When Updating Is Heresy: Warhammer 40K and the Risk of Legacy Systems

The Adeptus Mechanicus, technical debt and the price of technology nobody dares to change.

In the name of the Machine God

Imagine a forge world. The cathedral houses a machine rather than an altar. Walkways disappear into smoke; pipes climb iron walls like ribs. Candles tremble beneath the gears. Somewhere above, an indicator keeps blinking.

A tech-priest approaches a panel, performs an inherited sequence and waits. The machine answers. Nobody remembers who wrote the original instructions. Nobody wants to discover, in front of an idle factory, why the seventh step could not be skipped.

This is an imagined scene, not a canonical story. But its paradox fits Warhammer 40,000: a civilisation depends on technology that is as important as it is difficult to understand, change or replace.

Remove the robes, lower the chanting and replace the sacred panel with the server nobody has dared restart since 2014. The comparison becomes less strange.

Act I — The cult of the machine

Warhammer Community's introduction to the Adeptus Mechanicus describes engineer-priests preserving, reproducing and maintaining ancient technologies, some only partially understood. Knowledge, devotion and maintenance are intertwined.

It would be inaccurate to reduce them to “they hate everything new.” The Mechanicus also searches for lost knowledge, and Belisarius Cawl is an obvious counterexample to complete technological immobility.

The useful question is different: how much room remains for change when the explanation of a technology's operation is wrapped in the authority of tradition?

In our imaginary cathedral, an apprentice asks why a lever must be pulled twice. “We have always done it that way.” There may be an excellent reason. It may also be a workaround for a fault fixed centuries ago. Nobody can distinguish the two.

In IT, the ritual looks less solemn: a file named FINAL_v7, a procedure stored in one person's memory, or an application that only works with one particular library version. The system still produces results. The ability to explain those results is diminishing.

A technology can keep working after the organisation has lost much of its ability to govern it.

An inventory therefore needs more than a server name. Who owns it? Which process depends on it? What data does it handle? What does it depend on? Who knows how to restore it?

If the custodian leaves and the explanation leaves with them, the organisation loses more than a person. It loses part of its operational capability.

Act II — The cost of standing still

The machine keeps running. Everyone is reassured until a spare part disappears, an interface changes or vendor support ends. The temple discovers its stability had an expiry date. Nobody put it on the calendar.

Technical debt resembles interest on a deferred decision: a shortcut or unsuitable solution makes later work more expensive. It is not simply another word for age. Fear of touching a system can feed it: the less we know, the less we change; the less we change, the harder recovering knowledge becomes.

Consider a wholly hypothetical shipping application. It is reliable, but runs on an unsupported operating system and depends on a component the new environment rejects. Migrating during the seasonal peak could stop the warehouse. A short postponement may be reasonable.

Postponing for five years without review is different. Threats, access and staff change. Supplier knowledge becomes concentrated in one technician approaching retirement. The machine has not become sacred; it has become difficult to replace.

Joint CISA/NSA guidance on risky configurations highlights unsupported software and hardware: vulnerabilities may remain without vendor fixes. But “legacy” does not automatically mean vulnerable or non-compliant. Support, exposure, data, threats and actual controls matter.

In our warehouse, the postponement needs an owner and a review date. Meanwhile, necessary communications can be restricted, the system separated from less trusted networks, unusual activity monitored and authorised accounts reduced.

These are compensating measures to evaluate and test, not a blessing that removes every vulnerability. Guarding a door does not repair the wall. It may reduce exposure while the repair is prepared.

Delaying an update can be necessary. Systematically ignoring the resulting risk is something else. Incense is unfortunately not a compensating control.

Act III — The necessary heresy

Now the innovator arrives, looks at the panel and proposes replacing everything on Friday afternoon. Two hours later, the main machine runs perfectly. Three connected production lines are waiting for a signal the new system no longer sends.

The priests feared change. The newcomer feared only slowness. Both ignored the same thing: dependencies. A patch applied without understanding them can compromise availability while trying to improve security.

NIST SP 800-40 Rev. 4 treats patch management as preventive maintenance and an organisational process: identifying, prioritising, acquiring, installing and verifying updates. Security needs must be connected with the needs of the people keeping services running.

For the warehouse, change starts before the maintenance window. Reconstruct integrations, agree an acceptable interruption and test the new environment. Test the whole process: the order enters, the shipment leaves and the data returns correctly. An application opening successfully does not prove the service works.

Then prepare the way back: verified backups, workable instructions, available people and criteria for stopping. Rollback is not the sentence “we can always go back.” Some data changes make it complicated. Understand that before the warehouse phone starts ringing.

Postponement also needs governance:

• What residual risk remains?
• Who accepts the decision?
• When will it be reviewed?
• What event would require earlier action?

The cautious custodian and the innovator can sit at the same table. One knows the machine's scars. The other sees another route. Neither should win by principle. They need a transition the organisation can sustain.

Prayer is not a recovery strategy

Not every old technology needs scrapping. Not every new one deserves trust. A well-understood, maintained system may be more valuable than a brilliant replacement whose dependencies nobody has analysed.

But continuity cannot depend indefinitely on luck or the last remaining custodian.

Perhaps the real heresy is not updating. It is continuing to call something prudence after we can no longer explain it.

What would be harder in your environment: replacing the oldest system, or reconstructing the knowledge needed to change it safely?

English adaptation of my original article on manfredimarrocco.blog, my primary editorial source. The forge-world scenes are illustrative inventions, not quotations from Warhammer fiction or descriptions of client systems. Illustrations come from the original article. Translation and adaptation assisted by AI.