Migration 就是迁移的意思，这个机制在很多 web 程序和框架上很常见了。

一个朴素的 Migration 可以这样做：

• 为了功能 A，你需要为数据库增加新的表，于是将创建表格的 SQL 保存在 create_table_for_a.sql （文件名我随意取的）中，当 A 上线时，在数据库执行这个脚本
• 接着功能 B 也要做对数据库做改动，仿照做功能 A 时候的方法，创建了文件 sql_for_b.sql，并且在上线时，在数据库执行
• 继续同理...故略

随着项目的迭代，可以得到一组 SQL 文件，需要部署到新的环境的时候，只需要按照文件的顺序，依次执行即可。

以上就是最原始的做法，你可以在著名的基于 Java 技术的工作流引擎 Activiti 中看到 https://github.com/Activiti/Activiti/tree/master/activiti-engine/src/main/resources/org/activiti/db/upgrade 。

Rails 的 Migration 更先进，额外实现了如下特性：

• 实现了一组 Ruby 的 DSL，意味着你可以通过 Ruby 代码做 SQL 做的事情（主要是创建、修改、删除表和索引），这样使得（通常情况下）迁移脚本和具体数据库软件解耦，对比上文举的 Activiti 的例子，它为每一种它支持的数据库分别实现一遍 Migration SQL
• 可以调用项目中的模型，更方便的进行数据的更改。
• 标准化了数据迁移脚本的格式，使得不仅可以正向的迁移，程序发版有问题需要回滚的时候，可以回滚数据迁移
• 在数据库中增加了额外的迁移记录表，方便追踪迁移的执行，保证迁移不会重复执行，不是全新的数据库时 Rails 可以知道应当从哪条迁移脚本开始继续
• 约束了迁移脚本的格式（默认格式 时间戳_文件名.rb）解决了数据迁移的先后顺序问题
• 自动生成当前版本数据库表结构的快照（即“schema.rb"），于是可以实现快速部署到全新环境的数据库而无需依次执行迁移脚本，对比上文举的 Activiti 的例子，他（为每种它支持的数据库）单独提供一份最新版本的数据库的 SQL 用作全新环境的安装
• 提供了便捷的 rake task 去执行迁移、回滚、复位、创建、删除等迁移操作