Long Migrations
Hey!
Welcome back to another week of musings. I hope you had a great weekend and manage to rest!
Today is the beginning of Hispanic Heritage Month!
Was this forwarded to you? You can subscribe here!
Things I enjoyed in the past week
How To Honour Your Curiosities is a good video on how having multiple hobbies or passions might seem overwhelming or confusing, but if it's aligned with your core values it is a good thing!
I've been thinking of taking a hiking trip with my family, and I've been seeing a lot of hiking content, such as this video from a YouTuber who hiked the John Muir Trail.
In relation to hiking, I also began reading "A Philosophy of Walking" by Frédéric Gros*.
I've been working through some migrations over the last couple of years, and if you've run migrations for your organization, you know that they can be tedious, burn out people, or leave everyone tired if they're very long (e.g., years).
I've also complained, and heard a range of possible complaints, from "I don't like the new UI" to "My workflow is completely broken because of this niche use case I was hacking into the old system." I have to listen to all complaints, categorize them, and integrate them into the project; in many cases, they won't stop a migration. Migrations are one of the primary ways organizations can pay down tech debt.
Prepare as much as possible
While we might never be fully prepared, there are many edge cases in practice due to Hyrum's Law.
It's good to listen to current customers and their use cases; some might not be possible to migrate as is, or we might disappoint others. Document differences as much as possible, create a migration plan, and clearly outline what will happen by when, as well as the benefits of implementing this approach.
One of the aspects of preparing is also being ready to listen to the customers and their feedback.
In other cases, being prepared also means making some hard choices, like shutting down systems or passing ownership of a system to a team that doesn't want to migrate, etc.
Create a sense of progress
The lack of progress in a project can be very demotivating for all, and often, you may have a large migration, such as moving all CI workloads from Jenkins to GitHub Actions.
If you work for an established and large company, you may have thousands of jobs and clusters to manage and migrate to the new approach. Workloads without clear owners, people, or complete teams that have moved off and left things running, but have been abandoned.
While weekly or monthly email updates might be beneficial, such as when we're at 400 out of 5,000 workloads. It might be better to set up "artificial" milestones, such as migrating the largest workload or the most complex one, and celebrate that.
Beware of the long tail
One of the most challenging aspects of a migration is the work post-migration. You might have set your new system up and running, but you might have had to create a sub-system to keep an old database in sync, or let some teams with complex use cases use the old system for a while.
What I've done in this case, besides sending emails and other communications, is that the migration is over. After one or two months, I've done "scream tests" where we shut off the old system, or the sync process, etc. First, a few hours, then a day, then full weeks, and so on.
Your turn!
Have you ever had to run a migration at work? How did it go? What did you learn from it? Let me know your thoughts by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others