Legacy Migration Playbook – Segment the New from the Old
So far, we have covered five “plays” we can run during a legacy migration. These plays can be used independently, or they can be used together; it all depends upon the situation. Each solution/situation is somewhat unique.
Each legacy project requires a different approach. Sometimes the right answer is to leave the existing solution in place and build something alongside it. That is what I will cover in this post.
Wait, isn’t building something new alongside the existing solution the same thing as the strangler pattern we already covered?
Sort of. With the strangler pattern as we tend to use it, we strangle out the legacy system. Many legacy systems have many stable subsystems that we can live with. Rarely is everything bad. That should be restated: rarely is everything bad. Many systems have subsystems that can live on for years and not require any massive changes.
When working with legacy systems, the secret isn’t just figuring out how to redo it but identifying what to redo (and finding what to leave in place). If you have a stable subsystem that hasn’t been changed frequently, it is probably okay to continue using it.
But even if there are a few subsystems that can live on, we are still faced with adding new functionality. In that case, you are left with two decisions: continue to add functionality inside of the existing system or build a parallel system for the new features.
Usually, you are better off adding to the existing system and refactoring within that world. But if the new code is substantially different than the existing code, adding it to the current system might be slower. And if you feel the existing system has many stable subsystems, leaving them in place reduces the risk of breaking everything.
We applied this technique to a project this year. We rehosted the existing legacy system in an Azure App Service and then created a new Azure App Service for the new code to address our mobile use cases. While this technique doesn’t apply to all legacy migrations, it is one to keep in mind.
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
