Most companies that have been running for more than a few years have one: the system nobody wants to touch. It still works. It still processes the orders, or the invoices, or whatever it was built for. But every change request now comes with a sharp intake of breath, a two-week estimate for something that sounds like a one-day job, and a quiet worry that fixing one thing will break three others.
At that point you have two obvious options — modernise what's there, or replace it — and a third that most people never seriously consider. Here's how to tell them apart.
"Legacy" isn't about age
A system isn't legacy because it's old. It's legacy when the cost of changing it no longer matches the value of the change. Plenty of ten-year-old systems are perfectly maintainable. Plenty of three-year-old ones aren't, because they were rushed, the person who built them left, and nothing was written down.
The practical test: how long does a small, well-understood change take today compared to two years ago? If a one-line business rule now costs a week and a nervous Friday release, the system is holding you back regardless of the year it was written. That slowdown is what technical debt feels like from the business side.
When refactoring is the right answer
Refactoring means changing how the software is built without changing what it does: add tests first, break up the modules everything depends on, replace dead dependencies, move to a supported framework version. Unglamorous, and usually the cheaper, lower-risk route.
It's the right call when:
- The business rules inside it are still correct and still valuable — you'd only reimplement them anyway
- The platform is still supported and you can still hire people who know it
- The pain is concentrated in a few modules rather than spread through everything
- The data model still matches how the business works today
When a rebuild is the honest answer
Sometimes the foundation is the problem, and no amount of tidying fixes it. Rebuild when:
- The platform is at end of life with no upgrade path — an unsupported framework or a database version that no longer gets security patches isn't a maintenance issue, it's a compliance one
- Nobody can run it anymore — incomplete source, no working build, one contractor who is unreachable
- The data model is wrong, because the business changed shape and the software never did, so every new requirement gets bolted on sideways
- Every change touches everything, so the test effort for a small feature is larger than the feature
One warning: a rebuild resets your risk clock. You're reimplementing years of undocumented decisions, and while you do it the old system still has to run and still has to be maintained. Budget for both, in parallel, for the whole migration period. That double-running cost is the line most rebuild plans leave out.
The option most people skip: strangle it
You don't have to choose between "leave it alone" and "replace it all at once." The middle path is to put a thin layer in front of the old system and move one capability at a time behind it. Reporting moves out first, then invoicing, then order entry. Old and new run side by side; users see one application.
It costs more in total engineering than a clean rebuild, and it needs discipline to avoid living in a half-migrated state forever. In exchange you get something valuable every quarter, no big-bang cutover weekend, and the ability to stop halfway if priorities change. For a system that runs daily operations, that trade is usually worth it.
The part everyone underestimates: the rules nobody wrote down
The hardest thing to take out of a legacy system isn't the code — it's the behaviour that only exists in the code. The discount that applies to one customer for historical reasons. The overnight job that quietly fixes bad records. The field that means something different when it's empty.
Then there's the data. Fifteen years of records with three spellings of the same supplier, test entries that made it into production, and columns that were repurposed twice. Reserve 15–30% of a rebuild budget for migration and cleanup alone. Whichever route you take, get those rules on paper first — that's exactly what a proper discovery phase is for.
What each route costs
- Targeted refactor: €10,000–€40,000, phased, delivered in weeks. The best value per euro when the foundation is sound
- Strangler migration: €60,000–€150,000 spread over 12–24 months, with working software throughout
- Full rebuild of a mid-sized line-of-business system: €80,000–€250,000 over 4–12 months, plus the cost of keeping the old one alive meanwhile
Note what that comparison implies: the cheapest sensible move is often to spend €15,000 on a focused refactor now, and make the rebuild decision a year later with better information and a system that's easier to reason about.
Five questions that settle it
- Can we still get people who know this stack in three years?
- Are the business rules inside it still correct?
- Is the data model shaped like the business we run today?
- What do we spend per year just keeping it alive — licences, hosting, workarounds, manual corrections?
- What does a day of downtime cost us mid-migration?
Yes to the first three: refactor. If questions 1 and 3 are both no, a rebuild isn't really optional — it's only a question of when, and how gradually.
Not sure which side you're on?
A short technical assessment — a few days, not a project — usually settles this with numbers instead of opinions. Get in touch and we'll look at what you have, what it's costing you, and which of the three routes actually fits.