Many businesses depend on software written ten, fifteen or twenty years ago. It might be a desktop application built by a developer who has since retired, a system written in a language few people still use, a heavily customised package whose vendor no longer supports it, or an accumulation of Access databases and Excel macros that grew into the company's operating system. It still works — mostly. But each year it becomes harder to change, harder to support and harder to connect to the rest of the business. Legacy software modernisation is the process of moving away from such systems without disrupting the business that depends on them.
This guide is for owners and managers responsible for an ageing system. It explains how to assess it honestly, the four main options, why "rewrite everything" is often the riskiest choice, how incremental modernisation works, and how to plan the journey.
What makes software "legacy"
Age alone does not make software legacy. Some old systems are stable, well understood and fit for purpose. Software becomes a liability when it can no longer change at the speed the business needs. Typical symptoms:
- Knowledge risk. Only one person — or nobody — fully understands how it works.
- Technology risk. The programming language, database or operating system is out of support, with no security updates.
- Change paralysis. Small changes take weeks and often break something else.
- Integration barriers. It cannot easily exchange data with newer systems, websites or mobile apps.
- Access limits. It runs only on office desktops, so field staff, branches and customers cannot use it.
- Workarounds. Staff maintain parallel spreadsheets because the system cannot do what they need.
- Performance and reliability. It slows down as data grows, or fails in ways that are hard to diagnose.
If several of these apply, the cost of standing still is probably already higher than it appears.
Step 1: Assess the system honestly
Before choosing a path, understand what you have. A structured assessment looks at the system from four angles.
Business value
Which business processes depend on it? Which functions are used daily, which occasionally, which never? Many legacy systems contain large areas nobody uses any more. Usage logs, interviews and observation reveal the real footprint — often much smaller than the full feature list.
Business rules
Legacy systems are often the only place where certain business rules are recorded: how discounts are calculated, how jobs are prioritised, how stock is allocated, how commissions are computed. These rules are valuable and must be extracted before anything is replaced. Some are still correct; some are outdated; some were never intended.
Technical health
Is the code readable and structured, or a tangle? Is the database design sound? Are there automated tests? Is the technology still supported? Can it be hosted securely? A technical review by experienced developers answers these questions in days, not months.
Data
How much data is there, how clean is it, and how is it structured? Data quality often determines the effort of any modernisation more than code quality does.
A simple scorecard helps structure the discussion:
| Area | Questions | Score (1–5) |
|---|---|---|
| Business fit | Does it support current processes without workarounds? | |
| Changeability | Can changes be made quickly and safely? | |
| Knowledge | Do several people understand it? Is it documented? | |
| Technology support | Are the language, database and platform supported and secure? | |
| Integration | Can it exchange data with other systems? | |
| Accessibility | Can users work from browsers, phones, branches? | |
| Data quality | Is the data complete, consistent and well structured? |
Low scores across business fit and changeability suggest replacement; low scores mainly in technology and accessibility may be solvable with less drastic options.
Step 2: Understand the four options
Option 1: Wrap (encapsulate)
Leave the old system running and build a modern layer around it: an API that exposes its data and functions, a web or mobile front end for specific users, or integrations with other systems. For example, field technicians might get a mobile app that reads jobs from and writes results to the old system.
Good when: the core system is stable and correct, but needs to be reachable from new channels. Risks: the old system's limits remain; wrapping adds another layer to maintain; it buys time rather than solving the underlying problem.
Option 2: Refactor or re-platform
Improve the existing code and move it to supported technology without changing what it does: upgrading frameworks, restructuring code, moving the database, moving from a desktop to a web architecture step by step.
Good when: the system's logic is sound and well matched to the business, but the technology is outdated. Risks: poorly structured code can be harder to refactor than to rewrite; benefits for users may be limited if the business processes also need to change.
Option 3: Replace with off-the-shelf software
Adopt a commercial product that covers the same functions — for example, a standard accounting package or a field service product.
Good when: the functions are standard and a product fits your processes well. Risks: unique processes that gave you an advantage may be lost; customisation of the product can recreate the legacy problem; subscription costs and vendor dependence must be considered over many years.
Option 4: Rebuild as custom software
Build a new system designed for current and future needs, using modern technology.
Good when: your processes are distinctive, the old system no longer fits, and no product fits well either. Risks: the biggest risk lies in how the rebuild is done — a single big-bang rewrite is far riskier than an incremental rebuild.
Why big-bang rewrites fail so often
The appealing plan is to build the complete new system in parallel and switch over on a single day. In practice, this approach fails surprisingly often, for predictable reasons:
- Hidden rules. The old system contains years of rules and edge cases that surface only when the new system meets real data. Each one delays the switch.
- Moving target. The business keeps changing during the rewrite. The old system keeps getting changes; the new one must copy them.
- No value until the end. Users see no benefit for a long time; support and budget erode.
- All-or-nothing risk. On switch-over day, every function changes at once. Any serious problem affects the whole business.
This does not mean rebuilding is wrong. It means rebuilding in one piece usually is.
Incremental modernisation
The safer approach is to replace the old system piece by piece, while both run side by side. Developers often call this the "strangler" approach, after a plant that gradually grows around a tree: new functions grow around the old system until it can be removed.
In practice, it works like this:
- Create a way for old and new to share data — an integration layer, shared database views, or synchronisation between the two systems.
- Choose a first slice — a function with high value and manageable risk, such as the technician app, the customer portal, quotations or reporting.
- Build it in the new system, connected to the old one for the data it still needs.
- Move users of that function to the new system; the old function is switched off.
- Repeat with the next slice, until the remaining old core is small enough to replace or retire.
Each step delivers value, limits risk to one area and teaches the team more about the old system's hidden rules before the most critical parts are touched.
Choosing slices
Good first slices have clear boundaries, visible user value and limited dependency on complex core logic. Examples:
- A mobile app for field staff that currently use paper.
- A customer or dealer portal that reduces phone calls.
- Reporting and dashboards drawing data from the old system.
- A quotation or estimating module.
Core financial postings, complex stock allocation and pricing engines are usually better tackled later, once the integration layer and the team's understanding are mature.
Extracting business rules
Before rebuilding any function, document its rules. Sources include the code itself, the database (including triggers and stored procedures), user knowledge, documents and the outputs the system produces. A useful technique is to run the same real inputs through old and new systems and compare outputs — for example, last month's orders through both pricing engines. Differences reveal rules that were missed, or rules that were wrong all along. Decide consciously which rules to keep, change or drop.
Data during modernisation
When old and new systems run in parallel, data ownership must be clear: for each type of data, which system is the master at each stage? Synchronisation should be designed for failures — retries, logs, alerts and reconciliation reports — because silent mismatches between systems are one of the main risks of incremental modernisation. Data cleaning should start early; it benefits every option and every slice.
People and change
Legacy systems shape how people work. Staff have built habits, shortcuts and expertise around the old system's quirks — sometimes they are proud of mastering it. Involve these experts early: they know the hidden rules and the real exceptions. Explain why the change is happening and what will improve for them. Train by role, close to each slice's launch, and keep support close during transitions.
A practical roadmap
| Phase | Activities | Outcome |
|---|---|---|
| Assess | Usage analysis, rule discovery, technical review, data review, scorecard | Clear picture of the system and its risks |
| Decide | Compare options per area; choose target architecture and approach | Modernisation strategy and roadmap |
| Prepare | Integration layer, data cleaning, environments, first slice design | Foundation for parallel running |
| Replace in slices | Build, test, migrate users and switch off each slice | Value delivered step by step |
| Retire | Migrate remaining functions and data; archive history; decommission | Old system removed safely |
Review the roadmap after each slice. Priorities change as the business learns, and early slices often reveal better ways to tackle later ones.
Example
A trading company had run its operations on a desktop application for eighteen years. Its original developer was close to retirement, the database could not be upgraded, and sales staff kept customer information in their own spreadsheets because the system was not accessible outside the office. A full rewrite was considered but judged too risky: the system's pricing and credit rules were complex and poorly documented.
Instead, an integration layer was built to read from and write to the old database. The first slice was a web-based customer and order portal for the sales team, using data from the old system. The second was a management dashboard, which revealed several pricing rules that differed from what managers believed — some were corrected. The third slice replaced order entry and pricing, verified by running three months of historical orders through both engines until results matched or differences were explained. Purchasing and stock followed. The old application was finally retired, its history archived in a searchable read-only database. At no point did the business stop, and each step brought visible improvements for users.
Common mistakes
- Choosing a big-bang rewrite because it seems cleaner on paper.
- Copying every old feature, including ones nobody uses.
- Ignoring hidden business rules until they break something in production.
- Leaving data cleaning until the end.
- Excluding the people who know the old system best.
- Wrapping indefinitely, so the old system's problems never get solved.
Summary
Legacy software becomes a problem when it stops the business from changing. Start by assessing the system's business value, rules, technical health and data. Choose between wrapping, refactoring, replacing with a product and rebuilding — often a different choice for different areas. If you rebuild, do it incrementally: create a way for old and new to share data, replace valuable slices one at a time, extract and verify business rules, and retire the old system only when it has nothing left to do. Modernisation done this way delivers value early, limits risk and keeps the business running throughout.
Frequently asked questions
Is it always better to rewrite old software from scratch?
No. Full rewrites are risky and often take longer than expected, because the old system contains years of business rules nobody has written down. Incremental replacement is usually safer.
How do we know if our legacy system needs modernisation?
Warning signs include difficulty finding people who can maintain it, security updates no longer available, inability to integrate with other systems or mobile apps, frequent breakdowns, and business processes bent to fit the software's limits.
Can we keep the old system running while building the new one?
Yes, and usually you should. Incremental approaches move functions one by one to the new system while the old system keeps running the rest.
What happens to our historical data?
Active data is migrated to the new system; older history can be migrated, archived in a searchable form or kept in a read-only copy of the old system, depending on how often it is needed.
How long does modernisation take?
It depends on the size of the system and the approach. Incremental modernisation delivers the first replaced functions in months while the full transition may take longer, spreading risk and cost over time.
