マイグレーション履歴（データベースのスキーマ変更履歴）とは
マイグレーション履歴とは、データベースのテーブル構造（スキーマ）の変更を、順序付きのスクリプトとしてコードと一緒に版管理したものです。RailsやLaravel、Prisma、Drupalのアップデートフックなどが仕組みを提供し、履歴があれば空のデータベースから本番と同じ構造を再現できます。履歴が無い事業は、本番DBの構造とコードの対応関係が誰にも分からず、環境の再構築も安全な変更もできません。
ソースコードはGitで管理されていても、データベースの構造は「本番のDBを直接いじった」まま放置されている事業は珍しくありません。テーブルを1つ足した、カラムの型を変えた、インデックスを張った。その変更がコードに残っていなければ、買主は本番DBをダンプして構造を推測するしかなく、コードが期待する構造と本番の構造がずれている箇所を、障害が起きて初めて知ることになります。
マイグレーション履歴が整備されている事業では、①環境の再現——ステージング環境や買主の検証環境を、空のDBからコードだけで作れる。②変更の安全性——次にテーブルを変えるとき、履歴に1本追加して各環境に順に適用でき、手作業の適用漏れが起きない。③ロールバック——変更を戻す手順も履歴にある。④コードとの対応——「このカラムはいつ、なぜ足されたか」がコミット履歴と一緒に読める。技術デューデリジェンスでは、マイグレーションの仕組みが使われているか、履歴が本番と一致しているか（本番にだけ存在するテーブルやカラムが無いか）、履歴の途中に手作業の穴が無いかを確認します。マイグレーション履歴の無いDBは、バックアップがあっても「戻せる」保証が無いのと同じ状態です。
RIKKA M&Aの技術デューデリジェンスは、リポジトリの構造からマイグレーションの仕組み（フレームワーク標準の仕組みや独自のスクリプト）の有無を読み取りますが、本番DBとの一致は運用環境にアクセスしなければ確認できません。納品スペースで受け渡すDBダンプと、コード中のマイグレーション履歴を検収時に突き合わせることが、買主にできる最も確実な確認です。当社自身も、DBスキーマの定義と更新フックの両方向の一致を機械的に検査する運用をとっています。