Generally you want your database migrations described in a straightforward manner for development; the migrations will contain a straightforward change from old to new (and back).  With a live (busy) production database, it is often necessary to handle things differently to maintain up-time.<p>As a simple example, to make an atomic change to a write-only table, you could create a copy of the table, alter the copy as necessary, then in a single rename operation, rename the live table to &#x27;_old&#x27; and the &#x27;_new&#x27; table to live.  You most likely would not want to add two additional table schema and all of those steps to your development database operations.<p>It&#x27;s entirely possible that they could capture what is done in production as migrations, and test them first, but it would still likely be separate from what the application developers are working with.