By Ritvars Mētra, Founder of ReadinessCompassAdoption metrics can be argued with. Usage counts can be inflated, survey scores can be flattered, and training completion proves nothing at all.
There is exactly one adoption test that cannot be gamed: switch the old system off. If work continues, adoption happened. If it does not, it did not.
Which is precisely why so many legacy systems are still running four years after the replacement went live.
Why it does not happen
Decommissioning has a distinctive profile: the cost of delay is small and diffuse, the risk of acting is concentrated and personal, and nobody’s objectives contain it.
- It is unfunded. The programme budget ended at go-live. Decommissioning needs money after the money has gone.
- It is nobody’s objective. No one is measured on systems switched off, and several people are measured on nothing breaking.
- The dependencies are unknown. A twelve-year-old system has interfaces, reports and scheduled jobs nobody has documented, and a proportion of them still matter.
- Retention obligations are unclear. Somebody says “we might need it for audit” and the conversation ends, because nobody can say for how long or in what form.
The National Audit Office reached the same conclusion about government’s legacy estate, recommending that bodies produce plans so that maintenance, support and decommissioning are systematically addressed and the required funding is ringfenced. Ringfenced, because a decommissioning budget that is not protected is the first thing reallocated to a live problem.
The adoption cost of leaving it on
The licence and hosting cost is the visible one and usually the smaller one. The adoption cost is larger and entirely invisible.
While the old route remains open, the new way is optional. Under time pressure people will use whichever system they are faster in, which for a period is the old one — and Markus and Tanis observe that operational staff adopt workarounds to cope with early problems and then fail to abandon them once the problems are resolved. An available legacy system is the most powerful workaround in the building, and it has an executive sponsor in the form of whoever declined to fund the switch-off.
The practical consequence is that the adoption curve does not start when the new system goes live. It starts when the old one goes off, which is the same reason a parallel run needs a written exit standard.
How to actually get there
| Step | What it settles |
|---|---|
| 1. Log who is still using it, and for what | Access logs answer this in a day. The list is always shorter than people assume, and the reasons are specific |
| 2. Separate lookup from processing | Most residual use is looking something up, which read-only access solves entirely |
| 3. Get the retention answer in writing | How long, which records, in what form. Usually an archive rather than a running system |
| 4. Go read-only, with a date | The real decision point. Ends the workaround while keeping the reassurance |
| 5. Set the switch-off date and hold it | Dependencies surface when a date is credible, and not before |
Step four does most of the work. Read-only removes the ability to process while preserving the ability to check, which addresses the actual anxiety — people are rarely attached to the old system, they are attached to being able to look something up.
Step five is worth stating plainly: unknown dependencies are not discoverable by asking. They surface when a date is announced and believed, because that is when the person running a monthly report off the old database finally mentions it. Announce the date early enough that the surprises are cheap.
Decide it before go-live
Every part of this is easier while the programme still exists. Put the decommissioning date, its owner and its funding in the go-live decision paper, alongside the reversion arrangements that the same paper should already contain.
Doing so also has an honest side effect: it forces the organisation to say out loud how long it intends to keep a fallback. That is a genuine risk decision, and it is better made deliberately at the gate than by default, four years later, when someone notices the invoice.
More on what survives a programme in the Adoption Risk Hub, or read who owns the process after closure.