Migrating Off a Legacy System Without Downtime

The old system works. Nobody understands it any more, the vendor has no capacity for it, new requests take months — but it works. That is exactly what makes replacing it so unpleasant: the job is not building something new, it is cutting the old one loose without stopping the company.

The idea is attractive: switch over the weekend, work in the new system on Monday. The problem is that you find the mistake on Monday morning — and by then there is usually nowhere to go back to, because orders have started landing in the new system.

Big bang makes sense only for a small system with little data and few users. For anything larger, the risk grows faster than the time saved.

It is more practical to split the system into parts and move them one at a time. The order follows one rule: start with whatever has the fewest ties to the rest.

Typically that is a reference list or a module that mostly reads data — reporting, for instance. Operations do not depend on it, so a mistake stops nobody, and it still proves whether the new system sees the data correctly.

Only then come the modules that write data, and last the ones daily operations run on.

Every step needs a defined state to roll back to. Not in theory — tested. The same point we make about backup and recovery of a company application: a restore that has never been tested is not a plan, it is a hope.

For a while both will be running. That is uncomfortable but unavoidable, and it is manageable if two things are settled in advance.

Which one is the source of truth. For every type of data, one system has to be binding. Not "both", because then two versions of reality appear and nobody knows which one counts.

How data is synchronised. One way, as long as you can. Two-way sync is an order of magnitude harder and brings conflicts to resolve. How that kind of link gets built is covered in the piece on connecting company systems through APIs.

This is underestimated almost every time. The old system holds years of exceptions: records missing mandatory fields, duplicate customers, dates in three formats, notes in the phone-number field.

The new system has stricter rules and will reject most of it. There are three options, and the choice should be deliberate: clean the data (best, most expensive), loosen the new system's rules (fast, carries the mess across), or do not migrate the problem records and keep them read-only in an archive.

What works well is repeated dry runs — the full data volume every week, with a report of what failed and why. The error list then shrinks gradually instead of appearing in full a week before go-live. A separate data cleaning step before migration is worth its own time.

• Third-party integrations. More things hang off the old system than anyone remembers — the bank, the e-shop, shipping, reports for the parent company.
• Printed documents. Invoices and delivery notes have to look the same, or customers and accountants will say so.
• User permissions. Migrate roles, not individual settings; it is a chance to tidy up who can see what.
• History. Decide up front how many years move to the new system and what stays in the archive.

A technically successful migration can still be spoiled if the team does not take it up. It helps to involve a few people from operations during testing — not as training, but as real work in the new system alongside the old. They find things that were never in the specification, and they become the people colleagues ask after go-live.

This deserves saying too: if the old system covers the needs and the only problem is that it is old, migration may not be the right call. Wrapping it in an interface and building new things beside it is often the more sensible move.

If you are weighing a replacement and want to walk through the risks before deciding, write to us. How we approach custom development, and what we have solved along these lines, is in our case studies.