Replacing a system the business runs on, without stopping the business

Every company has one: a system nobody wants to touch, that everybody depends on, written by someone who left. It works. It is also the reason three other things cannot be done.

Replacing it is not a technical problem. It is the problem of changing the wheels while the car is moving, and the projects that fail do so for organisational reasons, not code ones.

Why the old system is still there

Worth saying plainly, because it changes the plan: it survived because it does something right.

Over ten years it absorbed every exception your business ever had — the customer who is invoiced differently, the product that is measured in two units, the rule that applies only in December. None of that is documented. It is in the code, and often only in the code.

That is why “we will rewrite it in six months” is almost always wrong. You are not rebuilding the features you can see. You are rebuilding a decade of accumulated decisions nobody wrote down.

Big bang or gradual

Big bang. Build the replacement, pick a weekend, switch. Simple to plan, and the right answer when the system is small, self-contained, and losing a day would not hurt.

It is the wrong answer for anything the business runs on, for one reason: there is no way back. If Monday reveals a problem, you cannot un-migrate a weekend of transactions. Every big-bang failure we have been called into looked fine on Friday.

Gradual — the strangler approach. Put the new system beside the old one and move one function at a time. Invoicing first, say. Everything else stays where it is, the two talk to each other, and the old system shrinks until there is nothing left in it.

More work in total, and more moving parts, and it is what we recommend for anything that would hurt to lose. Its virtue is that every step is small enough to reverse.

The middle case exists: for one department’s tool with fifteen users, big bang is fine. Judge it by what a bad Monday costs.

The migration is the project

People budget for the new system and treat moving the data as a task at the end. It is usually a third of the work, and it is where timelines break.

The data is not as good as you think. Every long-lived system holds the same things: the same customer three times under three spellings, records with mandatory fields empty because the field was added in 2019, dates in two formats, amounts where somebody used a comma. None of this matters while the old system runs, because the humans work around it. A new system with actual validation rejects it on day one.

Cleaning is a business job, not a technical one. Which of the three duplicate customers is the real one is a question only your people can answer. Budget it as its own phase, with your team’s time in it, or the automation faithfully carries the mess across.

Migrate in dry runs, repeatedly. Not once at the end. Run the full migration into a copy every week during the build, and count what fails. That number should fall. If nobody is running it until the last month, the last month is when you discover the size of the problem.

History is a decision. Ten years of transactions, or two years and an archive nobody edits? Full history often doubles the migration and buys very little; ask what someone would actually do with a 2017 record. This is a business call and it should be made early, because it changes the estimate.

Running both at once

For the gradual approach, both systems are live for months. Three things make that survivable:

1. One source of truth per record type
   • Customers live in one system. Orders in one system. Never “both, synced”.
   • Two-way sync of the same record is where data corruption comes from, and it is worth restructuring the plan to avoid it.
2. A reconciliation that runs nightly
   • Compare counts and totals on both sides and report the drift.
   • Drift is normal. Undetected drift is how you find out in March that January was wrong.
3. A visible cutover list
   • What has moved, what has not, who to ask about each.
   • Everyone in the company should be able to see it without asking IT.

Keeping a way back

The single question that separates the migrations that go well: for each step, what does reversing it look like, and how long does it take?

Keep the old system readable — not running, readable — for at least a full accounting cycle after the last function moves. Someone will ask what happened in a specific transaction in March, and the answer needs to exist.

Freeze the old data at cutover rather than deleting it. Storage is cheap. Being unable to answer an auditor is not.

What it costs and how long it takes

For companies with 10–200 employees:

• One function moved out — invoicing, or one department’s tool, running beside the old system: 10,000–25,000 EUR, 6–10 weeks.
• Gradual replacement of a mid-sized internal system, in stages, with reconciliation: from 45,000 EUR, 4–9 months.
• Data migration alone, where the target already exists: 6,000–20,000 EUR, depending almost entirely on how bad the data is.

That last range is wide for an honest reason. Until we have seen the actual records, nobody can tell you how much cleaning they need — and anyone who gives you a firm number without looking is quoting the good case.

How to know it worked

Measure before you start: how long a month-end close takes, how many things people do outside the system because it cannot do them, how long a change request waits.

• Realistic target: every function moved has run one full accounting cycle in the new system without a manual correction;
• Watch: the nightly reconciliation drift, and the count of records still edited in the old system;
• Success signal: somebody suggests a change that would have been impossible before, and nobody flinches.