Migrating to a New Database
Come migration time, if you’re (very!) lucky, you can go offline, and Just Take Care Of It . Odds are, however, that it isn’t going to be that simple — systems that can’t go offline, customers that scream really loud, money, whatever. In that case, the general strategy tends to be some variation of the following 1. Migrate Creates / Updates / Deletes to the New Every time you insert/update/delete data into your old database, you do the same on the new database. You’re still Read ing from the old database however, so in case things go south, you find a bug, etc., you can just totally nuke the new database and start again from scratch And yeah, theres a whole bunch of detail here around preloading, metrics, alerts (•), and so forth that I’m eliding 2. Serve (some!) Reads from the New In -1- , all your Read s came from the old environment. Now, you can, and should, start serving Read s from the new environment. Mind you, if at all pos...