When a system starts to hurt, the conversation about what to do with it collapses far too quickly into a single word: rewrite. It is the most dramatic option, the most satisfying to imagine, and the most expensive to get wrong. Before reaching for it, it helps to be precise about what the three real options are, because they solve genuinely different problems and carry genuinely different risks.
Three words that are not synonyms
Refactoring changes the internal structure of the code without changing what it does. You keep the same behaviour, the same platform, the same data — you make the existing thing cleaner, safer, and easier to change. Replatforming keeps the application largely as it is but moves it onto a better foundation: a supported runtime, a managed database, a container platform, the cloud. The behaviour is preserved; the ground underneath it changes. A rewrite throws the implementation away and builds the capability again, usually with a new architecture and often new technology. Only the rewrite discards the thing the business has already paid to learn — every edge case, every regulatory quirk, every hard-won fix that lives in the old code and nowhere else.
A framework for choosing
The right choice falls out of four honest questions. The first is about value: is this part of the system a source of competitive advantage, or is it undifferentiated plumbing? You refactor or rewrite where the business competes; you replatform, buy, or outsource where it does not. The second is about coupling: how entangled is this capability with everything around it? Tightly coupled code resists extraction, which pushes you toward in-place refactoring or a careful strangler approach rather than a clean rewrite. The third is about knowledge: does anyone still understand how this works? A system no one understands is the most dangerous possible rewrite candidate, because you cannot rebuild behaviour you cannot describe — there, the first job is to characterise the existing behaviour, not replace it. The fourth is about rate of change: code that changes constantly rewards investment in its structure; code that has not been touched in three years and works may not be worth touching at all.
The hidden cost of a rewrite
A rewrite's advertised cost is the engineering effort to rebuild the features. Its real cost includes three things that rarely make it into the estimate. There is the knowledge you throw away — the accumulated behaviour of a system that has survived contact with real users is an asset, and a rewrite discards it and rediscovers it the hard way, usually in production. There is the parallel-running tax — until the new system fully replaces the old, you run and maintain both, and that period is almost always longer than planned. And there is opportunity cost — the roadmap the business did not get while the team was rebuilding what it already had. None of this makes a rewrite wrong. It makes a rewrite a decision that should clear a high bar, not the default reaction to a system that has become uncomfortable.
Why the honest answer is usually "a mix"
In practice, almost no real system wants a single strategy applied uniformly. A mature platform is a portfolio: a differentiating core worth refactoring or selectively rewriting, a stable periphery that just needs a supported foundation underneath it, and commodity capabilities better replaced by something you buy. The most effective modernizations we run treat the decision at the level of the capability, not the system — refactor the part that changes weekly and matters, replatform the part that works but sits on an unsupported runtime, rewrite only the specific piece whose design actively prevents where the business needs to go, and leave the boring, stable parts alone. "Rewrite the system" is almost never the right sentence. "Here is the one strategy that fits each part of the system" is.