Rehost vs Replatform vs Refactor vs Rebuild

Part 3 laid out all seven Rs and made a key point: most of them resolve quickly once you understand a component. Retire the dead code, retain the stable parts, replace the commodity functions — those decisions are usually clear. What is left is the band that actually consumes the debate, the budget, and the risk: rehost, replatform, refactor, and rebuild. This part turns those four into a decision framework you can apply to a real component, one at a time.

The one question underneath all four

Before comparing the options, ask the question that orders them: does the business need this component to change, or just to run somewhere better?

That single distinction sorts the four. Rehost and replatform answer “run somewhere better” — they improve where and how the system operates without touching what it does internally. Refactor and rebuild answer “change” — they alter the system’s internal structure so it can evolve. Most expensive modernization mistakes come from answering the wrong question: rehosting a system the business desperately needs to evolve (so nothing actually improves), or rebuilding a stable component the business never asked to change (so you spend the most for no new value).

The four, side by side

	Rehost	Replatform	Refactor / Rearchitect	Rebuild
Changes the code?	No	Minimally	Yes — structure	Yes — entirely
Preserves behavior?	Exactly	Exactly	By design (must prove it)	Re-derives it
Relative cost	Low	Low–medium	Medium–high	Highest
Relative risk	Low	Low–medium	Medium	High
Time to value	Fast	Fast	Steady, incremental	Slow if big-bang
Fixes changeability?	No	Barely	Yes	Yes
Best when	Need a new home, on a deadline	Operational pain, not change pain	The system must evolve and is salvageable	The code is beyond saving

The columns trade two things against each other: how much you spend and risk, versus how much you fix the actual legacy condition. There is no free lunch — the cheap, safe options don’t make the system changeable, and the option that fully fixes changeability is the one that costs and risks the most. The skill is matching the move to what the component genuinely needs.

Rehost: relocate, don’t transform

Rehosting takes the system as-is and moves it onto new infrastructure. The application barely notices; only its surroundings change.

Choose it when the pressure is about where the system lives, not how it works — a data center closing, hardware end-of-life, an urgent need to exit a facility. It is fast, it is low-risk, and on a hard external deadline it is often the only responsible option.

Be honest about what it doesn’t do. Rehosting changes the address, not the architecture. Every reason the system was hard to change before — the coupling, the missing tests, the lost knowledge — moves with it. If you rehost and call the modernization done, you have a legacy system with a better hosting bill. Rehost earns its place as a bridge: it buys time and a cleaner cost base, after which you transform the parts that need it. As a destination, it disappoints.

Replatform: capture the easy operational wins

Replatforming is rehosting plus a handful of deliberate, low-risk adaptations to fit a modern runtime — a managed database instead of a self-run one, containers instead of bespoke deploys, object storage, a managed queue. The application’s logic is left alone; its operational envelope improves.

Choose it when the pain is in operating the system — too much infrastructure to babysit, poor scaling, high run cost — rather than in changing it. You get real, bounded benefits for modest, contained risk.

Its ceiling is the same as rehost’s, raised a notch. You have not touched the internal structure, so a system that was hard to change is still hard to change. Replatform is the sweet spot when operations hurt and the code itself is tolerable; it is the wrong tool when the business is blocked by what the system can’t do.

Refactor and rearchitect: make the system changeable

Here you change the inside. Refactoring restructures code while holding behavior constant — untangling dependencies, adding the tests that were never written, paying down the debt that makes every change slow. Rearchitecting goes further: it changes the structure and often the technology — a monolith split into bounded services, a synchronous tangle turned event-driven, a dead framework replaced — while still preserving what the system does.

Choose it when the business genuinely needs this component to evolve and the existing code is salvageable — the logic is sound even if the structure is tangled, and the domain knowledge encoded in it is worth keeping. This is the band that actually cures the legacy condition: it makes the next change cheap and safe, which was the whole point of modernizing.

