In this article (11 sections)
Almost every company older than ten years has one: a system that works, that nobody wants to touch, built by a partner's nephew or by a company that no longer exists, and that something important depends on. It runs. And every time it needs a change, somebody says "careful with that one".
The temptation is to throw it out and build it again. That is, almost always, the worst option available. This piece explains why, what the alternatives are, what each one costs and how to decide which one applies.
Why rewriting from scratch goes badly
The full rewrite is the most intuitive strategy and the one that produces the most failed projects. The reasons are structural, not about execution.
The old system knows things nobody wrote down. Ten years of operation left dozens of rules inside it that were never documented: one customer's special discount, the validation that got added because something happened once, the odd end-of-month case. Nobody remembers them all. They surface one at a time, in production, after the new system has already replaced the old one.
The company can't stop while you rewrite. The old system still needs changes while the new one is being built. You end up maintaining two systems and paying twice.
You deliver no value until the end. A twelve-month rewrite is twelve months of spending with no benefit, and a cut-over date where everything changes at once. If that date slips —and it slips— the project starts losing internal support right when it needs it most.
Cut-over day is a high-risk event. Everybody learns a new system at the same time, with the business running.
None of this means rewriting is always wrong. It means it's the most expensive and riskiest option, and it's only justified when the others don't apply.
The five strategies, from lowest to highest risk
1. Leave it alone
This is a legitimate option and it gets dismissed too fast. If the system works, covers what it has to cover, and there's no important new requirement, modernizing it is spending money on a problem you don't have.
When it applies: the system is stable, somebody can maintain it, it has no serious security problems, and it isn't blocking anything the business wants to do.
2. Update the infrastructure without touching the system
Often the problem isn't the software but where it's running: a physical server in the office, an operating system past end of support, a database on a version that no longer gets security patches.
Moving the same system onto modern infrastructure, with automatic backups and monitoring, solves the most urgent risk —losing the data or being exposed— without touching a line of code.
Typical cost: USD 2,000 to 6,000. It's the best risk-to-benefit intervention there is, and it's almost always the right first step.
3. Put an API in front of it
The old system stays untouched, but you build a layer on top that exposes its data and its operations in a modern way. From then on, everything new gets built against that layer.
This is what unblocks most situations. You can have a mobile app, a customer portal, a dashboard, or an integration with another system, without having touched the core.
When it applies: the old system does what it does well, but it's sealed off and can't connect to anything.
Typical cost: USD 5,000 to 15,000, depending on how accessible the old system's database is.
4. Replace it in pieces
The strategy that works when you really do have to replace it. You pick one module, build its new version, put it into production, and the old system stops handling that. Then the next one.
During the transition the two run side by side, with the integration layer keeping them in sync. It's more total work than a single big-bang rewrite, and it's substantially less risky: every step delivers value, every step can be rolled back, and if the budget gets cut halfway through, what's already done still works.
Where to start: with the most independent module, not the most important one. You need the first replacement to go well so you can build internal confidence.
Cost: the cost of the new system, spread over time, plus 15% to 25% extra for the work of keeping both alive.
5. Full rewrite
When it's genuinely justified:
- The system runs on technology nobody you can hire still maintains.
- The data model is so wrong for the current business that any change means rebuilding it anyway.
- There's a legal or security requirement the system can't meet in any form.
- The business changed so much that the system models a company that no longer exists.
If none of those four apply, what you probably need is one of the earlier options.
How the decision gets made
Five questions, in order.
1. What concrete problem do you have today?
"It's old" isn't a problem. "We can't push invoices into our accounting system", "it goes down twice a month", "we can't give customers access", "the guy who maintained it retired" are problems. If you can't name the problem, the answer is to leave it alone.
2. What does not fixing it cost you today?
Hours lost, sales not made, penalties, the risk of losing data. If the annual cost of doing nothing is lower than the project, there's no case yet.
3. Can anyone maintain the current system?
If the answer is one person, you have a continuity risk that has nothing to do with the technology. And if that person is external, it's more urgent than it looks.
4. Is the database accessible?
This is the technical question that changes the plan most. If you can read the database directly, almost all the middle strategies are available. If the system is a black box with no access to the data, the options shrink a lot and the cost goes up.
5. Is what the system does documented?
If not, the first deliverable of any project has to be documenting it. And it has value on its own, whatever you decide afterwards.
What to do before anything else
Whatever the strategy, three things are worth solving first because they're cheap and they lower the risk immediately:
Automatic backups that have been tested. It isn't enough for the backup to exist: you have to have restored it. A backup that's never been restored is a hypothesis, not a backup.
Document the current behavior. Not the code: what the system does. Which processes it covers, which rules it applies, which reports it produces, who uses it and for what. You do it by interviewing the users, not by reading the code, and it's the raw material for any project that follows.
An inventory of integrations. What it connects to, what files it exports, what other system depends on it. It's very common to discover halfway through a project that a third party consumes a file the system generates every night and that nobody remembered.
The most common management mistake
Presenting modernization as a technical project. "We need to update the system" doesn't win budget or priority, because it doesn't answer any question management is asking.
What does work is tying it to something the company wants to do and can't do today: give customers access, open a second location, plug in a sales channel, meet a requirement from a large client. Modernization stops being a maintenance cost and becomes the thing that enables something valuable.
There's also a practical side effect: it defines the scope. Instead of "modernize the system", which has no edges, the project becomes "make X possible", which does.
In short
The right question isn't "do I rewrite or not?". It's "what's the smallest intervention that solves the problem I have today?".
In most cases that intervention is moving the infrastructure, securing the backups and putting an integration layer in front. With that, the old system stops being a risk and stops being a cage, for a fraction of the cost of rewriting it.
And if after that you still need to replace it, you'll be able to do it in pieces, with the system documented and without stopping the business.