Legacy Migration Playbook – Determine a Migration Strategy / Strangle

Martin Fowler is held in high regard around our office. Two of his creations are referenced a lot: the idea of design stamina hypothesis and his strangler pattern for legacy migration. When we engage in work on a legacy application, the strangler pattern often comes up. Ironically, we will refer to it as the strangler pattern in this post, but in Mr. Fowler’s blog post he refers to it as a strangler fig application.

The strangler pattern refers to vines that – over time – strangle out a tree, leaving a shell of vines that look like the tree that was strangled out.

Like the vines, this pattern involves strangling out pieces of the application, slowly and over time. Throughout development, you remove pieces of the original application and replace them with the new application and architecture. Eventually, much of the original application is replaced.

This pattern makes a lot of sense in most cases. It allows us to make headway toward a better architecture/system without having to pay the entire cost upfront and in one huge bite. In many ways, this pattern often becomes part of almost any legacy project.

However, this pattern doesn’t have to be used across the entire system. There are often parts of a legacy system that don’t require any changes and can stay as they are. We will go into more detail about this in a later blog post.

It is important to note that this pattern isn’t the best thing to start with. Many of our legacy projects turn into some sort of strangle, but we often need to wait until we know more information. I really like the approach of taking a small bite of work first. Before refactoring a solution, it is also a good idea to get a few unit tests in place first. The strangler pattern fits best after you have found your bearings within the legacy system. Only after you know enough about the system can you make well-informed decisions about how best to begin strangling it.

The strangler pattern, as we use it in legacy systems, is often a go-to play. While its level of use varies from project to project, it will almost always find its way into work done against a legacy system.

Plays

System Review / Code Review
Design the Ideal End State
Mini Spike Work
Add Some Unit Tests
Determine a Migration Strategy / Strangle
Segment the New from the Old
Start Over