Every established business has one. A system that predates most of the staff, that nobody fully understands, and that everybody agrees should be replaced eventually.
Eventually keeps arriving because the risk of touching it feels larger than the cost of keeping it. Here is a sequence that makes it manageable.
Stage one: find out what it actually does
Not what it was specified to do. What it does now, after a decade of adjustments.
Follow the outputs. Every report it produces goes to somebody who uses it for something. List them, find the recipients, and ask what decision each one supports. Some will turn out to be unread, which is useful to know.
Read the data model. The fields tell you what the business tracked and, from the ones that are empty, what it stopped tracking. A field used for three different purposes over eight years is a story about how the process changed.
Watch people use it. They know more than they can explain. The keyboard shortcut nobody documented, the screen you have to visit first or the next one behaves oddly, the workaround for the thing that has been broken since 2018.
Find the integrations. Legacy systems accumulate connections — a nightly export to a spreadsheet somebody's report depends on, a file dropped on a network share that another system picks up. These are the things that break silently after cutover.
This stage is usually where projects are won or lost, and it is the one businesses try to shorten.
Stage two: decide what you are actually replacing
A ten-year-old system does many things, and not all of them still need doing.
Separate the requirements into: still essential; still done but no longer necessary; and done because the old system made it necessary.
That third category is often substantial. Manual reconciliation steps that exist because the old system could not do something. Reports produced to compensate for a gap. Replacing those requirements rather than the process behind them is how businesses carry twenty years of accumulated workaround into a new system.
Stage three: the data
This is where migrations overrun, without exception.
Profile it before planning anything. How many records? How many have required fields empty? How many duplicates? What formats are dates actually stored in? What is in the free-text field people have used for everything?
Expect values that cannot exist. Orders with no customer. Dates in the future that should not be. Amounts stored as text. Records whose status is a value the documentation does not list.
Decide what comes across. Not everything should. Agree a cut-off for historical detail and a plan for what happens to the rest — usually a read-only archive rather than a migration.
Clean at source where you can. Fixing data in the old system before migration is easier than fixing it during, because the old system is what people are still using to check.
The general approach is covered in migrating without losing history.
Migration timelines are set by data quality, not by system complexity. Profile the data in week one and you will know what you are actually facing.
Stage four: parallel running
Run both systems on the same work for a period, and compare.
It is genuinely expensive — people enter things twice — so it needs a defined scope and an end date. But it is what turns a hopeful cutover into an evidenced one.
Cover at least one month end, and ideally a quarter end, because that is when the reporting differences show up. Compare the numbers each system produces, and investigate every difference. Some will be the new system being wrong. Some will be the old system having been wrong for years, which is an awkward and valuable discovery.
Stage five: cutover
Pick a quiet point in your business cycle. Not month end, not your busiest season.
Have a written rollback plan. Not because you expect to use it, but because knowing it exists changes how the team behaves on the day.
Freeze changes in the old system at a stated time, run the final data migration, verify against known totals, then open the new system. Have more support available than you think you need for the first week.
Stage six: decommission deliberately
The stage that gets skipped, leaving old systems running for years "just in case".
That has real costs: licences, hosting, an unpatched machine on your network, and the temptation for somebody to go back to it.
Do it properly: keep the old system available read-only for an agreed period, take a full archive with a documented way to read it, confirm every integration has been re-pointed, then switch it off. Record what was archived and where, because in five years somebody will ask.
When nobody understands it and nobody wrote it down
This is common and it is not fatal.
Work from the data and the outputs, which cannot lie about what the system contains. Talk to the longest-serving users, who know the exceptions. Look at the file the system exports every night, because whatever consumes it defines part of your requirements. And accept that you will find something after cutover — plan support capacity for it rather than pretending you will not.
What makes it go wrong
Underestimating data quality. Skipping parallel running to save time. Migrating the workarounds along with the requirements. And treating it as an IT project when it is a business change project that happens to involve software.
Our data migration team moves UK businesses off ageing systems, starting with a profile of the data rather than a plan. Start a conversation.
