The migration checklist
This is the ninth and last installment in a series of blog posts on the topic of technology migrations. If you want to start from the very beginning, you can find an overview of the series and an index of the posts here.
The migration checklist
If you’ve endured this blog post series until the end, you may well be interested in a checklist to follow while running migrations, so you won’t have to read the entire thing again when you need it ;)
-
Before you start
- Make sure you have a monopoly over your technical area
- Check whether your team can migrate everything by itself in a reasonable time
- If you can, migrate everything by yourselves and stop here
-
Preparations
- Make sure your company really wants to do this migration
- Find a use case internal to your team or create one (using the old system)
- Find at least one sponsor teams with an easy use case
- Find at least one other sponsor team with a hard use case
-
Alpha – You
- Write design document
- Build prototype
- Write migration plan
- Set an estimated end date for the migration (you’ll miss it)
- Dark-launch your internal use case and compare with production
- Make sure your company really wants to do this migration (again)
- Migrate your internal use case
- Announce the alpha release
-
Beta – Sponsors
- Dark-launch the sponsors’ use cases and compare the results with production
- Write the first draft of the migration guide
- Make sure your company really wants to do this migration (yes, again)
- Set up a channel to broadcast regular migration progress updates (don’t stop until the end)
- Subscribe management to the above channel
- Migrate the easy use cases using the migration guide
- Migrate the hard use cases using the migration guide
- Send a migration progress update and announce the beta release
- Polish the migration guide
- Wait and help whoever asks to be migrated (if anyone)
-
Automation – Bystanders
- Polish your technology until you feel confident
- Write automation to migrate most use cases without users’ intervention
- Automatically track your migration progress
- Wait
- Make sure your company really wants to do this migration (it is not too late)
- If you decided to stop, do a retrospective
- Draft a release announcement focused on the benefits for the users
- Set an estimated end date for the migration (you’ll miss it again)
- Announce widely the stable release, the deprecation of the old system and your migration plan
- Stick deprecation warnings all over the old system documents and user-facing tools
- Automatically migrate all the use cases you can
- Automatically create tickets for all remaining use cases
- Send migration progress update
- Wait
-
Nudges – Adopters
- Nudge all remaining users to migrate (be creative!)
- Wait
- Check migration progress
- Send migration progress update
- Repeat until the number of use cases migrated per round is low and constant (or zero) for at least two iterations
-
Fat tail – Laggards
- Identify the remaining use cases that must be migrated
- Remind management and the team that you have to finish this
- Tell the owners you will take care of migrating their use cases for them
- Set an estimated end date for the migration (this time, stick with it)
- Communicate as widely as possible that the old system will be terminated on that date
- Migrate the must-be-migrated use cases
- Send migration progress update
-
Deprecation – Victims
- Shut down the old system (but be ready to roll back)
- Watch the world burn
- If it burns too hot, roll back
- Set an estimated end date for the migration (don’t give up!)
- Migrate the newly discovered must-be-migrated use cases
- Send migration progress update
- Repeat until the old system has been shut down
- Delete anything even remotely related to the old system (or it will haunt you)
- Send final migration progress update
- Celebrate with your team (you have earned it)
Antonio Uccio Verardi
from meta import engineering_manager