# Data Migrations in Production

**URL:** <https://www.ruby-forum.com/t/data-migrations-in-production/156419>\
**Category:** Rails\
**Created:** [December 27, 2008, 4:05am UTC](https://www.ruby-forum.com/t/data-migrations-in-production/156419 "2008-12-27T04:05:40Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mikec](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/977dab/32.png) [@mikec](https://www.ruby-forum.com/u/mikec)\
**Post date:** [December 27, 2008, 4:05am UTC](https://www.ruby-forum.com/t/data-migrations-in-production/156419/1 "2008-12-27T04:05:40Z")

</div>

General question - when you deploy a new production version, how do  
you normally handle the data migration? I’m leery of applying “spot”  
changes directly to the prod DB - I would prefer to have an unchanged  
version to roll back to. (Could always backup and restore of  
course…) I haven’t seen much literature on running a data  
migration script to move from one prod DB to another with changes  
applied on the fly, so I’m guessing people don’t do that…

---

<div class="post-metadata">

**Author:** ![mikec](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/977dab/32.png) [@mikec](https://www.ruby-forum.com/u/mikec)\
**Post date:** [December 27, 2008, 1:16pm UTC](https://www.ruby-forum.com/t/data-migrations-in-production/156419/2 "2008-12-27T13:16:37Z")

</div>

On 27 Dec 2008, at 03:04, Mike wrote:

> General question - when you deploy a new production version, how do  
> you normally handle the data migration? I’m leery of applying “spot”  
> changes directly to the prod DB - I would prefer to have an unchanged  
> version to roll back to. (Could always backup and restore of  
> course…) I haven’t seen much literature on running a data  
> migration script to move from one prod DB to another with changes  
> applied on the fly, so I’m guessing people don’t do that…

As far as being able to roll back to stuff, we just stop replication  
between the master and the primary slave while we do migrations etc…  
If it all goes tits up we can fallback to the slave which has the  
database prior to the migrations and also has the previous version of  
any code that it runs.

Fred