Why and when to use the Strangler Pattern when migrating legacy business applications?
The Strangler Pattern, also known as ‘Strangulation’ is a technical term used in the software development industry. It is an approach or methodology used when a given legacy system is migrated or re-engineered into a new modern system. The pattern is simply the migration of features or modules from the old legacy system to the new system one “bit” at a time. We will discuss in another article what a “bit” may mean, but as each bit of the system is migrated from the old to the new, the old is decommissioned and the new comes on-line. Effectively, the legacy system is strangled (decommissioned) one bit at a time.
Why the Strangler Pattern?
Very often a given business or organisation is already using a system for their day-to-day business activities. The system they use, more or less, fits their unique internal business processes and requirements. However, as with all things, especially technology related things, they grow old. When software applications starts to grow old, various challenges start to come up. Things like slowness, compatibility, interfacing (especially API interfacing) with other systems, security, maintenance, and so on, start to pose more of a problem. Technology moves on at a rapid pace, and according to industry estimates, a software application has roughly a 10 – 15 years life-cycle. Once the application starts approaching the end of its life-cycle, plans need to be drawn about replacing it or modernising it. The prominent question then arises, “How?”.
How do you modernise or replace a legacy system with a new one, whilst keeping things running smoothly without downtime or serious user frustration? Whilst there maybe other possible solutions, this article argues in favour of the Strangler Pattern, especially given that it has served us well in similar cases.
The Strangler Pattern allows for gradual, self-paced, manageable migration of the old to the new, which, within a business environment context, where everyone is already busy, makes total sense. When the new system comes on-line gradually, issues can be picked up much easier and quicker, ensuring the eventual “official” go-live is that much more trouble-free. This is in total contrast to the “big bang” approach where the new system is developed in its entirety on the sideline, and then commissioned in its entirety in one go. If the testing phase was not thorough enough, and it never is, then the go-live event might happen in iterations (several tries). The better the testing, the less the iterations (tries), but rollbacks are painful, when some data is in the new system and you have to go back to the old system. One word of caution though, beware of the big-bang approach. Usually, software development companies that have no experience or domain knowledge of the industry will propose the big-bang approach when the Strangler Pattern is the better option.
I guess the best reason for using the strangler pattern, is reduced risk. If your business has a very low appetite for risk, then the strangler pattern is your friend. Migrating one system segment at a time, means you have a backup if the new does not work as expected. The legacy system is still there until you are happy that the feature is working well in the new system. Another reason for using the strangler pattern is that it almost forces you into architecting the new system in a way that will enable you in the future to strangle it in the same way. Since the new code will become old sooner or later, this is an important consideration.
Some people may see the strangler pattern as a more expensive option and hence if the budget is a barrier, then it should be avoided. Although, it may take longer timewise to get to the end, the process avoids potential tangents or features that are later deemed useless or unnecessary. There are far fewer significant reworking or amendments after the official release with the strangler pattern than there are with the big-bang approach. Potential assumptions and tangents are picked up much earlier in the development life-cycle and therefore the end-product is that much more optimised to the actual requirements. Change requests are that much quicker and easier to implement earlier in the development life-cycle than they are in the latter end of the software development life-cycle, and therefore considerably cheaper.
When to use the Strangler Pattern?
You cannot use the Strangler Pattern on a green-field project. If there is no legacy system, or old application needing to be replaced, then you cannot use the strangler pattern. The only time you would consider the strangler pattern is when you are trying to replace / modernise an old legacy software package or system / application.
Another very important consideration is the commitment of the customer and / or other important stakeholders. Since the process may take longer and it will involve more of their input, it is important to have total commitment to the success of the project from all involved. Waiting for information, or for decisions can be time-consuming. Commitment, collaboration and good timely communication are essential. Without it will be hard.
Do not use this pattern when the system to be replaced is relatively small and lacks complexity. In those cases, the big-bang approach would be the better option.
Also, it is important to have access / control of the whole technology stack when using the strangler pattern. When you do not have a good view of the inner-workings (under the bonnet) of the business logic / layer and / or the data layer, it becomes a bit riskier. In those cases, proceed with great caution.
It helps a great deal when the development team has domain knowledge or experience, otherwise assumptions and a million questions addressed to the stakeholders will slow down the process and potentially introduce issues. Copying and pasting code is rarely possible when migrating features from legacy applications to new applications. A certain amount of code interpretation needs to happen, and in those cases, any amount of domain knowledge is precious.
One of the best commodities needed for this approach is time and resources. If time is very short or the resources (human and otherwise) are not there, it may not be a good idea to opt for the strangler pattern. Be realistic on time and effort estimates before commencing the project.
Conclusion
The Strangler Pattern is a powerful approach when it comes to migrating functionality from legacy old systems to new systems as part of a software development life-cycle. It can yield very good results if applied correctly. The method has a good track-record. We have successfully used it in the past and more recently. It is most useful and valuable where complexity is high. It requires commitment from all project stakeholders.