The safest way to replace an old system is to move it one function at a time. Put a thin layer in front of the old system, build one function in the new system, route traffic to it, check the results against the old one, then repeat. This is called the strangler pattern. The old system shrinks until nothing is left to switch off.
Why a full rewrite fails
A rewrite promises a clean start. Three problems follow it.
- The target moves. The business keeps changing while the rewrite runs. By the time the new system is ready, it copies a company that has since changed.
- Nothing ships until everything ships. The team delivers no value for a year or more, and its budget is the first one questioned when priorities shift.
- The old system is the specification. Nobody has read all of it. Rules sit in code written years ago, and the rewrite team finds them one by one, usually after go-live.
The 2018 move at TSB Bank in the United Kingdom shows what a single cutover can cost. In April 2018 the bank moved its customer data to a new platform. According to the Bank of England, a significant proportion of its 5.2 million customers were affected by the first problems, some issues lasted until December 2018, and the Financial Conduct Authority and the Prudential Regulation Authority fined the bank £48.65 million, announced on 20 December 2022. Source: Bank of England, "TSB fined for operational resilience failings". A staged approach limits how much can go wrong at once.
Grow around the old system
Replace the system in an order that puts the least at risk first.
- Reports first. Build the new reporting layer from a copy of the old data. Nothing is written back, so a mistake costs a bad chart and not a bad ledger. You also learn how clean the data is.
- One self-contained workflow next. Pick one process with clear edges, such as gate passes, leave requests or quotation approvals, and run it in the new system.
- A module with its own records. Move a function such as stores or the vendor master, so the new system becomes the source of truth for it.
- The core last. Ledger, billing and similar functions move when the team has learned the data and the rules.
To rank your own systems, see which legacy systems to modernise first. For the seven approaches (rehost, replatform, refactor and others), see legacy modernisation approaches compared.
The facade does the work
A facade is a thin routing layer in front of the old system. Users and connected systems call the facade, and it sends each request to the old system or the new one. You can move one function at a time, and if the new one misbehaves, route that function back to the old system. Users see the same screens and links throughout. Without a facade, every move needs everyone to change at once, which is a big bang in small pieces.
Run both systems before you trust one
Before switching a function, run old and new side by side on live input and compare.
- Reconcile by machine, not by sample. Compare every record and every total, using checksums or matching rules. A spot check by a person catches the errors people think of. A full comparison catches the others.
- Write down every difference. Each mismatch is either a defect in the new system or a rule the old one applied that nobody listed. Record which, and the reason.
- Set an exit rule. For example: the two systems agree on every record for a full month-end close, including year-end where possible. Then switch.
A parallel run seldom exposes arithmetic errors. More often it exposes unwritten rules: a customer class that rounds differently, a tax treatment added as an exception after a rule change, a discount that only applies on one day of the month. See recovering undocumented business rules.
Rescue the knowledge
While the old system is still running, record how it behaves.
- Interview the people who run it, and the people who fix it when it breaks.
- Turn each rule you find into a test that the new system must pass.
- Keep the old system's outputs for a set period, so a disputed figure can be traced.
Those tests last longer than the migration. They become the safety net for every later change.
What it costs and what you get
A staged programme takes longer on the calendar than the first estimate for a rewrite. It spends money in smaller amounts, and every step is a point where you can stop, change course or keep what you have. Each completed stage is already in use. For rollout choices see big-bang versus phased rollout.
When a rewrite does make sense
Apply these criteria to your own system.
- The old platform is unsupported and cannot be put behind a facade.
- The whole system is compact enough to be described and tested end to end before you switch.
- The business function itself is being retired or changed completely.
Outside those cases, move in stages.
Questions buyers ask
Can we replace a legacy system without downtime?
Usually yes, with a facade in front and a parallel run before each switch. A short cutover window can still be needed for the final data move of a core function.
What is a parallel run?
Running the old and new system on the same live input, and comparing every output until they agree.
What goes first?
Reporting, then one self-contained workflow, then a module with its own records, then the core.
Where Brihat Infotech fits
Brihat Infotech's legacy modernisation work uses strangler-pattern migration, checksummed parallel runs and interface preservation, and ends with evidence for switching off the old system. Start a conversation.