Strangling Your Legacy Codebase: A Safe Way To Perform Migrations

You may not be familiar with the strangler pattern even if used it in the past. Working on a software team, you’ve likely been faced with a massive refactor or migration to a new platform/codebase/service architecture. Let’s say for example that your company wants to port all their widgets currently written in Jquery to ReactJS. These widgets are exported via a library and imported into a web app. You have some choices in how to approach this.

All or Nothing!

Your team begins re-writing widgets to use ReactJS. There are dozens! Some more complicated than others. You estimate it will take 6 months to fully migrate your legacy code to the new framework. About 9 months later (because no one can estimate a project this large) your team is finally ready to flip the switch!

Uh oh.

A PagerDuty alert pops up on your phone. Followed by another. And another. 😳

The decision to switch all of your widgets over at once has backfired spectacularly. Previous functionality is not working as expected. Certain features are missing patches that were merged to the legacy code base. It’s a mess. You cry over your half-eaten burrito in shame.