The risk is precise and manageable. Preserving behavior is hard because the behavior includes edge cases nobody documented — the rule for the one odd customer, the quirk that handles month-end. Change the structure and miss one, and you have shipped a regression. The discipline that contains this is to capture the behavior first, change one bounded piece at a time, and prove each piece equivalent to the original before it carries live traffic — a parity gate. Refactoring without that proof is gambling with production. With it, refactor and rearchitect are the safest way to make a system you can’t change into one you can.

Rebuild: when the old code is beyond saving

Rebuilding re-implements the functionality from scratch on a modern stack. You keep what the component does and throw away how it does it.

Choose it when refactoring would cost more than starting over — the structure is so degraded that untangling it is a fool’s errand — or when the underlying technology has no viable path forward at all. In those cases, the existing code is a liability rather than an asset, and preserving it preserves the problem.

The trap is shape, not ambition. Rebuild done as a big-bang — the whole component (or system) replaced at one distant cutover — is the most reliable way to fail in this entire framework, for reasons that have nothing to do with the team’s skill. The rebuild chases a target that keeps moving as the old system changes; the business waits years for the first delta of value; the undocumented behavior gets rediscovered through production incidents; and the parity gaps surface after the sunk cost has already won the argument. The fix is not to avoid rebuilding — sometimes you must — but to rebuild incrementally, slice by slice, behind a strangler facade that lets the old and new run side by side with traffic shifting gradually. That turns the riskiest move into a series of small, reversible steps.

A worked example

Picture an order-management system flagged as legacy in Part 2. Run the four-way decision across its parts rather than the whole:

• The reporting module is stable, rarely changes, and runs fine — retain it for now, or replatform the database it sits on if operations are the only pain.
• The batch job that runs nightly is a maintenance burden but logically simple — replatform it onto a managed scheduler.
• The pricing engine is where the business wants constant new capability and is blocked by tangled code that still encodes valuable rules — refactor / rearchitect it in bounded slices, proving parity before each one ships.
• The custom notification service duplicates what a messaging product does better — replace it.
• The abandoned promotions module, built on a framework that died years ago and salvageable by nobody — rebuild it incrementally, only the parts still in use.

One system, four different answers. That is the normal, correct outcome — and it is exactly why “are we rehosting or rebuilding?” is the wrong question to ask about a whole system.

What the mix usually looks like across a portfolio

Zoom out from one system to the whole estate and a pattern repeats. The expensive moves, refactor and rearchitect and rebuild, are the minority. Most components are stable enough that the right answer is to retain them, rehost them onto a saner home, or replatform away the operational pain. Only a handful, the ones the business is actively blocked by, justify changing the code. A good modernization program has that shape. It lands most of its estate in the cheap, low-risk band and concentrates the expensive work on the few components that actually move the business.

The classic budget failure is the opposite. Treating a whole estate as a rebuild feels decisive, and it flatters the urge to do it properly, but it spends the highest cost and risk on components that never needed to change while starving the few that did. The inverse mistake, rehosting everything to look busy and cheap, leaves the business exactly as blocked as before, now with a bigger cloud bill. Getting that ratio right matters more than getting any single component’s move perfect.

The moves also combine over time, not just across components. Rehost first to clear a data-center deadline, then refactor the parts that need it once the fire is out, is a sound sequence rather than a contradiction. Read the four as a menu you draw from per component and per phase, never a single label you stamp on the whole program.

Not a substitute for understanding

This framework helps you reason about a decision; it does not make the decision for you, and it can be applied prematurely. You cannot reliably choose among these four for a component you do not yet understand — how the business depends on it, how much undocumented behavior it carries, how degraded the code truly is. Teams that assign moves from an org chart or a vendor’s checklist, before doing the analysis, routinely pick the expensive option for a stable component or the cheap one for the part that actually needed to change. The framework is downstream of understanding the system, never a substitute for it.

Where this leads

A per-component decision is the right unit of analysis — but a pile of correct per-component decisions is not yet a plan. You still have to sequence them: which slice goes first, what depends on what, where the early value and the early risk should land. Part 5, How to Build a Modernization Roadmap, turns this scatter of decisions into an ordered, fundable program.