Modernization is not one service. It is five distinct kinds of work with a price range spanning an order of magnitude, and vendors routinely use the cheapest label to win the deal and the most expensive scope to deliver it. Knowing which one you are actually buying is the difference between a predictable programme and a budget conversation six months in.
01The five categories, honestly described
These are usually presented as a ladder where each rung is strictly better. They are not - they are different trades between cost, disruption and how much of the original constraint you keep. Picking the highest rung you can afford is a common and expensive mistake.
| Approach | What changes | What does not | Relative cost |
|---|---|---|---|
| Rehost | Where it runs | Everything about the code | 1x |
| Replatform | Runtime, managed services around it | Application structure | 2-3x |
| Refactor | Internal code structure | Architecture and data model | 3-5x |
| Rearchitect | Service boundaries, data ownership | Business logic, mostly | 6-10x |
| Rebuild | Everything | Only the domain understanding | 10x+ |
02Rehost is underrated and often correct
Lifting a system into cloud infrastructure without changing it is dismissed as 'not real modernization'. It is frequently the right first move: it decouples the retirement of ageing hardware from the much longer question of what to do with the application, and it buys years of runway for a fraction of the cost.
The failure mode is stopping there while expecting cloud-native benefits. A rehosted monolith on a VM costs more to run than it did on hardware you already owned and gains you very little elasticity. Rehost as a deliberate step with a stated next move is sound; rehost sold as transformation is not.
03Where the cost multiplier actually comes from
The jump from refactor to rearchitect is where budgets break, and the reason is data rather than code. Splitting a system into services means splitting the database, and splitting a database means deciding who owns each entity, handling the transactions that used to span tables, and backfilling history into new stores.
That work is invisible in a proposal that focuses on service boundaries. When you see a rearchitecture priced close to a refactor, the data migration has almost certainly been underestimated or excluded.
04Choosing based on what is actually blocking you
The right approach follows from the constraint you are trying to remove, not from how modern you want the stack to look. If the problem is that the hardware is out of support, rehost solves it. If the problem is that deploys take a weekend, the constraint is release process rather than architecture. If the problem is that two teams cannot ship without coordinating, that is a boundary problem and rearchitecture is genuinely warranted.
Writing the constraint down in one sentence before talking to vendors is the single most effective thing a buyer can do. It converts an open-ended transformation conversation into a scoped problem with a testable outcome.
- Hardware or OS out of support: rehost
- Operational cost and toil: replatform onto managed services
- Code is unmaintainable but structure is sound: refactor
- Teams block each other, scaling is uneven: rearchitect
- Domain has fundamentally changed and the model no longer fits: rebuild
Topics
Lena Voss
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.