A rewrite that shipped at 60 per cent while the old system kept invoicing
I once watched an eighteen-month rewrite ship at sixty per cent feature parity, while the legacy system it was meant to replace kept invoicing customers the entire time. The code was never the problem. Twelve years of accumulated logic, a database nobody dared touch, and three people who actually understood it: that was the problem.
Here is what the room got wrong, and it is the most common mistake I see. Everyone treated “rewrite or keep” as a build decision. It was a pricing decision, and nobody priced it.
Why the all-at-once rewrite is the most expensive line on the table
Ripping out a system that still runs the business is the single most expensive option available, because three meters run at once. You pay the old system’s full maintenance, plus the rewrite burn, plus the revenue you defer while crawling back to parity. Across the modernisations I have costed, running the old system in parallel during a long rewrite adds a substantial fraction to the total bill. The numbers are round and openly estimated, but consistent enough that I now assume it going in. That is the same dual-running cost that quietly decides most modernisation budgets, and it is almost always left out of the build-vs-buy conversation entirely.
In the project above, someone had proposed moving one capability at a time and leaving the rest earning. It got killed as “too slow.” Eighteen months later, slow would have looked excellent.
The deeper failure is organisational, not architectural
Three people holding twelve years of domain logic in their heads is an organisational risk, not a technical one, and a big-bang rewrite makes it worse, because it asks those same three people to re-specify everything at once, under deadline, while still keeping the old system alive.
Moving one capability at a time fixes both problems at once. The business keeps earning, and each slice forces the knowledge out of three heads and into something the team owns and tests. A wrong call then costs a sprint instead of a fiscal year. This is the whole case for the incremental, downtime-free approach: it is not just safer engineering, it is cheaper risk.
There is no clean four-question checklist
I distrust anyone who sells this decision as a tidy flowchart. The honest version is messier. In a regulated business (and most of the manufacturers, operators and financial firms we work with across the UAE and the wider MENA region carry real regulatory weight), you also have to answer who owns the audit trail mid-migration, what your lock-in exposure is at the vendor’s next price revision, and what a regulator sees if you strand the old system halfway. Those questions kill more “simple” rewrites than budget ever does, and they are exactly where composable architecture earns its place: designing around contracts rather than products keeps the exit door open and the audit trail intact while you move.
The framing holds whether you run a thirty-person shop or a regulated manufacturer with eight hundred. If anything, the smaller the team, the less a wrong call is survivable. There is no slack to absorb a rewrite that overruns by a year.
How to actually make the call
The useful sequence is short, and none of it is about the technology:
- Price all three options honestly. Keep it, replace it, modernise it in place, each with its real cost, including the dual-running meter and the revenue deferred. The cheapest-looking option on the surface is frequently the most expensive once all three meters are counted.
- Find where the knowledge lives. If the system runs on what a handful of people hold in their heads, that is the risk to retire first, and a big-bang rewrite is the worst way to do it.
- Decide what stays earning while you move. The capability you can leave untouched is the capability you do not have to pay to rebuild, at least not yet.
The systems hardest to place are the ones where these answers are genuinely ambiguous, and that ambiguity is information: it usually points to a knowledge or ownership gap, not a technical one.
If one of your systems is hard to place right now (keep it, replace it, or modernise it in place) and the call feels ambiguous, that is the conversation worth having before the budget is set. Talk to TrueForge and we will price the options with you, including the ones the room usually forgets.