No route out of a legacy estate earns approval until the run-cost ledger shows the recurring payment that is going to end, the staff member accountable for ending it, and the date on which it ends. Everything below is a method for reaching that line. Until it exists, the options are preferences, and a preference cannot carry a business case.
The bill that had never been added up
The engagement began at a UK mutual insurer, looking at a policy administration system on an IBM mainframe. The system ran under z/OS: CICS transactions driving COBOL programs over VSAM files and a DB2 policy master, a nightly batch chain producing commission statements and regulatory extracts, and an MQ queue carrying policy changes out to a .NET portal. Two engineers could recite the batch schedule from memory. No one could reconstruct it from the documentation, because the documentation had stopped at a release superseded more than a decade earlier.
Nothing was failing in a way a board would notice. The batch settled overnight, the reconciliations balanced, and the auditors had approved the system for years. The damage sat in the run-cost ledger, spread across lines that never appeared on the same page. Extended hardware support on a machine that had dropped out of mainstream service. Another logical partition still hosts an integration environment for a cancelled project. A tape archive invoiced by volume. A licence tier bought for that same cancelled project and renewed every year because the renewal notice arrived and somebody paid it. A retainer for a contractor who knew two of the older programs. Overtime for the operators who nursed the batch window through month end.
Each line was defensible on its own. Together they were the largest single cost in the technology budget, and no single user could see more than a few of them.
What the transformation changed
The programme that followed matters for its shape. The cost reduction came out of that shape: boundaries that separated charges from the system, events that replaced a nightly extract, and parallel operation that made cancellation safe.
The policy master stayed in place. A service façade was placed in front of the CICS transactions, so the policy master's capabilities could be called as coarse-grained services by anything that needed them. An anti-corruption layer sat between the legacy copybooks and the canonical event schema, which meant the enterprise contract for a policy change did not inherit a record layout designed for tape. The portal moved onto the façade and its direct file transfers were deleted. The commission run changed from a nightly extract into an event-driven flow, with an idempotent consumer so a repeat delivery could not pay a commission twice. The policy master then ran in parallel against the new service-owned datastore, cycle by cycle, until the outputs matched.
The copybook stayed behind the interface:
01 POLICY-EVENT.
05 EVENT-ID PIC X(32).
05 POLICY-NUMBER PIC X(12).
05 EFFECTIVE-DATE PIC 9(8).
05 PREMIUM-AMOUNT PIC S9(7)V99 COMP-3.
05 CHANGE-REASON PIC X(2).
That fence let the organisation cease consuming a set of charges while the system that produced them continued running. Stopping the charges is the cost reduction.
The charges, taken one at a time
Each recurring line was given an entry of its own, because a total hides the thing you are trying to remove.
Extended hardware support. It renews annually with a long notice period, the price has risen at each renewal, and it exists only because the machine is out of mainstream service.
The idle LPAR is a virtual machine that remains inactive. It consumes capacity, licence entitlement and operator attention, and the project it served was cancelled before the assessment began.
Volume-invoiced tape archive. The invoice tracks stored volume, so it grows while the business shrinks, and no retention policy has been applied to it in years.
The licence tier. It was bought for capacity the cancelled project never used, and the renewal is paid by default because the notice lands in a queue instead of on a desk.
The specialist retainer. It buys availability instead of work, and its value falls as the service façade removes the need for deep program knowledge.
Batch-window overtime. It is a recurring labour charge created by the schedule, not by the volume of work.
Each entry had a renewal date, a cancellation clause and a named consumer. That combination is what turns a cost into a candidate.
The series of steps has a check at each stage
Step 1. Build the charge register from invoices and contracts
Collect twelve months of invoices, the contracts behind them, and the renewal calendar. Start from the money, because an architecture diagram does not carry prices. Check before continuing: for every recurring line, you can find the user who authorised the last renewal and the notice period that applies.
Step 2. Attribute each line to a function that someone consumes
Walk the estate and ask who or what calls each component. Map by observation, then attach every charge to a function. Check: no line remains without a consumer, and the idle partition, the unused licence tier and the cancelled-project environment have been identified as consuming nothing.
Step 3. Separate the data before you touch the application
The largest charge usually comes from data that no live process reads. Archon Data Store shows the split that works: active data moves to the live environment, data with a retention or audit obligation moves to a governed archive, and data past its retention window with no business value is disposed of defensibly. Check: archived records reconcile to the source count, a sample can be retrieved and read, and the retention schedule is attached to the archive rather than to the old application.
Step 4. Prove the replacement on a full cycle before cancelling anything
Run the new path in parallel with the old one through a month end and a year end. Compare outputs at the level the business uses them. Check: two complete cycles have closed with matching results, and the operational team has agreed that they would be willing to run on the new path.
Step 5. Cancel based on the contract chain rather than the system layout.
Notice dates determine cancellation. Give notice on the lines with the longest notice periods first, and record each one. Check: a register shows the notice sent, the date it was sent, and the first invoice date on which the line should be absent.
Step 6. Report against the original line in the following year's actuals
Two conditions must be met before a user calls the reduction achieved:
- The payment has stopped in the accounts. The plan alone does not satisfy the check.
- The saving has been removed from the following year's budget. It no longer sits as headroom for another purpose.
Check: the annual accounts show the line gone, with no compensating increase elsewhere in the run-cost ledger.
Where this goes wrong
The most common failure is a real reduction that no one can see, because the money returns to a general run-cost pot and the next budget round manages it as headroom. Name the destination of the saving before the work starts, and put it in the baseline.
Another failure is a dependency that was documented as nothing. A non-production environment carries risk. RecordPoint says that the 2024 Midnight Blizzard intrusion at Microsoft began with a legacy non-production test tenant, and the environments that carry no visible workload are exactly the ones left behind when a project ends. Retiring an unused partition is a cost reduction and a security reduction at the same time.
The third failure is treating decommissioning as the low-risk option. The MHRA's guidance for adopters is explicit that the decision has to weigh the risks of retaining a legacy system against the risks of decommissioning it, and that planning for the end of a technology should begin during procurement. A cost reduction that ignores the decommissioning risk is a transfer of cost into a later incident.
The Government Digital Service's guidance on managing legacy technology puts continuous improvement planning first among its principles. The reason is financial: Gradual retirement of technology is generally cheaper and simpler than a full decommissioning project and prevents the next legacy estate from accumulating. The same guidance suggests a complete register of data assets and a current map of systems and infrastructure, which are the two records this method depends on.
The test at the end is straightforward. The line has gone from the accounts, the user who owned the renewal knows the line has gone, and the system that used to justify the line still runs for the functions that need it. That is legacy system cost reduction that earns its place.
