Most projects don’t end. They stop getting funded.
Most modernisation projects don’t end. They just stop getting funded. That is not the same as done. Done means the old system is off. The gap between those two is where a team quietly runs two systems for a year and pays for both.
The trap is familiar. The new system goes live, the demo works, everyone claps. The old system is still running in the corner, feeding three reports nobody admitted they depended on. I watched this on a manufacturing integration: the legacy order tool stayed alive for fourteen months after go-live, because one night shift used it to reconcile stock.
Here is the part I own. That was not a shutdown failure, it was a discovery failure. Those users existed before we built anything. We never audited who actually touched the old system, so we found them at decommission instead of at scoping. A shutdown checklist does not save you if discovery was thin.
Dual-running is not free
And dual-running is not free. For those fourteen months it was a legacy database licence, a VM, a patch cycle, and the real risk underneath: two systems holding stock numbers that slowly diverge. The number, rounded and anonymised because it is a client’s, was about 3,800 euros a month, roughly 53k over the run. That was more than enough to fund the work that actually killed the old box.
Price yours. That figure is usually the whole business case, and it belongs on the table with the other numbers that decide a modernisation budget rather than turning up as a surprise two quarters in. Launch is not the easy part. Launch is where integrations lie and people’s jobs are on the line. Shutdown is just the part nobody budgets for, because the slide already said “live”.
What “done” actually looks like
So here is the decommission checklist I hold a project to.
-
The legacy database goes read-only, then archived, then dark. In regulated shops (MiFID II, HIPAA, GMP), “dark” means a compliant retention archive in the original format, not a CSV export. Know your mandate before step one.
-
Every report and integration on the old system has a named owner who has signed off on the new source. Not “we think reporting moved over”. A name, against each feed.
-
Someone ran the old workflow end to end and hit a hard stop: login refused, data gone, export blocked. Name who tested it and when, or it did not happen.
The order matters. You cannot take the database dark until every reader has a named owner on the new source, and you cannot trust the migration until someone has tried to use the old system and failed. Each step is a gate, not a task on a list you can tick in any order.
Draw the line on purpose
The question worth settling at scoping, not at the end, is where your team draws the line: launch day, or the day the old stack goes dark. If you draw it at launch, you have budgeted for the easy half and left the expensive half to discover itself. If you draw it at dark, the dual-run cost and the discovery work are in the plan from the start, where they are cheap.
If your last project still has a legacy box running “just in case”, that box is a live line item, not a safety net. Price the dual-run first, then decide whether keeping it is a decision or a drift. Talk to TrueForge and we will help you scope the shutdown, not just the launch.