You know the system needs replacing. Everyone knows. But it keeps getting pushed to next quarter. Then the quarter after that.
Meanwhile the business starts to suffer. Every month you wait, the replacement gets harder, because the old system grows more tangled with everything around it. At some point you are stuck: you cannot switch the old system off, and the new one is nowhere near ready. That is the trap.
There is a way out. It is called the Strangler Pattern, and it lets you replace the old system gradually instead of all at once.
What it actually is
The name comes from the strangler fig, a plant that grows around a host tree and slowly takes its place. That is exactly what you do to your old system.
You work at the edges. You replace one piece at a time with new code, while the old system keeps running. No overnight switch. No big reveal. The old system stays alive until the new one is ready to take over, function by function.
The alternative is the big bang rewrite: build the whole new system in the dark, flip the switch one night, and pray. I have watched companies lose a quarter of their customer base doing exactly that. The new version shipped, customers hated the new interface, and there was no way back.
Why it wins
Business continuity. The old system keeps serving customers the entire time. Very few companies can afford a full rewrite that has to work overnight. Your liquidity stays intact because you are not betting everything on one launch date.
Lower risk. You replace in small steps. If a new piece breaks, you fall back to the old one. In DevOps terms, think canary releases and small beta groups. The Strangler Pattern supports exactly that kind of gradual rollout.
Customer feedback. This is worth its weight in gold. You are not guessing what the new system should do. You ship a piece, watch how real customers use it, and refine before you build the next piece. The big bang gives you zero feedback until it is too late.
One cheap habit that pays off: prefixing
If you take one technical thing from this, take this one. Prefix your URLs and your API routes from day one. It costs almost nothing to do early.
It means that later you can run a new version of an API or a website alongside the old one, route traffic between them, and make the whole thing look like one seamless product to the customer while it is being rewritten behind the scenes. Anyone who says “we will never rewrite this” is usually wrong, and usually sooner than they think. Prefixing is cheap insurance against your own certainty.
The costs, honestly
Glue code. You will write specialized code to connect the old system to the new one. It is complex, it is temporary, and you will throw it in the bin the day the migration finishes. Budget for building something you will delete.
Two sources of truth. Run two systems and you risk two versions of your data. Keeping them in sync is where your best people earn their pay. If you can keep a single shared database, the problem gets much easier.
Scaling surprises. It is easy to forget that the new system has to scale as well as the old one. You usually discover it did not at the worst possible moment, when customers show up in force and nothing responds.
Vendor lock-in. There are commercial tools that speed up strangling. Some are good. Just make sure you do not swap a system you could not replace for a vendor you cannot leave.
And keep the whole operation short. While you are strangling, you maintain two systems at once. That slows your pace and raises your costs. The longer it drags, the more it hurts.
What it looks like in practice
On one of my products we changed our entire stack. Hiring an army of developers to rewrite everything overnight was never an option, so we strangled it.
Today that product runs on four systems. One legacy, three new: a new backend API, a new frontend, and a server handling websocket communication. Because every route was prefixed from the start, we could introduce each new piece cleanly and keep a fallback ready if it misbehaved. The customer never sees the seams. To them it is one product.
The glue code holding it together is complex, and most of it is destined for the trash once we finish. That is the deal. It is still far cheaper and far less risky than the big bang would have been.
The takeaway
Every strangle job I have run has been unique and needed its own plan. That is the one constant. Stick to good engineering habits early, replace gradually, refine on real feedback, and you keep the business running while you rebuild it.
If you have a system you know needs replacing and you are not sure how to approach it, that is the conversation I have with companies most weeks.
