あるプロジェクトにおいて、諸事情でSQLを直接実行してテーブルを作成していましたが、
途中から Laravel のマイグレーション機能で管理・運用することになりました。その際の移行手順です。
状況
- 反映したいマイグレーションファイルは全て作成済み
- DBには、一部のマイグレーションファイルの内容がSQL直接実行により反映済み
-
migrationsテーブルに記録がない、もしくは不完全な状態
準備：反映済みファイルの特定
まず、どのファイルまでが既にDBへ反映されているかを正確にリストアップします。
DBへ反映済の database/migrations フォルダ内のファイル名を特定してください。
手順
1. migrations テーブルの確認・作成
migrations テーブルが存在しない場合は、一度空の状態で作成します。
php artisan migrate:install
実行結果例:
Migration table created successfully.
2. 反映済みファイルの「記録」を挿入する
既にDBに構造が存在するマイグレーションファイルについて、「実行済み」として migrations テーブルに登録します。これにより、次回以降の実行対象から除外されます。
実行コマンド例（SQL）:
2025_01_02_000000_create_posts_table.php まで反映済みの場合：
INSERT INTO migrations (migration, batch) VALUES
('2025_01_01_000000_create_users_table', 1),
('2025_01_02_000000_create_posts_table', 1);
※ バッチ番号(
batch)は、1,2,3と振っても問題ありませんが、まとめて1としておけば、後でまとめてロールバック（戻す操作）ができるようになります。
3. 未実行のマイグレーションを実行する
まだDBに反映されていない残りのマイグレーションを Laravel 経由で実行します。
実行コマンド:
php artisan migrate
実行結果例:
Migrating: 2025_02_01_000000_create_comments_table
Migrated: 2025_02_01_000000_create_comments_table (15.23ms)
Database migration completed successfully.
（※既に登録した users や posts はスキップされ、comments 以降が実行されます）
注意点
整合性の確認
「手順2」で migrations テーブルに登録するファイル名は、DBの現在の構造と100%一致している必要があります。
- 登録し忘れると →
php artisan migrate実行時に「Table already exists（テーブルは既に存在します）」というエラーが出て停止します - 過剰に登録すると → DBに存在しないのに「実行済み」としてしまうと、カラムが足りない等の不具合が発生します
バックアップ
万が一、既存のテーブルを破壊してしまうリスクを考え、作業前にはダンプ（バックアップ）を取得しておきましょう。
まとめ
この手順を踏むことで、既存のDB構造を壊すことなく、Laravel のマイグレーション管理下とすることができます。