Rewrite, refactor or replace? The strangler-fig method for SMEs
There are three honest ways off a legacy system: refactor it in place, replace it with a package, or rewrite it as a modern application. The fourth option, staying put, is a decision too, and it should be made deliberately rather than by default. The strangler-fig method takes the sting out of the rewrite: the new system grows around the old one a slice at a time, each slice proves itself in live use, and the old system is only switched off when nothing depends on it any more.
Every legacy system conversation eventually arrives at the same three doors: fix up what we have, buy something off the shelf, or build it again properly. Vendors will happily choose for you, each recommending, by remarkable coincidence, the door they sell. Here is the version with no coincidences in it.
The three doors, and the fourth nobody admits to
Refactor means improving the system you have without replacing it: moving the data to a proper database, untangling the worst code, lifting it onto a supported server. It is the cheapest door this year and the easiest to undersell or oversell. The honest test is the platform underneath. Refactoring a messy system on a living platform is sound engineering. Refactoring a system on a dead one, FoxPro, Clipper, DOS-era DataFlex, polishes the cabin of a sinking ship: every pound spent still depends on a runtime nobody supports and a talent pool that is retiring.
Replace means buying a package and migrating your data into it. Where the process is standard, this wins outright; nobody should commission bespoke payroll. The cost is the fit. Decades of small customisations are how your business actually competes, and a package obliges you to abandon the ones that do not match its shapes, then charges per user, per month, forever, for the privilege. The test: list the ten workflows your staff would refuse to give up, and ask the vendor to demonstrate each one. The demo meeting is cheaper than the discovery eighteen months in.
Rewrite means building the system again on a modern stack, with the old one as the specification. It carries the largest one-off price and the scariest reputation, mostly earned by rewrites run as big-bang bets. Run properly, behind a parallel run, it is the only door that ends with you owning the asset outright: no licence meter, no ceiling, and a hiring market measured in hundreds of thousands of developers rather than dozens.
Stay is the fourth door, and it is a real one. A stable system, a tested backup, an imaged machine and a written exit date is a legitimate position for a business with bigger fires. Staying by default, with none of those four things, is not a position; it is a countdown you have chosen not to look at.
The strangler fig, for businesses rather than conferences
The rewrite door has a hinge that changes everything, and it has a memorable name. Martin Fowler named the pattern after the strangler figs he saw in Queensland: they germinate in the canopy of a host tree, grow down and around it, and eventually stand on their own roots when the host is gone.
Applied to your system, it means the rewrite does not happen as one bet. It happens in slices:
- A slice is chosen. Usually something self-contained with visible value: the reporting nobody can get out of the old system, a customer-facing portal the old system could never offer, one painful workflow.
- The new system takes that slice live, reading from, and where necessary writing back to, the old system’s data. The old system keeps doing everything else.
- The slice proves itself in real use. Not in a demo. In month-end.
- The next slice follows. Each one shrinks the old system’s job and grows the new one’s, with the business banking value at every step instead of waiting two years for a grand unveiling.
- One day the old system does nothing. Switching it off becomes an anticlimax, which is the correct emotional register for decommissioning.
The slicing has a second benefit nobody markets: it caps regret. If priorities change after three slices, you stop, and the three slices keep working and keep paying. A big-bang rewrite abandoned at sixty per cent is worth nothing; a strangler fig abandoned at sixty per cent is sixty per cent of a system, live.
Choosing in practice
| Your situation | The door that usually wins |
|---|---|
| Standard process, modest customisation | Replace with a package, done carefully |
| Messy system on a living platform | Refactor, with a written scope so it does not become a rewrite by stealth |
| Bespoke system on a dead or dying platform | Rewrite, sliced strangler-fig style, behind a parallel run |
| Stable system, no changes needed, real fires elsewhere | Stay, with backups tested, the machine imaged and an exit date in the diary |
The pattern in that table: the platform decides more than the code does. Code quality is fixable; a dead platform is not.
If you want the choice made against your actual system rather than a table, that is what the free Legacy Risk Audit is for, and the Rescue Roadmap prices the chosen door at £1,950 fixed, credited against the build if you proceed. Whichever door it is, we will say so, including the two we do not sell.