When you want to change how your data is stored you have two options: 1) Don't touch the old data, and make sure all your code knows how to handle both the new

When you want to change how your data is stored you have two options: 1) Don't touch the old data, and make sure all your code knows how to handle both the new and old layouts 2) Update the old data to comply with the new layout #1 is cheaper in the moment, but makes your software more fragile because of the special cases: you now have two codepaths to check for every change instead of one. Also, whatever improvements the new layout is supposed to provide aren't available to the old records. #2 is more expensive right now, and scarier because your migration will be touching everything at once. If it starts trashing data, it'll trash all of it before you have a chance to stop it. On the other hand, after you've successfully migrated, all your data is consistent and you don't need to forever deal with legacy records in the active codebase. Both approaches can be used with either SQL or NoSQL datastores, and there's no reason you have to pick the same strategy for every schema change. There's pros and cons to both approaches and which one is better will depend on your particular situation.