Archive-and-Shutdown

A large fraction of applications in an enterprise estate are kept running for one reason: someone might need the data. Retention obligations, occasional lookups, and a general fear of deleting something make shutdown feel unsafe, so the application continues to consume infrastructure, licences, patching, security review and audit attention indefinitely.

Archive-and-shutdown separates the two obligations. The requirement is to retain the data, not to run the software. Export it in a durable, readable, documented format; store it cheaply; shut the application down.

Why it matters

This distinction unlocks a large proportion of a typical rationalisation programme. Applications in the low-value, unhealthy quadrant — which is where the savings are — are frequently blocked by a retention argument that dissolves once the data is separated from the application.

The savings compound beyond infrastructure: every running application carries patching, vulnerability management, access review, compliance evidence, disaster-recovery testing and a share of someone's attention. Those costs are largely independent of usage, so a barely-used application costs nearly as much as a busy one.

Implementation patterns

• Export to an open, self-describing format — Parquet, CSV with a schema, or documented JSON — not a database backup, which requires the original engine and version to read and therefore preserves the dependency you were removing.
• Include the schema, field meanings, code lists and any decoding logic, because data whose meaning is encoded only in the retired application's source is not readable data. This is the most commonly skipped step and the one that makes archives useless.
• Verify readability after export, by actually querying the archive with a general-purpose tool.
• Record the retention period and the disposal date, with automated expiry, so the archive does not become a permanent unmanaged liability of its own.
• Apply the same access controls and classification as the live system, since archived personal data is still personal data.
• Provide a documented lookup path for the occasional query, so the retirement does not create a support burden that motivates keeping the application.
• Dark-launch the shutdown first: block access for a defined period and see who complains. This is far more informative than any dependency analysis, and the unknown consumer is the usual blocker.
• Decommission the infrastructure, licences, DNS entries, monitoring and access grants, or the costs continue after the application stops.

Industry example

The pattern is standard practice in enterprise portfolio rationalisation and in regulated industries, where retention obligations frequently span years beyond an application's useful life. Regulators generally require that records be retained, retrievable and intelligible — which an archive satisfies, and which does not require the originating system to remain operable.

The consistent failure is the reverse: estates carrying dozens of applications kept alive solely as data viewers, each accumulating security debt, each requiring an owner, and each eventually becoming a genuine risk because nobody patches software that nobody uses.

Failure scenarios

• Exporting a database backup, preserving the dependency on the retired engine and version.
• Archiving data without its schema or code lists, producing an unreadable artefact that satisfies an audit and helps no one.
• Never verifying the archive is readable, discovering the problem years later during an investigation.
• No disposal date, so the archive becomes a permanent liability and a growing privacy exposure.
• Access controls dropped on the assumption that archived data is less sensitive.
• The application shut down while infrastructure, licences and monitoring continue to be paid for.
• No lookup path, generating support requests that lead to the application being restored.
• Shutting down without a dark-launch period, discovering the unknown consumer at the worst moment.

Trade-offs

An archive is materially less usable than a running application. Queries are slower, ad hoc analysis is harder, and a user who occasionally needed a screen now needs a data request. Where that access is genuinely frequent, retirement may not be appropriate — and the honest test is measured usage, not asserted usage.

There is also effort in the export itself: understanding the schema, extracting meaning encoded in application logic, and verifying the result. For a complex application that is real work, and it competes with delivery — which is the argument for funding decommissioning centrally, since the beneficiary is the organisation.

The trade is convenience of access and one-off migration effort in exchange for removing an application's entire ongoing cost and risk surface. For low-value systems it is decisively correct, and the pattern's main value is that it converts "we cannot turn this off" into a solvable data problem.

Interview question

"We have forty applications nobody uses that we cannot switch off because of retention rules. Tell me how you would retire them, what specifically you would export, and how you would find out who is still quietly depending on one of them."