Sooner or later you hit the point where the old system is more burden than support: an in-house build from twelve years ago whose developer left long ago. An Access database that only runs on one particular machine. An industry tool the vendor no longer maintains. You know you have to deal with it — but the thought of "what if everything grinds to a halt during the switch?" holds you back. That's exactly what this is about: how to replace and migrate legacy software without putting day-to-day operations at risk.
The short version
- When to replace: Five checkable signals — unsupported runtime, unreliable database, one person who understands it, Excel export as the only interface, the system dictating your processes.
- The safe way: Replace piece by piece with the strangler pattern — never one big-bang cutover.
- Start here: Tackle the biggest pain point first, run new and old in parallel, then migrate area by area.
- Protect your data: A clean migration with a dry run and reconciliation makes sure nothing gets lost.
- Bring the people: Involve daily users early — the best migration fails if nobody adopts it.
What does "legacy software" actually mean?
Legacy software isn't simply "old" software. What matters is that it's critical to your operations but barely maintained, developed further or understood anymore. Typical cases:
- In-house builds with nobody looking after them: Built internally or by a freelancer years ago — and nobody knows the code today.
- Standard software that's no longer maintained: The vendor no longer exists or has discontinued the product, and there are no security updates.
- Access and Excel solutions that outgrew themselves: What started as a spreadsheet is now the company's unofficial operating system. (We have a separate article on replacing Excel with custom software.)
- Outdated technology: An application that only runs on an old Windows version, a specific browser or a single server.
The tricky part: as long as it "works somehow", the urgency doesn't register. The risk grows every day regardless.
When to replace legacy software: five signals
Not every old system has to go immediately. But there are five findings we see over and over when we take a project over, and each one is a hard signal rather than a gut feeling. You can check them yourself without being a developer.
1. The runtime no longer gets security updates. The toughest one, because it's objectively verifiable. Ask your provider or admin for a number: which PHP, .NET, Java or Windows Server version is running? Then look up whether that version is still officially supported. If it says "end of life", your system gets no security patches anymore — including for holes that become public tomorrow. With personal data involved, that's not just technical, it's a liability question.
2. The database has no structure you can rely on. Missing foreign keys, dates stored as text, the same customer number in three spellings, fields called notes2. As a non-technical person you notice it because reports never quite add up and nobody can explain why. Databases like that are the reason "just change one small thing" takes days: every change can break something in a place nobody has on their radar.
3. Exactly one person still understands it. Sometimes it's a colleague close to retirement, sometimes an external developer who's hard to reach. The test is simple: if that person is out for two weeks, can anyone still fix a bug? If the answer is no, that's not a staffing issue, it's a business risk with a countdown.
4. The only way to get data out is an Excel export. A reliable sign that the system is sealed off. In practice it means every connection to another system runs through a human who exports, reworks and re-imports somewhere else — daily, weekly, forever. How modern systems solve this instead is in API integration: connecting your systems.
5. The system dictates your processes instead of supporting them. No mobile access, no way to model a second location, no new pricing logic without custom programming. When decisions in your company depend on what the software allows, you've reached the point.
If barely any of that applies and the software quietly does its job, targeted upkeep is the smarter choice — and we'll say so honestly; what a well-kept system looks like is in why software maintenance matters. Where the signals pile up, though, patching on is just expensive procrastination: you keep paying for workarounds and carry the risk on top.
The risks of replacement — and how to defuse them
The fear of switching is justified, but every one of the typical risks can be managed:
- Business interruption: The biggest bogeyman. The answer is precisely not to switch everything over overnight, but to go step by step (more on that in a moment).
- Data loss: Old systems are full of historical data. A clean migration with a dry run and reconciliation prevents anything from getting lost.
- Hidden knowledge: Old software often contains special rules that are documented nowhere. Before we replace anything, we make that knowledge visible.
- Buy-in from the team: The best new software is useless if nobody uses it. Involving the people who work with it daily, early, is mandatory.
Legacy software replacement step by step: the strangler pattern
The most dangerous route is the "big bang": rebuilding everything in the background for months and switching over completely on one cut-off date. If something goes wrong, operations stop — and that's exactly what you want to avoid.
The safe alternative is called the strangler pattern (named after the strangler fig, which slowly grows around a tree until it replaces it). It sounds technical but it's simple: instead of replacing everything at once, you build the new system around the old one piece by piece — switching over one area at a time.
Here's what that looks like in practice:
- Take the biggest pain point first. We look for the part of the old system that causes the most grief or carries the highest risk, and replace exactly that first.
- Run new and old in parallel. The new component takes over a clearly bounded area, the rest keeps running unchanged. Both access the same data where necessary.
- Take over more, step by step. Once the first area runs stably, the next one is up. With every step, the old system shrinks.
- Switch off the old tree at the end. When the last area has moved, the legacy software can finally retire.
The big advantage: you see first results within a few weeks, the risk gets spread across many small steps instead of one risky cut-off date — and if a step does hit a snag, it only affects one area, not your entire operation.
Top tip
Have a fallback option built for every switchover step: as long as the new and old areas run in parallel for a short while, you can switch back immediately if in doubt. That "safety line" costs little and takes the fear out of the transition.
What a replacement costs and how long it takes
The two questions everyone asks first — with numbers instead of evasion:
A first scoped cut along the strangler pattern (one module out, rebuilt cleanly, wired back into the old system) starts at €3,900 with us. A full replacement with several modules, roles and integrations starts at €11,900. An additional integration to the legacy system is from €1,900, taking over existing Excel data from €690, everything else by effort at €79/h. After the switch, support starts at €119/month. How those amounts come together and what drives them up in a specific case is broken down in what does custom software cost?.
On timing: the first cut is a matter of weeks, a full replacement of a grown system takes months — and that is the point of the approach, not a flaw. Replace everything at once and you have one date where everything must work. Replace in steps and you have many small dates, each of which is manageable.
What really drives the schedule is rarely the programming: it is the undocumented edge cases nobody remembers, and the availability of the people who actually know the process. Book their time in advance — that is the bottleneck.
Moving the data: what comes along, what gets cleaned, what stays behind
The data is often the most valuable thing about the old system: customers, orders, documents, years of history. A data migration is more than "export table, import table" — and the most important decision happens before any of it, namely these three categories:
What comes along. Everything needed in day-to-day work or subject to retention requirements: active master data, open transactions, documents inside the statutory retention period, the history someone may need to rely on. That data moves over in full and gets verified.
What gets cleaned. The part almost everyone underestimates. Grown systems reliably accumulate the same problems over the years: duplicates from customers created twice, "last name, first name" crammed into one field, dates in three formats side by side, amounts with and without thousands separators, free-text fields that actually hold three pieces of information. Carry that over unfiltered and you'll have the same reporting problems in the new system as in the old one — just more expensively.
What stays behind. Not everything has to come. Twelve years of log data, orphaned test records, intermediate states from a process that no longer exists: that belongs in an archive, not in the new system. We recommend a readable export of the old data set that gets kept and makes you able to answer questions if needed — without starting the new system loaded with ballast.
The process itself has four steps, and we skip none of them:
- Review and clean up what's there. Count first, then tidy: how many records are there, how many are duplicates, how many have required fields empty?
- Map the fields cleanly. Which field in the old system corresponds to which in the new one — and what happens to fields that have no counterpart? With Access and Excel solutions especially, the devil is in the details.
- Dry run in a test environment. We migrate there first and check samples before anything goes live. That run usually gets repeated several times until it comes out clean.
- Reconcile instead of hoping. Do the counts and totals match before and after? The migration is only done once the numbers line up.
That diligence is the difference between a calm transition and one where somebody asks three weeks later where the orders from 2021 went. It's also why we list the data migration as its own line item instead of letting it disappear into a lump sum — what's behind that for spreadsheet data is spelled out in replacing Excel with custom software.
Common pitfalls we see again and again
- "Let's replicate everything 1:1 for now." A replacement is your chance to get rid of entrenched workarounds — not to cement them in new clothes.
- Forgetting the last step. Some projects stall halfway, and then the old system keeps running forever for one remaining area. Plan the shutdown in from the start.
- Underestimated integrations. The old system often hangs off more third-party systems than you'd initially think. Those dependencies belong on the table early.
- Forgetting the people. Without training and without bringing along the people who work with it daily, even the technically best migration fails.
What you end up with
A modern, custom-built replacement belongs to you, is documented and maintainable — still in five years, whether we or your own team carry on with it. It gets security updates, can be connected to your other systems and grows with you instead of holding you back. Above all, your operations no longer hang off an old machine or a single person.
Got a system like that whose replacement you've been avoiding for years? Let's take a look together in a free initial consultation — we'll tell you plainly whether cutting over is worth it and what a safe, step-by-step first move looks like for you.
What we build in these projects is on our custom software page; how a project runs with us is in our process. If you want to know whether the cut is worth it in your case, write to us — we will give you a straight answer.
Frequently asked questions
When is it worth replacing legacy software?
When several things come together: nobody can maintain the system anymore, there are no more security updates, every small change turns into a gamble, the system is holding back your growth, or everything depends on one single person or one single machine. If barely any of that applies and the software quietly does its job, targeted upkeep is often the smarter choice.
How do you replace old software without downtime?
With the strangler pattern instead of a big-bang cutover. You take the biggest pain point first, run the new component in parallel with the old system, and then move area by area until the legacy software can retire. You see first results within a few weeks, and if a step hits a snag it only affects one area, not your whole operation.
What happens to the data in the old system?
It comes along — but properly. We clean up duplicates and dead records first, map the fields between old and new, migrate into a test environment as a dry run, and then reconcile counts and totals. The migration is only done once the numbers line up on both sides.
Isn’t it cheaper to just keep patching the old system?
Sometimes, yes — and we’ll say so honestly. But if a small adjustment takes days or breaks something elsewhere, the cheap old solution has long been eating more money than a rebuild would. Where the risks are piling up, patching on is usually just expensive procrastination.
How does the data migration from the old system work?
In three categories and four steps. First you decide what comes along (active master data, open transactions, documents under retention rules), what gets cleaned (duplicates, inconsistent date and number formats, free-text fields holding several pieces of information) and what only belongs in an archive. Then come the inventory, the field mapping, a dry run in a test environment and the reconciliation of counts and totals. Taking over existing Excel data starts from €690 with us.