kitloong/laravel-migrations-generator: reverse-engineering Laravel migrations from a live schema

The problem: a database with no migration history

Laravel assumes migrations are the record of how a schema came to be. Real projects often arrive the other way round: a database built by hand, by a legacy application, or by a DBA over several years, and a new Laravel codebase that has to treat it as its own. Writing migration files for a hundred tables by hand is mechanical work, and mechanical work is where mistakes live, particularly around index names and composite foreign keys.

This package exists for that specific handover moment. It reads the live schema through a Laravel database connection and emits migration files that describe what it found. The audience is a developer who has just been handed the connection details and needs the schema expressed in Laravel's own vocabulary, not someone who wants an ongoing schema management tool.

How generation works: tables first, foreign keys second

The README describes a two-pass order. The generator first emits the tables, columns and indexes, and afterward sets up the foreign key constraints. That ordering is not cosmetic. A foreign key migration that runs before the table it points at will fail, so the generator separates the two concerns into different files and relies on filename timestamps to sequence them.

By default it writes multiple migration files, one per table. The --squash flag collapses everything into a single file instead. The --tables and --ignore options take comma-separated lists, so a partial generation is possible. There is also a --connection option for databases that are not on the default connection, and a --path option controlling where files land. Views and stored procedures appear in the option table as their own filename patterns, which tells you the generator is not limited to tables.

The two-pass design has a consequence the README states plainly: include all the tables listed in the foreign keys so that they are present when the foreign keys are created. Generate a subset and you can end up with constraint files pointing at tables that were never generated.

Installing it and generating your first migration set

The README recommends installing through Composer as a development dependency. The --dev flag matters here: this is a scaffolding tool you run against a database, not something your application should load in production.

composer require --dev kitloong/laravel-migrations-generator

Laravel registers the service provider automatically. Lumen does not, and the README gives the manual steps for bootstrap/app.php. Before generating anything, the database connection has to exist in config/database.php, because the generator reads through that connection rather than accepting raw credentials.

A first run against the default connection, writing migrations for every table, is a single command:

php artisan migrate:generate

If the schema is large and you only want part of it, name the tables explicitly. The README's example uses five table names in one comma-separated string:

php artisan migrate:generate --tables="table1,table2,table3,table4,table5"

The inverse is available too, for the common case where a few tables belong to another system:

php artisan migrate:generate --ignore="table3,table4,table5"

For a non-default connection, pass its name as configured in config/database.php:

php artisan migrate:generate --connection="connection_name"

If you would rather review one file than dozens, squash the output:

php artisan migrate:generate --squash

Run php artisan help migrate:generate for the full option list; the README points there rather than enumerating every flag.

The limitations you should weigh before adopting it

This is a one-directional tool. It reads a schema and writes files. Nothing in the README describes comparing a database against existing migrations, detecting drift, or producing a diff. If your schema changes after generation, the generator will not tell you. You either regenerate and reconcile by hand, or you go back to writing migrations manually.

The foreign key ordering is the sharpest edge. Because constraints are emitted after tables, and because the README instructs you to include every table referenced by a foreign key, a partial run is a real failure mode. Generating only the tables you care about can produce constraint migrations that reference tables absent from the migration directory, and those files will fail when run in sequence.

There is also a naming question. The option table lists --default-index-names, described as not using DB index names for migrations. That flag exists because databases and Laravel do not always agree on how an index should be named, and the choice has downstream effects if you later compare schemas. The README lists the flag without spelling out the trade-off, so you are left to decide which naming convention your project wants.

Finally, the tool is scoped to Laravel's first-party databases: MariaDB, MySQL, PostgreSQL, SQL Server and SQLite. Anything outside that set is not covered.

Alternatives and how their approach differs

Two older generators come up in the same searches: xethron/migrations-generator and Bennett Treptow's laravel-migration-generator. They occupy the same niche, converting an existing schema into migration files, but they predate the current Laravel version line. The practical difference is maintenance and version fit rather than philosophy: kitloong's package is on the 7.x branch with a release in May 2026, while the older generators are tied to earlier Laravel releases. If you are on a current Laravel version, checking whether an older generator supports it is work you can skip by using this one.

The other alternative is not a generator at all. Laravel's own migrate and make:migration commands handle schema evolution from the migration side, and if your project already has a migration history, that is the correct tool. The generator is for the case where no history exists. Using it to maintain a schema that already has migrations inverts its purpose, and the README offers nothing for that workflow.

Maintenance, licensing and what a regeneration costs you

The repository is not archived. The last push was on 2026-05-10, which is the same day v7.4.0 was released; v7.3.0 came on 2026-03-15 and v7.2.0 on 2025-08-10. Releases are not on a fixed cadence, and the gap between v7.2.0 and v7.3.0 was roughly seven months, so treat the package as maintained when needed rather than continuously churning.

The licence is MIT, which is permissive and places few obligations on how you use or redistribute the generated files. That is a statement about the licence text, not legal advice; if your organisation has policies about dependency licences, run the check through your normal process.

The upgrade cost is mostly in the generated output, not the package. Because the generator is a dev dependency you run on demand, upgrading it does not change your application's runtime behaviour. What changes is the shape of the files it produces. A new major version can alter generated migration structure, and if you regenerate against a database whose schema has moved on, you are diffing two sets of hand-edited files. The cheap path is to generate once, commit the result, and then treat those files as ordinary migrations you maintain yourself.

Editorial conclusion

Adopt it when you have inherited a database with no migration history and you need Laravel to own the schema: generate once, review the files by hand, then treat them as the source of truth. Do not adopt it as a diffing or synchronization tool, because the README describes generation only, with no way to reconcile later schema drift. Before committing anything, verify the generated foreign key files against the real constraints, since the README warns that tables listed in foreign keys must be included in the same run or the constraint files will reference tables that do not exist in the migration set.

Frequently asked questions

Official sources

1. Issues
2. kitloong/laravel-migrations-generator on GitHub
3. License: MIT
4. README
5. Releases