In this guide 6 sections
Refactor or replace piece by piece unless the system is truly unfixable. A full rewrite takes longer than expected, freezes feature requests for a year or more and loses behaviour that nobody ever wrote down. The strangler approach moves one function at a time to new code while the old system keeps running, and the data moves last.
Signs the system really must change
Age alone is not a reason. A stable program can run for years. Look for pain instead: nobody can change it safely, the vendor has vanished, the compiler is unobtainable, or the platform no longer receives security patches.
Other signs are quieter. New staff cannot learn the screens, a simple report needs a developer, and every integration is a custom hack bolted on by someone who has since moved on. Months for a small change? The system is holding you back.
Write down which of these are true before choosing a method. Symptoms decide the cure.
- Only one person understands the code
- The runtime or database engine is out of support
- A change on one screen breaks an unrelated report
- Integrations rely on CSV file drops and manual exports
- The hosting hardware is failing
Why full rewrites disappoint
A rewrite sounds clean. In practice the old system holds years of small rules: the discount for one customer, the rounding quirk on tax lines, the report finance quietly relies on each quarter. None of it is specified.
The old system still needs fixes while the rewrite runs, so the team maintains two products at once and the business waits for both. Scope balloons. Users, seeing a blank page, ask for everything they ever wanted.
Sometimes a rewrite is right. If the platform is dead, the code will not build and the data model itself is the problem, then starting fresh is the honest answer. Just go in with eyes open.
The strangler approach in plain terms
Put a thin routing layer in front of the old system. Requests for one function, say quoting or customer search, go to new code, while everything else still reaches the old application through the same address. New parts slowly take over.
Pick the first function carefully. Choose something self-contained, visible to users and painful today. A quick win builds trust, and it teaches the team how the old data really behaves before the harder modules arrive.
Each step is small enough to reverse. Does the new quote screen misbehave? Switch the route back. That safety net is the main reason to prefer this path over one big release on a Friday night.
Data and running both side by side
Data is the hard part. Decide which system owns each table at each stage, and never let both write the same record, because two-way sync is where duplicate invoices are born. Sync one way first. Flip it later.
Run both in parallel for a while. Every morning, compare invoice counts, stock levels and ledger totals between the two, and chase each difference to its cause. A gap points to a rule you missed. Finding it early is cheap.
Clean as you go, but do not clean everything at once. Archive old history instead of carrying every closed order from fifteen years ago into the new schema.
- One owner per table at any time
- A daily comparison of key totals
- A read-only fallback to the old screens
- A written retirement date for each old module
What to keep and where to begin
Keep the business rules, the data and the reports people trust. Discard the screens, the framework and the workarounds. Interview the daily users at their desks, because they know which rules matter and which are plain habit.
Document the old behaviour as you find it. Those notes become automated tests for the new code, and that is how the odd rounding rule survives the move.
Start small. Pick one painful function. List every screen, table and report it touches.
Modernisation decision worksheet
A worksheet with a row per module of the old system. Columns: what it does, who uses it, pain level, tables owned, integrations, chosen route (keep, refactor, replace or retire) and move order. A final block lists rules found only in daily use, such as odd rounding.
Open a blank worksheet to printQuestions owners ask
Is refactoring always cheaper than a rewrite?
Not always, but it is usually safer. Refactoring spreads the effort and keeps the business running. A rewrite can still win when the platform is dead and nobody can build or run the existing code any longer.
Can we keep using the old system during the change?
Yes, that is the point of the strangler approach. The old system stays live while one function at a time moves across. You can switch any function back to the old route if the new version causes trouble.
What if nobody has the source code?
Then you have a harder problem. Recover what you can, record behaviour from the running system, and treat the database as the real asset. A replacement built from observed behaviour is often the only route. It is slower.
How do we avoid losing hidden business rules?
Ask the daily users, then compare outputs from both systems during a parallel run. Every difference in a total, a printout or a rounding decision points to a rule worth writing down. Test it.