Rewrite, refactor, or replatform?
Three ways to deal with software that has become hard to change, and how to tell which one your situation actually calls for. Usually it is not the rewrite.
The short answer
Refactor when the structure is wrong but the technology is fine. Replatform when the technology is the problem and the logic is sound. Rewrite only when the business rules themselves have changed beyond recognition, or when nobody alive understands what the software does. Rewrites are chosen far more often than they are warranted, because they are the easiest to quote and the most enjoyable to start.
Everyone involved has an incentive to recommend the rewrite. Engineers get a clean slate. Vendors get a bigger contract. The person proposing it gets to stop maintaining something they dislike. The only party without an incentive is the business, which pays for eighteen months of work to arrive back where it started.
Sometimes a rewrite is genuinely correct. It is rarer than the frequency with which it is proposed.
The short answer
| Refactor | Replatform | Rewrite | |
|---|---|---|---|
| You change | Structure | Technology | Everything |
| Behaviour | Identical | Identical | Redefined |
| Ships in slices | Yes | Usually | Rarely |
| Risk profile | Low, continuous | Medium, at cutover | High, all at the end |
| Correct when | Structure is wrong, tech is fine | Tech is the constraint, logic is sound | The rules themselves changed |
Refactor: change the structure, keep the behaviour
You improve how the code is organised without changing what it does. Consolidate the four places the same logic lives. Separate the thing that talks to the database from the thing that makes decisions. Add the tests that make the next change safe.
This is the right answer far more often than it is chosen, because it is unglamorous and hard to put on a slide. It ships continuously, carries almost no cutover risk, and can be stopped at any point with the value already banked.
- Choose it when: estimates have grown but the platform is still supported and the rules still make sense.
- Avoid it when: the framework is out of support and the security exposure is real.
Replatform: change the technology, keep the logic
The business rules are correct and hard-won. The thing they are written in is the problem: out of support, impossible to hire for, or unable to do something you now need, such as running on a phone.
The work is a translation exercise, and the danger is the quiet assumption that the old system is understood. It usually is not, and the undocumented behaviours are the ones people depend on. Budget for discovering them.
Where possible this should still ship in slices, with the old and new systems running alongside each other and traffic moving over gradually. A single cutover weekend is a decision to concentrate all your risk in the worst possible place.
Rewrite: change everything
Justified in two situations. First, the business has changed so much that the rules encoded in the software are no longer the rules you operate by, so preserving behaviour is actively wrong. Second, nobody understands what the software does, there is no documentation, and the original authors are gone, so translation is not possible because there is nothing to translate from.
Note what is not on that list: the code is ugly, the framework is unfashionable, or a new team dislikes the previous team’s choices. Those are refactoring problems wearing a rewrite’s clothes.
How to decide, in an afternoon
- 1List the five changes you most want to make in the next year.
- 2For each, ask what is actually blocking it: structure, technology, or the rules themselves.
- 3Count the answers. The majority tells you which of the three you need.
- 4If the answer is "we do not know what it does", that is its own finding, and it is the one case where a rewrite may be the cheaper path.
Whichever you pick, the test at the end is the same one: can somebody who did not build it change it? A rewrite that fails the Second Version Test has bought you a newer version of the same problem.