Decision guide
Rewrite vs modernize a legacy system
The rewrite is almost always the more appealing option and almost never the safer one. Here is how to tell which situation you are actually in.
Legacy systems invite rewrites because the existing code is unpleasant to work in and a clean start feels like the fix. The trouble is that the unpleasantness and the value are stored in the same place. Years of edge cases, regulatory quirks and bug fixes are encoded in code nobody enjoys reading, and a rewrite starts by throwing all of it away and hoping the important parts get rediscovered.
The deeper problem is structural. A rewrite has no value until it replaces the original, which means a long period of paying for two systems while shipping nothing, and a single high-stakes cutover at the end. Incremental modernization inverts that: each slice delivers on its own, and the risk is spread across many small reversible steps instead of concentrated in one irreversible one.
Side by side
| Criterion | Full rewrite | Incremental modernization |
|---|---|---|
| When value arrives | At the end, when the replacement goes live. Nothing before that. | Continuously — each migrated capability is in production and useful on its own. |
| Risk profile | Concentrated in one cutover. If it fails, there is often no partial fallback. | Distributed. Each slice runs in parallel with the old path and can be rolled back independently. |
| Feature delivery meanwhile | Usually frozen, or duplicated into both systems at double the cost. | Continues. New work lands in the new architecture as it is built. |
| Funding | One large commitment up front, before anyone can see whether it works. | Phase by phase, with the option to stop or re-sequence after each. |
| Hidden requirements | Rediscovered in production, often as incidents, because they were never written down. | Surfaced slice by slice, with the old system still running as a reference implementation. |
| Interim complexity | Lower — one architecture, cleanly designed. | Higher for a period. Two systems coexist behind a façade, and that has a real cost. |
A rewrite is defensible if
- The system is genuinely small enough to rebuild and verify in a few months.
- The platform is a dead end — an unsupported runtime with no migration path.
- The business rules are already documented elsewhere, so the code is not the only record.
- You can freeze feature work for the duration without losing ground.
Modernize incrementally if
- The system runs the business and cannot go dark.
- Nobody can fully enumerate what it does — the code is the specification.
- A previous rewrite has already been attempted and abandoned.
- Funding needs to be justified in stages rather than committed at once.
Our take
For anything load-bearing, the strangler-fig pattern is the default: put an API façade in front of the legacy system, move one bounded capability at a time behind feature flags, run old and new paths in parallel and compare their output before each cutover. It is slower on paper and dramatically less likely to end in a rollback. Start with an assessment that produces a costed, sequenced roadmap — that is the artefact that tells you whether a rewrite was ever the right call.
Questions we get asked
How long before we see anything from a modernization programme?
The assessment phase produces a costed roadmap in weeks, and a first migrated slice typically reaches production inside the first few months. That is the point of the approach: value arrives before the programme finishes.
Does running two systems in parallel not double the cost?
For a period, it adds cost — that is the honest trade-off. What you buy is the ability to compare the new path against the old before committing, and to roll back a slice without rolling back the programme.
What if our system is genuinely small?
Then a rewrite may well be right, and we will say so. The assessment exists to answer that question with evidence rather than preference.
What does modernization cost?
The assessment phase typically runs $4k–$9k and gives you a costed roadmap before you commit further. Full programmes start around $22k for a contained system and are funded phase by phase.
More decision guides
In-house hiring vs a dedicated team
Both give you engineers. They differ in how fast capacity arrives, what happens when the roadmap changes, and where the knowledge ends up.
Automation vs doing it manually
Not every repetitive task is worth automating. The deciding factors are how stable the rules are and what an error actually costs.
Still weighing it up?
Tell us the constraint you are working against and we will tell you which way we would go.