Decision guide
If you are searching for how to replace a legacy system or modernise an IT system, you have typically already felt the cost: slow delivery, one person who dares touch the code, an integration that only works at night, or a salesperson promising things the system cannot do. That is an honest place to stand. It is also where the expensive mistakes start.
We see two extremes. One is big-bang: everything must be rewritten because the stack is embarrassing. The other is endless deferral: "it still runs", until it does not, and then nobody can start it again. Both are expensive. This guide is the frame we use when the question is not "is the system old", but "what should you actually do about it — and in which order".
TL;DR
The main takeaways
- Replace when the system blocks a named business decision — not when it fails an aesthetic test.
- A rewrite is a product project with cutover, data and users. It is rarely the first step.
- Wrap and strangle beat big-bang when the core is still true and the pain sits at the edges.
- "Nobody dares touch it" is a risk you should reduce — it is not automatically an argument for throwing it away.
- A new system without ownership of data and processes becomes the next legacy. Scope is the real conversation.
- Start with the one flow you want out of the old system. Not with a new platform and a hope.
Why this matters in the first place
Legacy is a blurry word. Sometimes it means "written in a language the juniors will not touch". Sometimes it means "the only source of truth for orders, customers and stock". The first is a hiring problem. The second is your business. Mixing the two is how rewrites eat a year and still miss the order type that pays the salaries.
Modernisation is often sold as a technology lift: new framework, new cloud, new UI. That can be right. It is wrong as a goal. The goal is that you can change a business rule without asking the last person who remembers it to be brave. If you can do that in the old system — with tests, with documentation, with a bounded interface — you are already modernising without having replaced anything.
Conversely: if you cannot hire into it, cannot integrate, cannot honour a contract, or cannot shut down a manual process that grows with every new customer, then age is irrelevant. Then the system blocks. Then you must act. The action is just rarely "rebuild everything behind a curtain and switch over a weekend".
What you choose here is total cost of ownership over the next years — not a feeling of being modern. An expensive rewrite that ships a prettier UI on top of the same unclear rules is the most expensive place to end up.
What is typically wrong — once you peel the word "legacy" off
The most common pain is knowledge that lives in heads. The code is not necessarily bad. It is undocumented, untested, and the only person who has deployed it is on holiday. That is an operations and hiring risk. It is solved with characterisation tests, runbooks and pairing — not automatically with a new stack.
The next is data that is only true in the old system. Orders, prices, serial numbers, customer records. Everything new you build must either read from there or take over the truth. If you do not know which table wins when two systems disagree, you are not ready to replace. You are ready to draw a data map.
The third is the edges: a UI nobody can stand, an integration that only runs as a night job, a report that takes a morning, an onboarding that needs three emails to the internal specialist. Here wrapping is often right: a new layer in front, the old system as the source, until you have moved the one flow that hurts.
The fourth is the platform itself: licences you cannot renew, an OS that no longer gets patches, a vendor that is gone, hardware you cannot buy. That is a real deadline. It justifies action. It still does not justify rewriting business logic you have not characterised.
Three strategies — and when each of them is honest
Leave it standing, and reduce the risk. That is right when the core is stable, the pain is rare, and you can isolate it with tests, monitoring and a named owner. "Leave it" without an owner is just deferral. With an owner, backups and a plan for the day it breaks, it is an adult choice — especially if you have more important product work.
Wrap and strangle. You put a new layer around the old: an API, a portal, a new UI, a new integration. Traffic and writes move flow by flow. The old system shrinks until you can switch it off or leave it as an archive. That is right when the truth still lives in the core and you can cut an interface. It is wrong when you wrap without moving writes — then you have two truths and a sync project.
Replace. You build the new system as the source of truth for a bounded part, migrate data, and switch that part off in the old one. That is right when you can point to the part, when you have a cutover plan, and when the old system cannot carry the change the business has already promised. It is wrong when "replace" means the whole landscape at once because it looks cleaner on a slide.
The three can be combined. What you must not do is call a wrap a replacement, or a replacement a "small lift". Name the strategy. Then you can say no to scope that belongs to a different one.
Wrap and strangle vs. replace the core that blocks
Wrap / strangle
New layer in front; the old system shrinks over time.
- Truth still lives in the old system at the start
- You can cut an interface and move one flow
- Users get value before the old system is switched off
- Risk: two truths if writes do not move with the reads
Replace (bounded)
The new system becomes source of truth for one part.
- You can point to the part and the data that must come with it
- The old system cannot carry the change you have promised
- Cutover, rollback and parity are planned — not hoped
- Risk: you underestimate the rules that only live in heads
How to decide whether you should replace at all
Five questions. If you cannot answer them, you are not ready for a replacement project — however old the system is.
- 01
Which business decision is blocked?
A named thing: a contract, a channel, an integration, a compliance requirement, a hire you cannot make. "It feels old" does not count. If you cannot point to the blockage, the next step is to reduce risk — not to replace.
- 02
Where does the truth live today?
Which tables, files, manual lists? Who wins when two sources disagree? Without that map the new system becomes another copy you do not dare trust.
- 03
What is the smallest flow that removes the blockage?
One order type, one login, one report, one integration. If the answer is "everything", you have not cut. Cut, or you are building a big-bang under another name.
- 04
Can the old system carry a wrap, or do writes need to move?
If you only need to read and show, you wrap. If you need to change rules the old system cannot hold, the new system must own that part. Be honest. A wrap that writes both places without an owner is the worst of both worlds.
- 05
Who owns cutover, data and day-to-day operations afterwards?
A system without an owner becomes legacy again — even when it is new. If you cannot name product, operations and the person who may say no to scope, wait before you build.
“You do not replace a legacy system because it is old. You replace the part that blocks — and you leave the rest standing until it does too.”
When you should leave it standing (and still do something)
Leave it standing when the blockage is hypothetical and the core is true. An older ERP that actually reflects stock is worth more than a new UI that guesses. Your job is to make it less fragile: characterisation tests around the flows you dare touch, monitoring on the jobs that fail quietly, and a runbook for the day the last specialist is sick.
Leave it standing too when you have not cut a first flow. A replacement project without a v1 slice is a wish to be done being embarrassed by the stack. That is understandable. It is not a project. Wait until you can say: this order type, this role, this integration — and everything else waits.
What you must not do is leave it standing without reducing the risk. No backups you have tried to restore, no documentation of the night jobs, no agreement on who may change what. That is not conservatism. That is hoping nothing breaks.
If you later replace, that work still has value. Tests and a data map are what a rewrite otherwise pays dearly to rediscover. Modernisation often starts by making the old system understandable — not by opening an empty repo.
Replace, wrap, or reduce the risk?
Left is what you typically feel. Right is what we typically recommend as the next step.
Situation
You cannot point to a named business blockage
Next step
Reduce risk: tests, runbook, owner — not a replacement project
Situation
The pain sits in the UI or one integration; the core is true
Next step
Wrap that edge; move writes only when the new system must own the rule
Situation
The platform dies (licence, vendor, unsafe runtime) on a date
Next step
Bound the part you must move before that date; the rest waits
Situation
You cannot hire into it or change a rule you have already promised
Next step
Replace that part — with cutover and data parity, not the whole landscape
Situation
Nobody knows which source wins when data disagrees
Next step
Draw the data map before you build. Two truths cost more than one ugly system
Checklist before you call it modernisation
If you are missing several of these, you are about to start a rewrite you cannot steer.
- You can point to the one business blockage v1 must remove
- You know where the truth lives, and who wins on conflict
- The strategy is named: stand, wrap or replace — not "we are modernising"
- Cutover, rollback and parity are written down if you replace a part
- The old system has an owner and a plan while you build the new one
- You have separated "nobody dares touch it" (risk) from "it cannot do what we promised" (blockage)
Questions we get again and again
Isn't it cheaper just to rewrite everything in one go?
It feels cheaper on a slide because you only draw one system. In practice you pay to rediscover rules, for parallel operations, and for the cutover you did not have time to rehearse. A bounded replacement or a wrap delivers value earlier and keeps the old system alive until you know what you did not understand. Big-bang is a bet that you know everything up front. You rarely do.
When is no-code or an off-the-shelf product enough as a replacement?
When the blocking flow fits the tool, and you can accept its model for data and roles. That is right for an internal process you currently run in email. It is wrong when the core is your differentiation, or when you must mirror an ERP you are not allowed to simplify. An off-the-shelf product that forces you to lie about price or roles becomes the next system you are embarrassed by.
What do we do when only one person understands the old system?
That is a risk you should reduce now — whether you replace or not. Characterisation tests, pairing, a runbook, and making sure that person is not the only one allowed to deploy. Starting a rewrite to "get free" without capturing the rules is how you lose both the person and the system. Pin the knowledge down first. Replace afterwards if the blockage is still there.
Can't we build the new system beside it and switch when it is ready?
You can build beside it. You still have to cut a first flow that goes to production, and you still have to know who owns writes along the way. "When it is ready" is not a date. It is a signal that you do not have a cutover criterion. Set the criterion: this order type runs in the new system, with parity, for two weeks — then we switch it off in the old one.
How long does a modernisation typically take?
It depends on whether you wrap an edge or replace a core. A bounded first flow is often in the same range as other product engagements we run in 1–2 week iterations with weekly demos; you do not do a whole landscape in one engagement, and you should not promise that. The more honest plan is: first flow in production, then the next. The time you save is the rewrite you did not start.
If you are considering replacing a legacy system
Let us find the part that actually blocks.
A short review of the business decision you cannot take today, and where the truth lives, is often enough to say whether you should wrap, replace — or make the old system less fragile.