The system still works. It also runs on something unsupported, only one person understands it, and every change takes three weeks. At some point the risk of leaving it exceeds the cost of doing something, and the question becomes which of three things to do.
Replatform: move it, do not change it
What it is: lift the application onto supported infrastructure with minimal changes to the code. Same behaviour, newer foundation.
Best when: the software does what you need and the problem is the platform underneath it — an operating system going out of support, hardware you cannot replace, a data centre you are leaving.
Cost and risk: the cheapest and least risky of the three. Users may notice nothing at all, which is the point.
The catch: you have bought time, not solved the underlying problem. The code is still hard to change and still understood by one person. Do this deliberately as a stopgap, with a plan for what follows.
Refactor: keep it, improve it in place
What it is: restructure the existing code incrementally — improving the parts you touch most, adding tests, and separating tangled components — while it stays in production.
Best when: the business logic is valuable and hard-won, the system is broadly correct, and you can afford a steady investment rather than a large one.
Cost and risk: moderate and spread out. Lower risk than a rewrite because you are never far from a working system.
The catch: it requires sustained commitment. Refactoring that stops halfway leaves you worse off than before, with two half-architectures instead of one bad one. It also needs a team willing to work inside old code, which not everyone is.
Replace: build something new
What it is: a new system, then migrate to it.
Best when: the business has genuinely changed and the old model no longer fits; the technology is so obsolete that nobody can maintain it; or the system cannot meet a requirement you now have — security, accessibility, integration — at any reasonable cost.
Cost and risk: the highest of both, by a distance. It is also the option people reach for first, because a clean start is more appealing than reading someone else's code.
The catch — and it is a big one: the old system encodes years of exceptions, edge cases, and rules nobody wrote down. Rediscovering them is most of the work, and you will discover them one at a time, in production, from annoyed users. Budget for that discovery explicitly.
How to choose
Four questions, in order:
- Is the problem the platform or the software? Platform only → replatform. That is the whole answer.
- Does it still do the right things, just badly? Yes → refactor. The logic is the asset; keep it.
- Has the business outgrown the model itself? Yes → replace. No amount of restructuring fixes the wrong shape.
- Can you tolerate a long project? If not, replatform now and plan properly for later. A rushed replacement is the worst outcome available.
The hybrid that usually wins
The most successful modernizations rarely pick one. They replatform first to stop the bleeding, then strangle the old system gradually — building new functionality alongside it and moving one capability at a time, with both running until the old one is empty.
It takes longer on paper and is dramatically less risky, because there is no single day on which everything must work. For anything the business genuinely depends on, that property is worth a great deal.
Whichever route you take
Document the rules before you touch anything. Sit with the people who use it, watch them work, and write down every exception they mention in passing. That document is the most valuable artifact of the entire project and it is the one most often skipped.
And budget the data migration separately and generously — it is reliably the largest surprise, as our cost breakdown covers. Public-sector modernization has its own constraints; the case-management modernization case study walks through one.
We handle all three routes under application development, and a replatform usually runs alongside cloud and infrastructure work.
Tell us what the system is and why it hurts — the right route is usually clear within a conversation.