Minimizing risk with production data migrations

Sometimes you need to reshape some core, critical data in production.

You might wish there was a way around it, but the best choice is to bite the bullet and do it.

How can you approach this in a way that will give you the greatest confidence nothing will go wrong when it’s deployed?

There are few things I do in this situation, and I think they are all essential.

First, if possible, consider putting the data manipulation in a command, instead of inside the schema migration.

This will give you affordances like a progress bar, nicer logging, and explicit control of timeouts. And if you write the command correctly, you can run the command more than once without causing data corruption.

Next, just like any application feature, write automated tests for your data migration. And think defensively. Write tests where a field that should never be empty (but isn’t NOT NULL in the schema) is missing. Look at every line of code in your data migration and make sure at least one test is exercising that logic.

This will give you a ton of extra confidence.

Finally, if you can, run the data migration locally on a recent copy of the production database. Sometimes this isn’t practical if the data is sensitive, but even a sanitized copy of the data is better than nothing.

This is the ultimate test of how it will work in production. It may catch some edge cases you didn’t consider in your testing. Or it might highlight some performance issues you didn’t run into with your local development data.

And one final bonus: make a plan for how to recover if something unexpected still goes wrong. Will you roll the migration back? Will you restore from a backup?

Thinking this plan through will help you stay calm if something does happen, and get you back to a working app more quickly.

Here to help,

Joel

P.S. Need help with a tricky data migration? Let’s talk about it.