Choosing between rebuild, replatform and refactor

Every engineer who inherits a legacy system wants to rewrite it. Sometimes they are right. More often the rewrite is the option that feels best and performs worst, because it front-loads all the risk and defers all the value.

Three options, honestly stated

Refactor in place

Lowest risk, continuous value, and it preserves institutional knowledge embedded in the code. It will not fix a fundamentally wrong data model, and progress is hard to communicate to non-technical stakeholders.

Replatform

Move the system to modern infrastructure without restructuring it. Solves operational cost and scaling; solves nothing about the application itself. Frequently the right first step because it buys time cheaply.

Rebuild

Justified when the domain model is genuinely wrong, when the platform is unsupportable, or when the business the system was built for no longer exists. Everything else is usually impatience.

The test that decides it

Ask what the system will be doing in five years. If the answer is broadly what it does now, refactor or replatform. If the answer is fundamentally different — new business model, new regulatory regime, new scale by an order of magnitude — rebuild becomes defensible.

If you do rebuild, strangle it

Route traffic through a facade, migrate one capability at a time, run both systems in parallel with reconciliation, and retire the old path only when the new one has been correct in production for a full business cycle. Big-bang cutovers fail in ways that are difficult to reverse.