Replatforming, rearchitecture and rewrite are three different amounts of money, risk and elapsed time, and proposals routinely blur them. The distinction is not academic: choosing a rewrite where a replatform would have worked is the single most expensive mistake in modernization, and it is usually made in the first two weeks by someone who has not yet read the code.
01The three, precisely
Replatforming moves a system to modern infrastructure with minimal code change. The application is largely as it was; what changes is where and how it runs. Fastest, cheapest, lowest risk, and it adds no new capability.
Rearchitecture restructures the application itself, most commonly by splitting a monolith along business boundaries. The system does the same thing, but it can now be changed safely by more than one team at a time.
A rewrite replaces the system. It is the slowest and by far the riskiest, because you are reimplementing behaviour that nobody has fully documented and that the business depends on.
| Approach | Typical duration | Risk | Adds capability |
|---|---|---|---|
| Replatform | Weeks to a few months | Low | No |
| Rearchitect | Months | Medium | Indirectly - enables change |
| Rewrite | A year or more | High | Yes, and behaviour drift |
02The question that decides it
Ask how often the subsystem changes. Not how old it is, not what language it is in - how often someone needs to modify it.
A twenty-year-old system that nobody has touched in three years and that works is not a modernization candidate. Its age is irrelevant because age is not a cost. The cost is in systems that need to change and resist changing.
03Why rewrites go wrong
The behaviour you are replacing is not in the specification. It is in twenty years of accumulated edge cases, each added because a real customer hit a real problem. Most are undocumented and some are load-bearing.
A rewrite has to rediscover all of it, usually by shipping something that is subtly wrong and waiting for complaints. Meanwhile the old system still needs maintaining, so you are funding two systems and delivering no new value until the switch.
There are cases where a rewrite is right: the technology is genuinely unsupportable, the domain has changed fundamentally, or the system is small enough that the behaviour fits in one person's head. Those cases are rarer than proposals suggest.
04Mixing all three in one programme
The decision is per subsystem, not per estate. A realistic programme replatforms the stable periphery, rearchitects the two or three components that actually block delivery, and leaves the rest alone.
This is also what makes budgets defensible. 'We are modernizing the platform' is not a number anyone can sanity-check. 'We are rearchitecting order management because it blocks four teams, replatforming the rest, and not touching reporting' is.
- Score each subsystem on change frequency and business value first
- Replatform anything stable that only needs to move off unsupported infrastructure
- Rearchitect only what genuinely blocks delivery
- Reserve rewrites for systems that are small or truly unsupportable
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.