Legacy modernisation without a big-bang rewrite

Many mid-sized companies run on software that is ten or twenty years old: an Access database that became an ERP, a PHP application nobody dares to touch, a desktop tool that only works on one Windows version. It still does its job, but every change takes weeks, the original developer has left, and security updates stopped long ago.

The tempting answer is a complete rewrite: build the new system next to the old one, switch over on one weekend, done. In practice, this "big bang" is one of the riskiest projects a company can start. This article explains why, and how to modernise step by step instead.

Why big-bang rewrites fail

• The old system knows more than anyone thinks. Years of special cases, workarounds and business rules live in the code, not in any document. A rewrite has to rediscover all of them, usually by getting them wrong first.
• Nothing is delivered for a long time. For one or two years the business pays for a new system and gets no benefit, while the old system still needs maintenance.
• The target keeps moving. The business keeps changing while the rewrite is under way. By launch day, the new system is already behind.
• The switch-over is all or nothing. If the new system has problems on day one, everything has problems on day one.

The alternative: modernise in slices

The idea is simple: replace the old system piece by piece while it keeps running. Each step delivers value and can be rolled back. Developers call this the strangler pattern, after a plant that grows around a tree until it can stand on its own.

Step 1: understand what you have

Before changing anything, map the current system:

• Which functions are used daily, rarely or never? Usage data often shows that a third of the features can simply be retired.
• Where are the pain points: slow processes, manual double entry, missing interfaces, security risks?
• Which data is where, and how clean is it?
• Which other systems depend on it?

Result: a map of modules ranked by business value and risk.

Step 2: put an API in front

Create a modern interface (API) between the old system and everything else. New applications, such as a customer portal or a mobile app, talk only to this API, never directly to the old database. Behind the API, the old system keeps doing the work for now.

This one step often brings quick wins: a web portal or an app for field staff can go live within weeks, without touching the core.

Step 3: replace module by module

Pick the module with the best ratio of value to risk and rebuild it behind the API. When it is ready, route the traffic for that function to the new module. The rest still runs on the old system. Repeat.

Good first candidates are modules that change often, cause the most support work, or block new features. Leave stable, rarely used parts for last, or retire them.

Step 4: migrate data continuously

Data migration is where most modernisation projects hurt. Do not plan one big migration at the end. Instead:

• Clean data before you move it: duplicates, inconsistent formats, orphaned records.
• Synchronise data between old and new for a transition period, so both sides stay consistent.
• Migrate and verify module by module, with automated checks that compare counts and totals.

Step 5: switch off the old system

When the last important module has moved, the old system becomes read-only, then an archive, then it is switched off. Keep archived data accessible as long as statutory retention periods require, for example for invoices and accounting documents.

What a realistic roadmap looks like

For a typical mid-sized business application:

1. Analysis and target architecture: two to four weeks. Result: module map, target architecture, roadmap and budget.
2. API layer and first quick win: six to ten weeks, for example a portal or an app on top of the old system.
3. Module replacement: one module every two to four months, depending on size.
4. Decommissioning: once the core modules are replaced.

Each phase delivers something usable. You can pause, re-prioritise or change direction after every step.

Technology choices

Choose boring, proven technology with a long future: a typed back end (for example TypeScript or Python), a relational database such as PostgreSQL, a web front end with a mainstream framework, and cloud hosting in the EU or on your own servers. Avoid niche technologies that only one developer understands, because that is how today's modern system becomes tomorrow's legacy.

Typical mistakes

• Copying the old system one-to-one. Use the modernisation to simplify processes, not to rebuild every workaround.
• Ignoring the users. Involve the people who work with the system every day; they know where the real problems are.
• No tests for the old behaviour. Before replacing a module, write tests that describe what it does today. They protect you from silent changes in business rules.
• Underestimating data quality. Budget time for cleaning data. It always takes longer than expected.

Conclusion

Modernising step by step is less spectacular than a rewrite, but much safer. Each slice delivers value, risks stay small, and the business never has to stop. We help mid-sized companies analyse old systems, build the API layer and replace modules one by one. See our custom software development page or talk to us about your system.

Talk about your legacy system