- The system still encodes business rules nobody has fully documented.
- It is in active use and cannot be frozen for the length of a rebuild.
- The pain is concentrated in a few paths rather than spread evenly.
- You need to keep delivering value during the change.
- The target architecture is a hypothesis rather than a proven fit.
Choosing a path
Modernization or rewrite.
The rewrite is the most confidently made and least evidenced decision in enterprise software. It is usually proposed when a system has become frightening to change, which is a real problem, and it is usually justified with an estimate that assumes the new system will avoid the failures of the old one.
The useful question is not which approach is better. It is how much you can learn before committing.
Build your briefDECISIONIncremental or replace
HINGES ONCost of being wrong
TESTOne valuable path
01 / WHEN EACH IS JUSTIFIED
Both are legitimate. Neither is a default.
- A non-negotiable requirement cannot be met at any acceptable cost.
- The platform is genuinely end-of-life with no supported upgrade path.
- The business capability has changed so much the old model misdescribes it.
- The system is small enough that replacement risk is genuinely bounded.
- You can carry two systems for the whole overlap period, funded.
02 / WHAT THE COMPARISON TURNS ON
Reversibility, mostly.
The two options differ less in eventual cost than in what happens when an assumption turns out to be wrong.
Cost of being wrong
An incremental step that fails costs one step. A rewrite that fails costs the programme, and usually the credibility of the team that proposed it.
Undocumented behaviour
The existing system is the specification. Incremental change preserves behaviour by construction; a rewrite must rediscover it, and discovers it in production.
The overlap period
Rewrites are costed as a build and paid for as a build plus indefinite dual maintenance. The overlap is the line item that is consistently underestimated.
Delivery during the change
Incremental work keeps shipping. A rewrite typically freezes the roadmap, which is a real business cost that rarely appears in the comparison.
Evidence of fit
Incremental delivery produces evidence that the target architecture works here, with this data and this traffic. A rewrite defers that evidence until it is expensive to act on.
Team knowledge
Incremental change spreads understanding of both systems. A rewrite tends to split the team into those maintaining the past and those building the future.
03 / A SAFER WAY TO DECIDE
Buy evidence before you buy a programme.
- 01
Name the actual constraint
Write down what the current system prevents, in business terms. “It is hard to work with” is a symptom; “we cannot offer per-tenant data residency” is a constraint you can design against.
- 02
Propose the target architecture
State it explicitly, with the decisions and trade-offs recorded, so it can be challenged before anything is built on it.
- 03
Pick one valuable path
Choose a real user journey that matters commercially and exercises the parts of the architecture you are least sure about.
- 04
Deliver it to production
On the target architecture, with real traffic, alongside the existing system. This is the step that converts opinion into evidence.
- 05
Then decide the scope
With a working slice, the choice between continuing incrementally and committing to a wider programme is made on measurements rather than on estimates.
04 / QUESTIONS
Modernization questions.
When is a full rewrite actually justified?
When the existing system cannot meet a non-negotiable requirement at any acceptable cost, when its platform is genuinely end-of-life, or when the business capability it encodes has changed so fundamentally that the old model no longer describes the work. These situations exist, and they are rarer than rewrite proposals suggest.
What makes rewrites fail?
The old system is a record of every edge case the business encountered. A rewrite re-learns those cases in production, while simultaneously freezing the old system so both must be maintained. The overlap period, not the build, is what usually consumes the budget.
What is a modernization slice?
One valuable path through the system, delivered on the proposed target architecture, in production, with real traffic. It converts an architectural argument into evidence for a fraction of the cost of committing to a full programme.
How long should a slice take?
Long enough to exercise the risky parts of the architecture and short enough that the answer still arrives before the decision has to be made. If a slice cannot be scoped that way, the architecture is probably not yet specific enough.
Next decision
Test the architecture, then commit.
One valuable path in production answers more than a year of estimation.