Laravel Migrations Generator Laravel Package

Product Decisions This Supports

• Brownfield adoption / migration to Laravel. When the target is an existing application with a live database (the common case for replatforming a legacy PHP, Rails, or .NET app onto Laravel), this package removes the single most tedious and error-prone workstream: hand-writing hundreds of Schema::create calls that must match the existing schema exactly. It lets us scope the Laravel migration as an application-layer rewrite rather than a schema rewrite.
• Build vs. buy on schema introspection. Writing our own artisan command that introspects INFORMATION_SCHEMA, pg_catalog, sqlite_master, and SQL Server system tables — across columns, indexes, foreign keys, views, stored procedures, generated/virtual columns, enums, table comments, and user-defined types — is a multi-sprint effort with a long tail of dialect bugs. Buying (at MIT license, zero cost) is the clear call. Adopt rather than build unless we have a database platform it does not cover.
• Roadmap sequencing for a "modernize" initiative. Generation gives us a concrete, demoable artifact early: php artisan migrate:generate --squash produces a reviewable schema baseline. That de-risks the rest of the plan, because CI, seeders, model scaffolding, and test fixtures all depend on a reproducible schema existing first.
• Scope decisions on database coverage. Five first-party Laravel databases are supported (MySQL, MariaDB, PostgreSQL, SQL Server, SQLite), so a single tool covers every environment we are likely to encounter — dev on SQLite, prod on PostgreSQL or MySQL, an enterprise customer on SQL Server. That means we do not need a per-dialect contingency in estimates.
• Feature flags for phasing. The option surface maps directly onto delivery phases: --tables / --ignore for incremental table-by-table cutover; --skip-views, --skip-proc, --skip-foreign-keys to defer hard problems (views and stored procedures usually belong to a later phase, or are deliberately dropped); --connection for parallel-run against a replica.
• Onboarding and knowledge transfer. Generated migrations are executable documentation of a legacy schema, including index and FK names that no one documented. Useful for new engineers and for architecture review of an inherited system.
• Test-environment bootstrapping. A generated baseline plus --log-with-batch=0 gives a fast path to a schema-faithful test database, which unblocks integration testing before the application rewrite is far along.
• Squash decision. --squash (one file) vs. per-table files is a real product choice: squash for a clean single baseline commit on greenfield-ish replatforms, per-table for teams that will iterate on individual tables during a phased cutover.

When to Consider This Package

Consider adoption when most of these hold:

• We are standing up Laravel against a pre-existing database we do not control the DDL for, or one whose original migration history has been lost.
• The schema is non-trivial — dozens of tables with indexes, foreign keys, composite keys, enums, and generated columns. Below roughly ten simple tables, hand-writing migrations is faster than reviewing generated output.
• The database is one of the five Laravel first-party platforms. This is a hard requirement; anything else (Oracle, DB2, CockroachDB, MongoDB) is a "look elsewhere" signal.
• The target Laravel version is current — v7.3.0 added Laravel 13 support, and v7.2.0 fixed default-value escaping for Laravel 12.20+, so recent framework versions are actively tracked.
• We have engineering capacity to review the generated output. This is a generator, not a compiler with a correctness guarantee; every file must be read, and the resulting schema verified against the source by running migrations against a restored dump.

Look elsewhere, or treat as insufficient on its own, when:

• We need ongoing bidirectional sync. This is a one-shot reverse-engineering tool. Once migrations exist, they are the source of truth; there is no drift detection, no re-generation diff, no "apply database changes back into migrations." Teams that expect to keep generating against a live DB as it evolves will end up with duplicated or conflicting migration files. Pair with a schema-diff or dump-comparison step in CI if the legacy DB keeps changing during the transition.
• The database relies heavily on stored procedures and triggers. Procedures are partially supported (v6.5.0+), but triggers are not a headline capability. If the legacy system's business logic lives largely in the database, this tool generates the container, not the logic — budget a separate workstream.
• We want model/controller scaffolding too. This generates only migrations. Model and factory generation is a different tool (e.g. relies on reliese/laravel or similar); plan accordingly.
• Team is uncomfortable with a dev-only, community-maintained dependency. It is MIT, ~2.9k stars, has CI, codecov, and a consistent release cadence, but it is single-maintainer-led. Risk is low because it is a --dev dependency never shipped to production, but governance review should note it.
• The schema is enormous and irregular (hundreds of tables with legacy naming, no FKs, reserved-word columns). Generation still helps, but expect substantial manual normalization; the tool faithfully reproduces the mess, including the parts you wanted to fix.

How to Pitch It (Stakeholders)

One line: A free, MIT-licensed developer tool that turns an existing database into Laravel migration files automatically — including indexes, foreign keys, views, and stored procedures — so a legacy-database replatform starts from an accurate schema instead of weeks of manual transcription.

To executives: It removes a large, low-value, high-risk block of work from the modernization critical path. The alternative — hand-writing migrations for an inherited schema — is pure cost with no product differentiation, and it is where subtle bugs (wrong index, missing FK, mismatched column type) hide until production. We can generate a reviewable schema baseline in an afternoon, which makes the rest of the roadmap easier to estimate and lets us demonstrate progress to stakeholders early. Cost is zero; it is a development-time dependency and never ships to production. The main thing we are buying is schedule confidence, not a feature.

To engineering: It is a composer require --dev package with a service provider auto-registered, invoked as php artisan migrate:generate, and configured through the existing config/database.php connections. It supports all five first-party Laravel databases and tracks the current framework (Laravel 13 in v7.3.0, Laravel 12.20 default-value escaping in v7.2.0). Practical guidance: generate with --squash for a single reviewable baseline or leave it per-table if we are cutting over incrementally; use --tables and --ignore to control scope; use --skip-views, --skip-proc, and --skip-foreign-keys to defer what belongs in a later phase; use --log-with-batch=0 so the baseline sorts first; and use --default-index-names / --default-fk-names if we want Laravel's naming conventions rather than the legacy database's. Two explicit caveats: the generated files are a starting point that must be code-reviewed and verified by running migrations against a restored dump, and the tool is one-directional — after generation, our migrations are the source of truth and the legacy database must not be treated as a schema oracle. Budget for a post-generation normalization pass regardless of how clean the output looks.