Sooner or later, almost every company faces the same question: the system that has carried the business for fifteen years is becoming a problem. The developer from back then is gone, every change takes weeks, and IT is pushing because the old versions no longer get updates. That is the normal case, not the exception: in a Lünendonk survey (2025) of more than 150 mid-sized and large companies, 62 percent said parts of their business-critical applications are so outdated they need to be replaced; in every second company, keeping the old systems running is no longer assured in the medium term. From here there are essentially three paths: rebuild everything from scratch, replace the existing system step by step, or switch to an off-the-shelf product. All three are legitimate. Which one fits depends less on technology than on your business – and on honest answers to a few uncomfortable questions.

Why “just rewrite everything” goes wrong so often

The full rewrite is the most intuitive answer and, in practice, the riskiest. The plan sounds clean: build the new system in peace, then switch over on a weekend. In reality, rebuilding a system that grew for fifteen years rarely takes less than a year and a half – and during that time the old system keeps running and keeps changing, because the business doesn’t wait. The new system ends up chasing a moving target.

Then there is the hidden knowledge: old code contains hundreds of special cases documented nowhere. The pricing rule for the biggest customer, the exception for orders from one particular region, the rounding fix from 2014. With a big-bang switch, every forgotten special case surfaces on the same day – the first day after cutover, when it fits worst.

Path 1: replace step by step while everything keeps running

The alternative to the big bang: the new system grows around the old one and takes over one area after another. First, a new interface layer sits in front of the old system as a facade, so all traffic runs through one place. Then, behind that facade, one module gets rebuilt – order management, say – and switched over while the rest notices nothing. Old and new compute in parallel for a while; discrepancies surface immediately. Only once nothing runs through the old module anymore does it get shut down.

This path fits when the system is business-critical and full of custom logic you cannot buy anywhere. It has an honest price: for the duration of the migration you operate two systems side by side, and the facade is effort that eventually disappears again. In return, the risk stays small at every point and every step is reversible – you buy safety with some overhead.

Path 2: the rewrite – when it is the right choice after all

There are cases where rebuilding is reasonable: when the old system is small – an Access database, say, or a tool with a handful of forms that one person can rebuild in a few weeks. Or when the technology is so dead that nobody can be found to touch it and the source code is missing anyway. Then you work from behavior: the database, the exports, and the screens show what the system does, and that gets rebuilt, tested, and this time written down.

Even then: the switchover itself should not happen on a single date but with a parallel phase and a fallback. The rewrite as a development strategy and the big bang as a cutover strategy are two separate decisions – you can build new and still migrate gradually.

Path 3: off-the-shelf software – the uncomfortable option you have to check

We build custom software for a living, yet this check belongs at the start of every modernization conversation: if your old system, at its core, does something every standard product can do today – invoicing, inventory, scheduling – then switching to a finished product is often the fastest and cheapest way out. The fact that the system was custom-built once doesn’t mean it has to stay custom; plenty of things were special requests in 2008 and are standard features in 2026.

The cross-check: count the places where your business genuinely works differently from what the standard product expects. If it is two or three edge topics, those can usually be solved around the product. If the difference runs through your core process, you will bend the standard product until you have paid the cost of custom development anyway – just spread across years and workarounds.

The three paths at a glance

Before the decision itself, the three paths side by side, as described above:

	Step-by-step replacement	Rewrite	Off-the-shelf
Fits when	Business-critical system full of custom logic	Small system, or dead technology without source code	The core process is a standard feature today
Risk	Small, every step reversible	High on a cutover date, smaller with a parallel phase	Bending the product until it costs like custom software
Honest price	Two systems in parallel, the facade disappears again	Rebuilding from behavior, plus testing	Workarounds, spread across years
Pace	Longer, but no standstill	Weeks for small systems, eighteen months and up otherwise	Often the fastest way out

The decision questions

In consulting conversations, the choice almost always comes down to the same questions:

How special is the core process? Buy the standard, build the special.
How big is the system really? Rebuild small systems, replace large ones step by step.
Do you have the source code and someone who understands it? Without both, rebuilding from behavior is the only option.
How long can operations stand still? If the answer is “not at all”, every cutover-date plan is off the table.
Who will maintain the system in five years? That answer drives technology and documentation choices, whichever path you take.

What stays the same on all three paths

However you decide: the data moves over completely, history included. Before any switchover, the old system’s behavior gets pinned down in tests – the quirks especially. You only switch once the new system delivers the same results in parallel operation, and the way back is part of the plan, not the emergency binder.

And at the end, the knowledge about the system should live in documentation, tests, and your team – not, once again, in a single head. Otherwise you will have this same conversation in ten years, just about a different legacy system.