The real cost of decommissioning a legacy system

A programme we were on finished its cutover in March. Every user was on the new platform, the old system was in read-only, and the steering committee closed the migration workstream. Two years later the old system was still switched on. It had no users at all. It was still running because a nightly export fed a reconciliation file in the finance team, and because nobody could produce a written answer to the question of how long its records had to be kept.

That is a normal outcome. The build gets estimated in detail: somebody counts the screens, the integrations, the migration scripts, the test cycles. The switch-off gets a line at the end of the plan that reads decommission legacy, with no owner, no duration and no cost. It is the only piece of work in a programme where the business case has already been signed, the attention has already moved on, and the people who understood the old system are the ones most likely to have left.

The saving in that business case usually depends on the line nobody examined.

What the old system is actually connected to

The first honest task is to find out what reads from it, which is a different list from what is supposed to read from it. On an estate of any age the answer is not in the architecture diagram. There is a scheduled job on a server owned by a different department. There is a desktop database on a shared drive that pulls a view every Monday morning. There is an integration built for a partner who has since been acquired, still authenticating with a service account nobody will admit to owning.

We find these with instrumentation rather than interviews. Turn on connection logging at the database, log every authenticated call at the API layer, and leave it running for a full business cycle. A month is not a business cycle in most enterprises. Quarter end moves data that never moves in an ordinary week, and the annual jobs appear once, usually in the week everyone is on leave.

The log is the real scope. Every entry on it becomes a consumer to migrate, a consumer to retire with its own conversation and its own sign-off, or an access route to close. The middle category is where the schedule goes. Retiring a consumer means finding the person who depends on its output and agreeing what replaces it, and that person does not report to the programme.

One category deserves naming on its own: the access route that belongs to a person rather than to a system. A director with a direct database login. A supplier with a VPN account issued during an implementation in 2014. An analyst who has been exporting a table into a personal model for six years and considers it part of the job. These surface late, they are politically awkward, and they are a common reason a system that was supposed to be off in June is still on in November.

Retention is a legal question with an engineering bill

Before any data moves, somebody has to state in writing how long each class of record must be held and in what form. In a bank or a public body that position exists somewhere. It rarely exists at the granularity engineering needs. Legal will say that records of a given type are retained for the statutory period. Engineering needs to know whether that covers the record only, the audit trail around it, the attachments, or the ability to reproduce the screen on which it was approved.

The last of those is the expensive answer. Reproducing a decision as it appeared to the person who made it means keeping the reference data of that day: the price list in force, the fee schedule, the version of the policy that applied. Migrating current state into a new platform preserves none of that, and the new platform has nowhere to put it.

There are three defensible places for history to live.

• Inside the new platform, if it can hold historical records without them contaminating live data and live reporting.
• In a separate archive built for retrieval rather than for daily use, with an index, an access model and a restore procedure that has actually been tested.
• Exported into a fixed format with a catalogue, where the retrieval path is documented and slow retrieval is accepted in advance.

The fourth option, keeping the old system running as its own archive, is what most organisations end up doing by default. It means paying licence fees for a product nobody uses, running an operating system that will leave support during the retention period, and maintaining credentials that have to survive every password policy change for the next decade. It is the most expensive archive available and it gets chosen by not deciding.

There is a second question underneath retention, which is what must be deleted. Holding data beyond its retention period is an exposure, and a decommissioning project is the one moment when an organisation has both the appetite and the mandate to delete at scale. Most do not use it. Deletion requires somebody to be confident in writing, and keeping everything feels safer right up to the day it is disclosed.

The report finance still runs

Every legacy system has one report that turns out to be load bearing. It is rarely on the list the programme agreed to rebuild, because the person who runs it did not attend the requirements workshop. It runs monthly, by one team, and it feeds something that leaves the organisation: a regulatory return, a group consolidation, a covenant calculation for a lender.

These come out the same way the technical consumers do, partly from logs and partly from the slower process of asking finance and compliance what they produce and where the numbers come from. The answer is usually a chain. A report exports into a spreadsheet, the spreadsheet feeds a template, the template becomes a submission. Only the first link is in scope on paper. All of them break when the source changes.

Rebuilding the report is the easy half. The hard half is proving that the new number matches the old number over a period both systems covered. That is reconciliation work, it takes longer than the rebuild, and it is what the finance team will actually use to decide whether they trust the switch. Give it its own task and its own duration, or it will be discovered in the week before year end.

Read-only is a state somebody has to run

Read-only is the standard compromise. Users move, the old system stays available for lookups, and everyone agrees it will be off in six months. Six months is optimistic in the way that all six months are.

A read-only system is still a system. It needs the operating system patched, because it still holds production data and is still on the network. It needs backups, because losing an archive the organisation is legally obliged to hold is worse than losing a system that can be rebuilt. It needs someone who can restore it and someone who can answer a question about it. If it authenticates against the corporate directory it is coupled to every change made there. If it holds personal data it is in scope for every subject access request and every breach notification obligation.

None of that is free, and it does not get cheaper with time. We price the read-only period explicitly, per month, with an end date in the plan and a named person who signs the switch-off. Without a date, read-only is permanent.

Turning it off

The switch-off itself is a sequence, and it is worth running slowly enough to stay reversible at each step.

1. 01Disable writes and wait. Some integrations write on a schedule nobody remembers, and they complain within a cycle.
2. 02Remove network access for everything except one named route. Leave it a week. Whatever breaks in that week was still using the system.
3. 03Revoke service accounts one at a time, in order, with a rollback for each.
4. 04Take a final backup, restore it into a clean environment to prove it works, and record who holds the key and where the restore procedure is written down.
5. 05Power the system down but keep it restorable for an agreed period, with the end of that period in the plan.
6. 06Cancel the licences, the support contracts and the hosting.

The last step is the one that pays for the programme and the one most likely to be missed. A licence cancelled the day after its annual renewal costs a full extra year, and the saving the business case promised arrives twelve months late. Renewal dates belong on the decommissioning plan next to the technical steps, because the finance calendar decides when the saving becomes real.

A modernisation programme does not start saving money on the day the new system goes live. It starts saving money on the day the old contract is cancelled.

How we scope it now

Legacy system decommissioning sits in our own service list as a line of its own, and we scope it as a workstream with its own budget rather than as the tail of the build. Our delivery method already treats integration as the largest single item in an enterprise programme and prices it explicitly instead of leaving it in contingency. The switch-off deserves the same treatment and almost never gets it.

In practice the workstream produces five things: a logged inventory of everything that reads from the old system, a written retention position signed by someone with the authority to sign it, a reconciliation plan for the reports that leave the organisation, a priced read-only period with an end date, and a switch-off runbook walked through by the people who will run it. None of that is difficult. All of it is easier to agree in the first month of a programme than in the twentieth.

Running two systems is worse than running either one of them, so none of this is an argument for keeping the old one warm. The point is narrower. The cheapest year of a modernisation programme is the year the organisation finally stops paying for the thing it replaced, and that year only arrives if somebody owns the switch-off by name. Put that name in the plan in week one, while the people who understand the old system are still on the account and still answering the phone.