Pretty often I have a need to migrate the location where some data is stored - to a new column, a new table, or even a new data store. And usually this needs to be done with no down-time. I can see two approaches. Either:

  1. Change all live writers to write new data to both locations
  2. Do a one-time migration of data from the old location to the new location
  3. Change all readers to read data from only the new location
  4. Stop writing new data to the old location


  1. Change all readers to read data from both locations, preferring the new location
  2. Change all writers to write new data to only the new location
  3. Do a one-time migration of data from the old location to the new location
  4. Stop reading data from the old location

I'm curious to hear thoughts or experiences on which approach is preferable, or if they have pros and cons. Is one or the other a more established practice?

  • 2
    This is a bit broad. Can you narrow your question down to a specific, software-design related problem you are having? Questions without some context seldom go well, as you're essentially asking "Tell me everything that can possibly go wrong under every possible circumstance." Jun 1, 2020 at 20:22

2 Answers 2


If you don't just copy the data, but also transform it in some way and you have a new feature that can only work with the new data, then the second approach means that you can deploy that new feature already with partial data while the transformation is still being done on the old data.

The first method on the other hand allows for a very easy rollback if something goes wrong.


When I have done this, I have taken essentially your first approach - for instance, when encrypting a database or changing its key. I say “essentially” because the double-write state can last quite some time, since there is no need to hurry and the database works well during it.

The one refinement is that there is a tidemark at any given moment, representing how far the copying process has progressed. A write below the tidemark is doubled (to old and to new). A write above the tidemark is written only to the old database, since the new data will be transferred to the new database when the copying process gets there.

One of the great attractions of this approach is that it can fail at any time without doing any harm: the “old” database is still fully live and the “new” one just gets discarded.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.