Rewriting a Legacy Monolith: Strangler Fig or Strangler Fig, Those Are the Options

Every engineer meets a codebase they want to rewrite from scratch. Mine was a decade old monolith where the billing logic imported from the PDF generator, for reasons lost to time. The urge to open a fresh repo and do it right this time is powerful. It is also, in my experience and everyone else's I trust, how you end up maintaining two systems, one legacy and one perpetually 80 percent done.

The big bang rewrite fails for a boring reason. The old system does not stand still while you rebuild it. It keeps taking features, fixes, and weird customer accommodations, and your rewrite is chasing a target that moves faster than you can copy it. Meanwhile it ships zero value until the day it ships everything, and that day slips, because the old system's real spec is ten years of undocumented behavior that customers depend on.

So, strangler fig. Named after the tree that grows around a host until the host is gone. You put a routing layer in front of the monolith, pick one seam, one endpoint, one domain, and build just that piece outside. Route one percent of traffic to it, compare outputs against the old path, ramp up, then delete the old code. Repeat. The monolith shrinks in production, continuously, and every increment either works or gets rolled back small.

The two hard parts nobody advertises. Shared state, because the new piece and the old piece usually want the same database, and untangling data ownership is most of the actual work. And the last 15 percent, the weird corners nobody understands, which you save for the end when your extraction muscles are strongest.

It is slower per month and faster overall. Less dramatic, more done. Choose boring.