"Should we just rebuild it?" is one of the most expensive questions a company can answer wrongly. Rewrites are seductive — a clean slate, modern tools, no legacy baggage — but they are also where budgets and timelines go to die. Here is a practical framework for deciding between maintaining, modernizing and rewriting a system your business relies on.
Start with the business question, not the technical one
Before discussing code, answer this: what does the business need from this system over the next three years? Stability and lower running cost point toward maintenance. Significant new capabilities point toward modernization. A fundamental change in what the system must do — a new business model, a new market, a new scale — is the only situation that genuinely justifies a rewrite.
The four honest options
- Maintain — keep it running, secure and current. Best when the system does its job and the cost of change is the main concern.
- Modernize incrementally — replace parts over time (see the strangler-fig approach) while the system keeps running. Best when you need new capabilities but cannot accept downtime or risk.
- Re-platform — move to better infrastructure (e.g. cloud) without rewriting the logic. Often the fastest way to cut cost and improve reliability.
- Rewrite — rebuild from scratch. Highest cost, highest risk, longest time to value. Justified only when the business has fundamentally outgrown the system.
Questions that reveal the right answer
How often does the system actually need to change? If rarely, maintenance is almost always right. How much of its value lives in undocumented edge cases? The more there is, the more dangerous a rewrite becomes, because those cases are exactly what gets lost. What is the real cost of the current system — not just licences, but cloud spend, incident time and the opportunity cost of slow changes? And critically: if you rewrite and it goes wrong, can the business absorb that?
Why the rewrite is usually the wrong default
A rewrite asks you to reproduce years of accumulated business logic, hit feature parity before you can switch over, and run two systems in parallel during a long transition — all before delivering a single new benefit. Studies of large rewrites consistently show overruns and abandoned projects. The alternative — disciplined maintenance plus targeted modernization — delivers value continuously and keeps risk contained.
How we help you decide
Dink's technology assessment exists precisely for this decision. It is a fixed-scope, CTO-led review of your platform, costs, resilience and operations that ends in a prioritized plan — savings first, risk reduced. You walk away knowing whether to maintain, modernize or, occasionally, rebuild, and you are free to execute that plan with us or anyone else.