Many businesses run on software that was written ten or fifteen years ago. It still works, more or less, and it encodes years of business rules that nobody has fully documented. But it is getting harder to change, harder to host and harder to find people who understand it. Legacy system modernization is the process of bringing such software up to date, and the biggest decision is not which technology to use, but how much to change and how fast.
What makes a system "legacy"
Age alone does not make software legacy. A ten-year-old system that is well tested, on supported technology and easy to change is simply mature. Software becomes legacy when it is still important to the business but has become a liability. Typical signs:
- Unsupported technology. The programming language version, framework, database or operating system no longer receives security updates.
- Fear of change. Small changes take weeks because nobody is sure what else they might break, and there are no automated tests.
- Knowledge concentrated in one person, or in nobody, because the original developers have left.
- Integration difficulty. Connecting to modern services such as payment gateways, mobile apps or cloud tools requires awkward workarounds.
- Poor fit with how work is now done. Staff keep side spreadsheets because the system cannot handle new products, channels or rules.
- Hosting constraints. It only runs on a particular old server that cannot easily be moved or backed up.
One or two of these may be manageable. Several together usually mean the cost of standing still is rising quietly every year.
Legacy system modernization options
Modernization is a spectrum, from light-touch to complete replacement. Roughly in order of effort and risk:
| Approach | What it means | Best when |
|---|---|---|
| Encapsulate | Leave the core alone, but expose its data and functions through a modern API | The core is stable; you mainly need integrations |
| Rehost | Move it, largely unchanged, to new infrastructure such as a cloud server | The hardware or hosting is the main risk |
| Upgrade and refactor | Upgrade language and framework versions, add tests and restructure code incrementally | The design is basically sound but outdated |
| Incremental rebuild | Replace the system module by module, running old and new side by side | The system is large and business-critical |
| Full rebuild | Write a new system and switch over | The system is small, or so broken that incremental change is impractical |
| Replace with a product | Move to an off-the-shelf or open-source package | Your processes are now fairly standard |
Why "big bang" rebuilds are risky
Rewriting everything from scratch and switching over on one day is tempting because it promises a clean slate. In practice it carries well-known risks:
- Hidden requirements. The old system contains years of fixes and special cases that nobody remembers until the new system gets them wrong.
- A moving target. The business keeps changing during a long rebuild, so either the old system is frozen (frustrating users) or both systems must be changed in parallel (doubling the work).
- Delayed value. Nothing reaches users until the very end, and long projects are more likely to be cut or cancelled halfway.
- Risky cut-over. One day of switching everything leaves little room to recover if something goes wrong.
A full rebuild can still be right, especially for smaller systems, but go in with eyes open.
The strangler fig approach
The most widely recommended way to modernize a large system incrementally is often called the strangler fig pattern, after a plant that gradually grows around a host tree until it replaces it. In software terms:
- Put a routing layer in front of the old system, so requests can be directed either to old or new code.
- Pick one well-bounded area, such as customer management or invoicing, and build it new.
- Route that area's traffic to the new module, keeping both systems' data in sync where necessary.
- Repeat area by area until the old system handles nothing and can be switched off.
Each step delivers value, each step can be rolled back, and the team learns the old system's hidden rules piece by piece rather than all at once.
Preparing for modernization
Document what the system really does
Interview users, read the code and examine the database. Capture business rules, especially calculations, approvals and exceptions. Reports that staff rely on are a good guide to what data matters.
Add a safety net
Before changing behaviour, write tests that record what the old system currently does for important scenarios, sometimes called characterisation tests. They let you confirm that the new code produces the same results.
Plan the data
Data migration is often the hardest part. Old databases tend to contain duplicates, inconsistent formats and fields used for purposes other than their names suggest. Profile the data early, decide on cleansing rules and rehearse the migration several times. Our database management team treats migration as its own workstream for exactly this reason.
Decide on hosting early
Modernization is a good moment to move to infrastructure that is backed up, monitored and reproducible. See our notes on cloud solutions if a move to the cloud is part of the plan.
Managing the business side
- Set priorities by pain and risk. Start with the area that is most fragile or that blocks the most valuable business change.
- Avoid feature parity as the goal. Some old features are no longer used. Modernization is a chance to drop them, not copy them.
- Train and involve users. Staff who helped shape the new module adopt it faster.
- Keep the old system safe meanwhile. Patch what can be patched, restrict network access and make sure backups work.
An independent assessment of the current system, its risks and the realistic options is often a sensible first step; that is a typical software consulting engagement.
Key takeaways
- Software becomes legacy when it is important but risky and hard to change, not simply when it is old.
- Options range from wrapping with an API to a full rebuild; choose the least disruptive one that solves the real problem.
- Incremental replacement with the strangler fig pattern reduces risk for large systems.
- Invest early in documenting rules, adding tests and planning data migration.