www.simplify-data.de
Many companies run software that was developed ten or twenty years ago and still supports core processes today. It works, but every change gets more expensive, and hardly anyone still knows their way around it. This article explains why a complete rewrite is rarely the best answer and how step-by-step modernisation succeeds.
What is legacy software?
Legacy software refers to systems that have grown over time, are business-critical and rely on outdated technology. It might be an Access database, an in-house desktop application, a customised inventory system or a web application written in a language for which skilled developers are becoming scarce.
Age alone is not the problem. It becomes critical when several of the following apply:
- The operating system, database or framework no longer receives security updates.
- Knowledge of the system rests with a single person or a provider who is no longer available.
- New requirements, such as an integration with the online shop or mobile access, cannot be implemented, or only with great effort.
- Data has to be transferred by hand between the legacy system and other programs.
- The software only runs on specific, outdated machines.
Why a complete rewrite is tempting and risky
The obvious idea is: we rebuild everything, modern and clean, and switch off the old system on a fixed date. In practice, this approach, often called a "big bang", carries considerable risks.
- Hidden logic: over the years, legacy systems accumulate countless special rules that are documented nowhere. Many only come to light when they are missing in the new system.
- A long dry spell: it often takes many months before the new system is finished. During that time the old system still has to be maintained, and the business sees no benefit yet.
- A moving target: requirements change during development. The new system lags behind the business before it even goes live.
- A risky cut-over date: if something goes wrong on switch-over day, the entire operation may come to a halt in the worst case.
The alternative: modernise step by step
A proven approach is what software developer Martin Fowler described as the "strangler fig" pattern, named after a plant that grows around a host tree until it eventually replaces it. Applied to software, this means new components are built alongside the legacy system and gradually take over its tasks.
The advantage: every step already delivers value, the risk is spread across many small changes, and the legacy system stays in operation until it is no longer needed.
How step-by-step modernisation works
1. Take stock
First, the legacy system needs to be understood. Which features are actually used, by whom and how often? Where does which data live? Which other systems are connected? Talking to users, looking into the database and, if available, the source code all help.
This often reveals that a significant share of the features is rarely or never used anymore. Those parts do not need to be rebuilt.
2. Make the data accessible
An important early step is an API that exposes the legacy system's data. New applications can then read and write without touching the old code. It is also worth checking data quality at this stage and cleaning up duplicates and obsolete records.
3. Choose the first building block
Start with an area that is clearly defined and delivers noticeable value. That might be a report that is currently assembled laboriously in Excel, a customer portal or mobile access for field staff. An early success builds trust within the team.
4. Build, run in parallel, switch over
The new component is developed and initially run in parallel with the old system. Only once it works reliably do you switch over. For web applications, this is often done with a component placed in front that routes requests either to the old or to the new system.
5. Repeat and decommission
Area by area, functionality moves to the new system. In the end, little of the legacy system remains, and it can be switched off in a controlled way. Archive data is secured beforehand so that retention obligations continue to be met.
Complete rewrite versus step-by-step modernisation
| Aspect | Complete rewrite | Step-by-step modernisation |
|---|---|---|
| First benefit | only after completion | after the first building block |
| Risk | concentrated on the cut-over date | spread across many small steps |
| Budget | one large upfront investment | spread over a longer period |
| Flexibility | changes during development are difficult | priorities can be adjusted continuously |
| Parallel operation effort | low, but only briefly | higher, because old and new work together for a while |
The step-by-step route is not right in every case. For very small systems, or when the legacy system technically allows no integration at all, a rewrite may be simpler. It should then be prepared with particular care.
Checklist for getting started
- List the features in use and who uses them
- Document dependencies on other systems and data flows
- Assess the security situation: do all components still receive updates?
- Identify the people who hold knowledge and record it while it is still available
- Back up the data and check its quality
- Define a first modernisation building block with clear value
- Set success criteria, for example less manual work or shorter processing times
- Plan the budget in stages rather than as one large block
Avoiding common mistakes
A frequent mistake is rebuilding the old system one to one, including all the workarounds that crept in over the years. Use the modernisation to question your processes. A second mistake is involving users only at the end. The people who work with the software every day know best where things go wrong.
Finally, the new system should be built so that it does not become a problem again in ten years: with documentation, automated tests and technology that will have skilled developers and updates for the long term.
Modernisation with Simplify Data
Simplify Data, based in Kiel, Germany, helps companies in Schleswig-Holstein, Hamburg and remotely across Germany analyse grown systems and move them step by step into modern applications. We start with an assessment and turn it into a roadmap of manageable stages. Learn more on our software development page.