Introduction

Why Not Replace It All at Once

A legacy system is old software that still runs work the business depends on. It is usually large, poorly documented, and connected to many other things. Replacing it in one release means building the whole replacement first, then switching over on a single day.

That approach fails in a predictable way. The new system is built for months with no real traffic to learn from. The switch happens all at once, so every mistake arrives together. If it goes badly there is nothing to fall back to, because the old system has already been turned off.

The Strangler Fig Pattern avoids that. You build the new system beside the old one. You move one piece of work across, watch it, then move the next. The old system stays available until the last piece is gone.

How It Works in Short

Every request goes through one router that decides where it is handled. That router is called the facade. Work that has been rebuilt goes to the new system. Everything else goes to the old one. Moving a piece of work means changing that decision, not deploying a new version of everything.

Why Teams Choose It

1. Lower risk: the old path still exists, so a piece that misbehaves can be routed back to it.
2. Control over order: you replace the parts that cause the most pain first.
3. No large release: each change is small, so no single release can break everything.
4. No cutover day: there is never one moment when the whole system switches over. Users keep working while the parts move one at a time.

The pattern is not free. Two systems run at the same time, and their data has to stay correct while both are live. If the system is small enough to rewrite and switch over in one short release, that cost gains you nothing. This chapter covers the cost as well as the benefit.

The next lesson looks at why legacy systems are so hard to replace.