Have you ever pushed a web application to live status, and then had a developer start screaming down the hall about how you forgot to add the middle_name field to the users table? Or, have you ever dripped sweat onto your desk while you manually rename fields on your production database to fit a new application push just hoping that you don't break something?

Migrations are built to solve this problem. Using a very simple versioning process, Rails' migrations allow developers and DBAs to get along happily during deployment by taking control of the situation in a predictable manner. A migration represents a change in the database from one version to the next. Migrations are applied in order. For instance, when you roll out the new feature to the production server, the migrations give an easy-to-read (no SQL required) description of what needs to change in the database for the new code to function. Not only that, migrations allow us to setup the commands to roll-back the database and reverse the changes we just made, if a problem is found.

Migrations are not just for Rails developers. The same ideas present in them could be extended to many different frameworks and platforms. Come see what all the fuss is about!