App Migrations Resilience
Podcast: Play in new window | Download (36.0MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
Applications are like motor oil. They don’t last forever (for a variety of reasons) and they become a problem over time if you leave them alone. While legacy apps probably were great in their day (otherwise you wouldn’t be replacing them with a better version in most cases), apps have a limited lifetime. At some point, you are better off with a rewrite, especially if earlier decisions have made upgrading and refactoring impossible.
While it is common to want to do all the work to build a new version of the app and then just migrate everyone over, doing so requires taking huge risks. Not only does it mean that the legacy app hangs around for most of you clients for that much longer, but it also greatly increases the risk that something will go wrong across the board once people do migrate. Further, a great deal of institutional knowledge is ALWAYS encoded in old apps, if you know how to look for it.
Instead of trying to migrate everything at once, you need a process that allows you to make mistakes and (more importantly) to both recover from and learn from those mistakes. In short, rather than a perfect process, you need to develop a “perfecting” process. Several things are required for this. First, you need to reduce the number of places where things can wrong. Second, you need to be able to determine what went wrong quickly. Third, you need to be able to quickly adjust, and try again. While the final goal is a full migration, your goal until the last moment is the cultivation of a feedback loop that continually moves you closer to your goal.
Migrating clients to a new system is something we all have to do at some point. However, you don’t want to ruin everyone’s experience of your app, so you need to handle the process smoothly. Ideally, clients should see no loss in functionality after a migration and should not be impacted when someone else migrates. Additionally, you need to make sure that the migration process itself doesn’t interfere with active development or conceal other system issues. Finally, you want to make sure that both your systems and the people that run them can deal with the migration process without getting overloaded.
Join Us On Patreon
Level Up Financial Planning
Donate to Beej’s Mission Fund
Memo: Put “BJ Burns” in Memo