A legacy system is one the business depends on and is afraid to touch. It works, mostly. The people who built it have left, the technology is no longer supported, and every change is a risk.
The temptation is to replace it all at once. That is the most dangerous option available.
01Why the big switch fails
An old system contains years of business rules that nobody wrote down. A full rewrite has to rediscover every one of them, and learns which it missed on the day it goes live, with no way back.
02The staged method
- Map it. Record what the system does, what data it holds and what depends on it. Read the code and watch the users; neither alone is enough.
- Wrap it. Put a modern interface in front, so new software talks to the interface and not to the old internals.
- Move the data. Copy it to a current database and keep the two in step. Clean duplicates and gaps on the way.
- Replace one function. Choose a part with clear edges, rebuild it behind the interface, and run old and new together until their results agree.
- Repeat. Each replaced part shrinks the old system and proves the approach.
- Retire it. Switch the old system off only when nothing calls it.
03Choosing what to do with each part
- Keep: it works and nobody needs it to change.
- Re-host: move it to supported infrastructure unchanged.
- Refactor: keep the logic, renew the code beneath it.
- Replace: buy or build a new version.
- Remove: nobody uses it any more. There is always more of this than expected.
04What to protect throughout
- The business rules buried in the old code. They are the valuable part.
- The data and its history.
- The ability to go back at every stage.
In short
- Replace a legacy system in stages, never in one switch.
- Wrap it with an interface first, so everything else is insulated from the change.
- Run old and new side by side and compare results before trusting the new.
- The undocumented business rules are the asset to preserve.
Questions
How do we know what an undocumented system does?
From three sources together: its code and database, the people who use it daily, and its actual inputs and outputs over time. Automated analysis of the code helps and does not replace the other two.
Should a legacy system be moved to the cloud?
Sometimes. Re-hosting solves an infrastructure risk and leaves the software as it was. Whether the cloud is the right home is decided system by system, on cost, rules and where the data must live.
When should a legacy system simply be left alone?
When it is stable, supported well enough, and nothing in the business needs it to change. Modernisation should answer a real risk or need.
Sounds like your problem?
Tell us about it. We'll say honestly whether the swarm can help, and what it would take.
Read next
- CRM, ERP, HRMS, CDP, PIM, WMS and the rest: thirty business systems explained in plain wordsBusiness systems
- Custom software or off-the-shelf: how to decide whether to build, buy or extendBuild or buy
- Custom CRM or off-the-shelf CRM: which does your sales team need?CRM
- When does a company need a custom ERP?ERP
- CDP vs CRM vs DMP: what each one stores, and which you needCustomer data
- CMS, DAM and PIM: what each one manages, and why a catalogue needs all threeContent and product data