Legacy software: modernise or rewrite?
You probably know the situation. The application your business runs on every day was written ten or more years ago. It works, but nobody dares touch it. The original developer left long ago, the framework version is out of support, the server needs an upgrade the app will not survive, and every small change takes weeks.
Then the question lands on the table: fix the old one, or throw it away and build something new?
Over the past years I have restored several applications more than ten years old, in both the public and the private sector. In none of those cases was the answer "throw it away". That does not mean a rebuild is always wrong — sometimes it really is cheaper. Below are the criteria I use to make that call.
Why "let's rewrite everything" is so tempting
Reading old code is hard and writing new code is fun. A new project promises a clean slate: modern technology, a tidy structure, everything the old system gets wrong.
The catch is that an old application is not just code. It is ten years' worth of business rules. Every odd if statement nobody understands any more was probably added for a reason: a special case for one customer, a change in legislation, a request from accounting, a bug that appeared one New Year's Eve. Those rules are not written down anywhere. They live only in the code.
Rebuild from scratch and every one of those rules has to be rediscovered — usually after the new system has gone live and something breaks.
Why big-bang rewrites so often fail
A large rewrite tends to fall into the same few traps, project after project:
- A moving target. The old system does not stand still while the new one is built. The business keeps needing changes, and they have to be made twice — or not at all in the old system, which frustrates users.
- A long stretch with no value. Months of work the user never sees. If budget or patience runs out before the end, you are left with a half-built new system and the old one still in production.
- Data migration. Ten years of data is always messier than anyone expects: broken records, duplicate customers, fields used for something other than their original purpose.
- All or nothing. One day you switch over, and if something fails there is nowhere to go back to.
What step-by-step modernisation means
The other route is to keep the application running and replace its parts one at a time. That is how I approached the old applications I have restored:
- Understand it first. The app is brought up in a separate environment and reviewed: versions, dependencies, where the data lives, what is critical.
- Tests before changes. The most important workflows are covered by tests that check the app behaves exactly as before. They are the safety net for everything that follows.
- One version at a time. Language, framework, libraries and database are moved to newer versions component by component. Each step is small, testable and reversible.
- Functionality is preserved. For the user nothing changes — same workflow, same data, just faster and secure.
- Then new features. Only once the foundation is modern do new features get built. They are affordable again, because the code is readable and the tests protect it.
The biggest advantage is that value arrives early and risk stays small. Every stage ends with a working system. If the budget runs out at some point, the app is still in better shape than when you started.
Honest criteria: when to modernise and when to rebuild
The answer depends on five things.
Value of the business logic. If the app holds a lot of logic specific to your business — calculation rules, special cases, workflows — that weighs heavily towards modernising. If it is essentially a simple data-entry form, there is little to lose.
Code quality. Old does not mean bad. Code that was written carefully ten years ago is often very upgradeable. If it is tangled — database queries in the middle of HTML, the same logic copied into ten places — every step gets expensive.
Data. Data almost always outlives code. If the data model is sound, either route can build on it. If the data model is itself the problem, it has to be solved either way.
Budget and timeline. Gradual modernisation can be split into stages and paused. A rebuild usually needs the full amount before anything reaches users.
Risk. If downtime costs money or stops people from working, the gradual route is almost always the safer one.
When a rebuild really is cheaper
There are cases where I will tell you myself that modernising is not worth it:
- The technology is so dead that there is no newer version or tooling, and every component would have to be rewritten anyway.
- The business has changed so much that the old app solves a problem you no longer have.
- The app is small and its logic fits on a couple of pages — writing it fresh is quicker than untangling the old one.
- A ready platform covers the need. For an online store, inventory and bookings, for example, a custom system often makes no sense when something like NUNDINAE already exists.
Even then, the old system is worth analysing before anything new starts — precisely to get those hidden business rules written down.
If the old system is actually a website, the same principle applies: a rebuild is possible, but it has to be done without losing what already works. I covered that in a separate post on redesigning a website without losing SEO.
How I start
The first step is always a review: I go through the application, its versions, data and server, and tell you in writing what I see. That is also where the answer to the main question comes from — modernise or rebuild — with the reasoning behind it. If the app holds confidential information, an NDA is perfectly normal.
More about what I do and how is on the software modernisation page.
Do you have an application nobody dares touch? Describe your situation in a couple of sentences here — what the system is, how old, and what is worrying you right now. I reply within one working day and tell you honestly whether and how I can help. If you would rather just write, all my details are on the contact page.
Does the application have to go offline during modernisation?
Usually not. The work happens in a separate environment, and the live version is swapped only once the new one has been tested. The switchover is short and planned.
What if there is no original developer and no documentation?
That is the rule rather than the exception. The code itself is the documentation — it just takes time to read. The tests written at the start also describe how the app really behaves.
Can it be developed further afterwards?
Yes, that is the whole point. Once the foundation is modern and covered by tests, new features can be added just as in a new application.
