Migrating to a new database is an exciting and daunting challenge. There is tremendous upside for applications and operations at the end of the migration process, but all too often the migration takes longer than expected or is left in a partially complete state. Many technical challenges are well solved but stakeholders have different goals that complicate completing the migration successfully and on time.
You can avoid common pitfalls and get your new database completely serving production data on a reliable timeline by asking and answering the following five questions:
Is it more important to be right or available?
When choosing a migration approach, it’s important to understand if reducing downtime is more important than making sure that the applications working with the data always have exactly the right data. If you can’t afford an for your application to return errors during downtime, but it’s okay if a response is potentially off by a bit (e.g. a UI application showing a graph), then consider an inconsistent migration to reduce downtime as much as possible. If your application is tracking money, you probably would rather have an error returned to the application than show an incorrect balance in an account, so choose a consistent migration approach with either minimal downtime or a planned downtime window.
How long can each application tolerate downtime?
If your application is for a business that is not open at night, you may be okay with downtime during the evening to make the migration happen. This flexibility can simplify your approach. However, if your users are spread out across different timezones or if its unacceptable for your users to ever experience a hiccup, then you need to understand your SLOs and retry capabilities to decide whether downtime of seconds or minutes is suitable. The answer will inform your planning.
Migrate all at once or in a phased approach?
Applications that interact with each other often might need to be migrated all at once. Maybe readers and writers interact with a single table often, and so cutover to the new database has to happen in one go. If not, maybe you have flexibility to do a phased approach that allows for testing one application at a time which limits the blast radius of changes.
When does the migration need to be complete?
Does this migration need to be done in the next week because your system is bursting at the seams and a bigger incident is coming if you don’t migrate? Or can the migration take a full year and budgets aren’t a concern?
If you need it done in the next week, downtime might be necessary because the planning process to make a “zero-downtime” migration happen is thorough.
Who is in charge of what part of the project?
If you don’t know who owns what, you can’t effectively plan. Remember that migrations are projects, not hackathons. Define clear roles for the people involved. And utilize the experts to build a meticulous plan.
If, for example, you’re migrating to CockroachDB there will be a support architect who can customize a migration strategy based on your business needs and your technical stack.
If you want to learn more about migrating databases take a look at our migration overview documentation. In that documentation you’ll find details about the tools available (like AWS DMS) for streamlining parts of the migration process. You’ll also find suggested strategies and more details about preparation and execution of successful database migrations.
