Legacy Migration Playbook – Introduction
There are a lot of working solutions out there. And there’s a lot of code behind those solutions.
Along with those solutions are often many reasons why they need to be upgraded (and not just enhanced with new features). Sometimes the weight of technical debt becomes too large. Sometimes technology changes out from under a project. Sometimes business needs change, and the software needs to change to support those needs.
A playbook contains a list of plays a team may run. Not necessarily an order for those plays, and not necessarily a list of plays they will run every week. When I used to coach my son’s flag football team, we had about 12 plays. Six plays, really – left and right for each. But of those, we usually only ran about eight to ten plays. Sometimes when a game was going well, I’d mix in another play. When things weren’t going as well, I’d coach a little more conservatively to help keep things simple for the kids.
Legacy migrations are often the most challenging aspect of software engineering. You won’t find many other projects with so many tradeoffs, but engineering is an art of tradeoffs. While there are usually no easy answers to your most sticky questions, there are things we can do to arrive at a good solution as quickly as possible.
In this series, we will go through many of the plays we use here at Don’t Panic Labs when working on legacy migrations. None of these plays were invented by us, but they are common when dealing with legacy systems.
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
I hope this will be a fun and enlightening series. Stay tuned…
