How to get out of your legacy system
Replace a legacy system step by step instead of in one big cutover. With the strangler fig pattern, you replace one function at a time while the old system keeps running, which keeps risk low and operations going. Map hidden dependencies and tacit knowledge first, and protect business continuity throughout the transition.
A legacy system is rarely broken – that’s exactly why it’s still around. It works, the business trusts it, and no one really dares touch it. But old technology gets more expensive to maintain, harder to staff, and eventually a brake on everything new you want to do. The question isn’t whether you should get out of it, but how you do it without stopping the business along the way.
Why step-by-step almost always beats big bang
The tempting plan is a clean cutover: finish building the new system, pick a weekend, move everything over, and switch off the old one. On paper it’s fast and simple. In reality, it’s one of the riskiest things an organization can do.
The problem is that a big bang migration can’t be tested in live operation until the exact moment everything has to work. A single overlooked edge case can then stop invoicing, orders, or production – with no easy way back. Step-by-step migration flips the equation: you move a little at a time, verify in real use, and always keep the old system as a safety net.
The strangler fig pattern: replace piece by piece
The proven method for this is called the strangler fig pattern. The idea is that the new system grows around the old one and takes over one function at a time, until the old system eventually does nothing and can be shut down.
In practice, it works like this:
- Put a router in front. A layer that directs every call to either the old or the new system.
- Move one narrow function. Pick something with clear boundaries – a report, a flow – and build it new.
- Redirect the traffic. Have the router point that specific function to the new system and go live.
- Verify and move on. If it works, take the next function. If something breaks, point back to the old one.
- Shut down the old one. Once nothing points there anymore, the legacy system can be retired calmly.
Each step is small enough to understand, test, and roll back if needed. The risk is spread out over time instead of concentrated into one fateful night.
Map hidden dependencies and tacit knowledge
The biggest danger with old systems isn’t the code you can see, but the code you don’t know exists. After many years, integrations, nightly jobs, export files, and exceptions have often grown up undocumented.
| What you're looking for | Where it often hides |
|---|---|
| Integrations with other systems | Scheduled jobs, file transfers, old APIs |
| Business rules and edge cases | In the code – and in the heads of experienced users |
| Reports and exports | Manual routines run at month-end |
| Permissions and exceptions | Undocumented workarounds for individual departments |
Technical analysis finds some of it, but far from everything. Much of the logic lives as tacit knowledge with a handful of people. Sit down with the people who use the system every day and ask what it does that no one has written down. That hour saves weeks of debugging later.
Keep the business running the whole way through
A concrete example: a company was replacing its old order system. Instead of switching everything at once, they first moved just order registration, while inventory and invoicing stayed on the old system. Once that part had proven itself in live operation for a few weeks, they took the next piece. The business kept running throughout the journey, and when the old system was finally shut down, it was a non-event.
That’s how you want a migration to feel: undramatic. Schedule transitions for calmer periods, always keep a way back, and communicate clearly with the people affected.
Why old systems get to live too long
A fair question is why you don’t just switch in time. The answer is that a legacy system rarely causes an obvious crisis – it decays slowly. The cost of maintaining it rises gradually, the skills to manage it get harder to find, and every new idea takes longer to deliver because the old foundation is in the way. No single day feels urgent enough to justify a switch, so it gets pushed back year after year.
That’s exactly why it’s worth making the decision before your hand is forced. A planned, step-by-step migration is always safer than an emergency evacuation once the old system finally breaks or the last person who understands it leaves. Starting while the system still works gives you the calm to move at your own pace.
Take one small step first
The best way out of decision paralysis is to make the migration small and concrete. Pick a single, narrow function, move it using the strangler fig pattern, and learn from the experience. That first step proves the method works in your specific environment, reveals the hidden dependencies you missed, and builds confidence that the rest can be done the same way.
Need help mapping an old system and putting together a migration plan that keeps the business running? At Weapp we’re happy to do a technical review and then drive the migration in controlled steps.
Frequently asked questions
What is the strangler fig pattern?
It's a migration strategy where you build the new system around the old one and move over one function at a time. Traffic is gradually redirected until the old system is no longer used and can be shut down. The name comes from the strangler fig tree, which grows around its host tree until it takes over completely.
Why is big bang migration so risky?
Because everything changes at once, it's impossible to test in real operation until the whole system has to go live. A single unexpected error can stop the entire business, with no easy way back. Step-by-step migration limits each risk to a small part and always keeps a working fallback.
How do we find hidden dependencies in the old system?
Combine technical mapping with interviews. Old systems often have integrations, scheduled jobs, and edge cases no one has documented. Talk to the people who use the system daily – much of the logic lives as tacit knowledge with a handful of people rather than in any documentation.
Can the business keep running as usual during the migration?
Yes, that's the whole point of a step-by-step approach. Since the old system stays in place until each part is replaced and verified, users rarely notice the switch. Schedule transitions for calmer periods and always keep a way back if a partial move doesn't behave as expected.
How long does a legacy migration take?
It depends entirely on the system's size and how tangled the logic is, but step-by-step migration deliberately takes longer in calendar time than big bang. In return, the risk is lower and the business can use the system the whole way through. Think of it as a controlled phase-out over months rather than a single weekend.