ひとことで言うと
マイグレーションは、データベースの構造変更を手順書としてコードに残し、環境をまたいで同じ状態に揃えられるようにする仕組みです。
テーブルの追加・カラムの変更・インデックスの設定など、開発が進むと構造は何度も変わります。 その変更を SQL を直接打ち込むのではなくコードとして管理することで、開発・ステージング・本番すべてを同じ手順で更新でき、変更履歴も残ります。
たとえ話でもう少し詳しく
マイグレーションは、建物の改修工事の手順書に近いです。
- 「2階に部屋を追加する」「古い壁を取り除く」などの工程を文書に残す
- 別の建物でも同じ手順書どおりに作業すれば同じ状態になる
- 問題が起きたら、手順書を逆にたどって元に戻せる
データベースでも同じです。 「users テーブルに email カラムを追加する」という変更をマイグレーションファイルに書いておけば、開発環境でも本番環境でも同じコマンドを実行するだけで同じ構造になります。 また、変更を取り消す手順（ロールバック）も一緒に書いておくことで、問題が起きたときに戻しやすくなります。
よく出る場面・使いどころ
- 新機能開発にあわせてテーブルやカラムを追加するとき
- 本番環境のデータベースをアプリの新バージョンにあわせて更新するとき
- チームで開発していて、全員のローカル環境を同じ構造に揃えたいとき
- 過去の変更履歴を確認・追跡したいとき
似た言葉との違い
- データベース
- データを保存・管理する仕組み全体
- マイグレーションはそのデータベースの構造を変えるための手続き
- バックアップ
- 現時点のデータを丸ごと保存しておく仕組み
- マイグレーション前にバックアップを取ることで、失敗時に戻れる状態を用意する
- デプロイ
- アプリの新しいコードを本番環境に反映する作業
- マイグレーションはデプロイと一緒に実行されることが多い
実務で気にするポイント
- マイグレーションを実行する前にバックアップを取る
- ロールバック（元に戻す手順）も一緒に書いておく
- データが大量にある本番環境では、カラム追加でも時間がかかることを想定する
- 複数人が同時にマイグレーションを追加したとき、順番の衝突に気をつける
注意: カラムの削除やデータ型の変更は、既存のデータが消えたり壊れたりすることがあります。本番環境で実行する前に、ステージング環境で動作確認し、バックアップを取った上で慎重に進めましょう。