title: How to most securely and effectively handle the data migration between different database versions / document structures?
body: <p>Premise 1: The structure of your documents will change over time due to new features, updates, etc. <br> Premise 2: Not all user documents will end up on your server, because sync is a premium feature. <br>
  Premise 3: The web or mobile client expects the data to come from the database in a certain structure to function properly.</p>
  <p>--&gt; I need to handle data migration on the client. <br>
  --&gt; I need to keep track of all database versions / document structures that ever existed and make sure that I migrate them safely to the current version, because otherwise the data corrupts and the app cannot be used anymore.<br>
  --&gt; If something goes wrong, there is no easy way to solve it, because the data is on the client and I can't solve it from the server.</p>
  <p>Solution 1: I store the version of the database in a document and create a 'migrateDB' function that checks the database version during startup and migrates all documents if needed. <br>
  --&gt; Requires less verbose code during subsequent database reads, because the client can expect the data to be safely migrated and in the right structure <br>
  --&gt; If something goes wrong during the migration, the app basically can't be used anymore</p>
  <p>Solution 2: The client migrates the documents on demand by checking the structure on every read and updating them if the structure is not as expected.  <br>
  --&gt; This would require very verbose code for reading documents from the database. It would have to handle every possible structure the data could still be stored in the database.  <br>
  --&gt; You will end up with a database in which some documents still have the old structure (because they haven't been read yet), while others have already been migrated</p>
  <p>Solution 3: Solution 1 + Solution 2</p>
  <p>Solution 4: ?</p>
  <p>How do you deal with this?</p>