Welcome to the This Dot Labs podcast, today we'll be talking about Software Migrations.
As a consulting firm, we regularly field requests from companies looking to revise elements of their products. These changes often take the form of migrations, through which we might change:
- Frontend Frameworks
- Cloud Providers
- Third-Party Integrations
- Defence Platforms
- State Management Systems
When discussing migrations, a lot of people find it hard to differentiate between migrations, refactoring, and adding new features. It's important to remember that when we refactor, a team’s developers usually understand the content already. In these instances, our goal is just trying to optimize how things work. With a migration, we not only have to move some code to a new framework, platform, etc., but the team has to be brought up-to-speed on the new concepts that are being implemented through this change prior to its implementation.
When simply introducing a new feature, a team expends effort, developers, time, or money to add new behaviors. The same goes for refactoring; we invest to get a more optimized system. Migrations require teams to invest just as much as refactors and new features, but give them the same system (essentially). Therefore, pitching migrations is difficult, because when you approach a business with a time and labor intensive plan, it is hard to convince them of the value in migrating when there will be no overtly apparent changes to the system functionality.
It raises a lot of questions around why we people migrate from one technology to another. Lately, lots of companies want to migrate to attract talent. As technologies fall out of date, it becomes harder and more expensive to find talent. Besides broadening the talent pool, migrating to new technologies also helps retain tech talent. Many developers like to feel like they're working with the latest technologies because it gives them a sense of career security. Sometimes, you see high-level architects join a team, and believe it's optimal to move to something else completely. Obviously pushing technology forward is great, but at the same time, that can financially burden their employer, and that's not always the ideal way to look at approaching the problem. Companies also migrate to keep their applications protected from security vulnerabilities.
Migrating frameworks doesn't come without it's fair share of problems. Proving that a migration offers enough value to justify the cost can be hard for developers since most times, it's impossible to measure that value. It can also be hard to keep track of new framework versions, and knowing which versions are worth migrating to can be difficult. Additionally, lots of people advocate for the use of lock files to control dependencies, rather than grabbing an entirely new set of dependencies that can instantly tank builds. However, migrations are definitely worth the costs when you consider benefits like higher talent retention, more secure applications, and technological longevity.
Most times, when carrying out migrations, the process is made much easier if there is a guide to walk developers through new versions. Many frameworks do this, and offer developers support during migrations. Angular, for example, does a great job with helping developers migrate to new versions. They have a CLI that can even update code to make sure the updates work properly. That being said, transition guides, and defined or automated processes, make it easier to update. Be it scripts, utilities, guides, or CLI, many frameworks make migrations easier.
We've talked about the arguments for and against migrations. I'm sure you're curious to know what the best way to carry out migrations is. Most people go with what we call the “Big Bang”, where the development team goes “dark” for a while, and implements the migration. Although the approach can be extremely tricky, it is the most time efficient way to do a migration. Some find it better to cut up migrations into milestones, and produce something deliverable, so that they can show their iterative progress, and can also stop working at some point in order to work on something that might be of a higher priority. Most also find it useful to have a good game plan that takes into account what pieces they're breaking up, how they are targeting them, and what they can expect to see, before they begin a migration. Something like this goes a long way towards both it being more efficient, and having better accountability to the people that are ultimately paying the bills.
Adding to that, you can introduce the concept of a Minimum Viable migration. Through this, you establish the minimum number of changes needed to do all new development in the migrated platform. This means running two different systems, and slowly porting things from one system to another.
Something worth bringing up, related to migrations, is that a lot of teams either don't have migration requirements, or the application was built bug-by-bug, or bug-fix-by-bug-fix, over a period of time. When this happens, most don't actually know where they are relative to where they started. Testing is such an integral part of all migrations. You need to know what you’re working with so you know when you've finished. When migrating the infrastructure of frameworks, it's important to have unit tests that aren't framework dependant, otherwise unit testing won’t work on the new system, which might be much more difficult for developers. It's much safer, and smarter, to rely on manual testing, end-to-end testing, integration testing, and other like processes. Sometimes such approaches might seem a bit non-traditional, but you want to make sure that you have the full suite of tests when migrating, because this is the best way to ensure that nothing has fallen through the cracks during the process.
That’s all we have on migrations today. It was great, as are all our conversations on performance and architecture. The conversation will not stop here. There's a lot more that we can cover, so you know we'll come back and have a chance to explore some of those at a later time. Till then.
About the author
