Weave Code
Laravel Data Migrations Laravel Package
lacodix/laravel-data-migrations
Laravel Data Migrations adds versioned data migrations to Laravel apps, letting you ship seed and data changes alongside schema migrations with tracking and repeatable, idempotent execution.
An extension to allow you to separate data migrations from structure migrations
Frequently asked questions about Laravel Data Migrations
- What is lacodix/laravel-data-migrations and what problem does it solve?
- It is a Laravel package that separates data migrations from structure migrations, so one-off data operations such as backfills, column transforms and reference-data seeding live in their own versioned migration files instead of being mixed into schema changes. Each data migration is recorded in a history table using the same ordered, recorded execution model Laravel developers already understand, with repeatable and idempotent execution. It is added as a single Composer dependency with convention-based migration files.
- How do I install lacodix/laravel-data-migrations in a Laravel project?
- Require it with Composer using the 3.x constraint: composer require lacodix/laravel-data-migrations:^3.0. Then publish and verify the package configuration, write your data migration files following the package conventions, and run the package's artisan commands to execute them. Laravel 11 to 12 on PHP 8.2 or newer, or Laravel 13 on PHP 8.3 or newer, is required.
- Which Laravel and PHP versions does laravel-data-migrations 3.x support?
- Version 3.x targets Laravel 11 and 12 on PHP 8.2 or newer, and Laravel 13 on PHP 8.3 or newer. Laravel 10 and below, and PHP below 8.2, are unsupported by this release, so those applications remain on the unmaintained upstream 2.x line. Note that Laravel 11 compatibility is a functional statement and does not imply an ongoing security patch guarantee.
- How is this different from Laravel's built-in schema migrations?
- Laravel's migrator is built for structure such as tables, columns and indexes, and its files are treated as schema history. This package handles the separate concern of data: versioned, tracked one-off operations like backfills or reference-data seeding, recorded in their own history table. Keeping the two apart lets data changes ship alongside schema migrations without polluting your schema migration timeline.
- I already use jlorente/laravel-data-migrations 2.x, how do I move to lacodix?
- The upgrade is a mechanical but mandatory cut-over: every Jlorente\DataMigrations namespace import, plus any manual service-provider registration or class references in config, must be rewritten to the new namespace. There are no namespace aliases and no Composer replace directive, so it is an explicit switch rather than a transparent swap. Verify the history table name before running any data migration afterwards.
- Can jlorente/laravel-data-migrations and lacodix/laravel-data-migrations be installed at the same time?
- No. The release notes explicitly prohibit installing both, because coexisting packages lead to duplicate or ambiguous class definitions or a Composer conflict. Any transitive dependency still pinned to jlorente/* will block the upgrade until it moves, so audit with composer why jlorente/laravel-data-migrations across your repositories first.
- Where does laravel-data-migrations store its history table and how do I configure it?
- Applied data migrations are recorded in a history table whose name and location come from the package configuration. Installations that never published an explicit config should verify where the existing history table actually lives before upgrading. A wrong table name makes the package treat already-applied data migrations as pending, which is dangerous for destructive or non-idempotent operations. Correctly configured installs keep their migration files, directories, history table and records and need no data rewrite.
- Are data migrations in this package idempotent and safe to re-run?
- The package provides tracked, repeatable, idempotent execution, but that guarantee depends on your migration code, since a raw INSERT or a destructive UPDATE is not magically safe. If your existing data migrations are not idempotent, treat history-table verification as a hard gate before any post-upgrade run. Otherwise a re-run against production data becomes a data incident rather than a deploy hiccup.
- How do I test data migrations before running them in production?
- Because data migrations are versioned files with recorded history, you can exercise them in a local or CI database much like schema migrations: run them against a seeded copy, assert the resulting data, and confirm the history records are written. Check the configured history table in each environment first so nothing is re-applied unexpectedly. Keep destructive operations behind idempotent guards so repeated CI runs stay safe.
- Is lacodix/laravel-data-migrations actively maintained and what are the alternatives?
- It is a fork under new stewardship, and the inaugural 3.0.0 release has a single contributor, so bus factor and long-term release cadence are unproven while the upstream jlorente package is effectively retired. There is no documented support policy beyond the version compatibility table, and Laravel 11 support does not imply an ongoing security patch guarantee. Alternatives are keeping one-off data operations inside ordinary schema migrations, or writing bespoke artisan commands or jobs backed by your own tracking table. If you need a guaranteed patch cadence, raise that governance question with the maintainer before adopting.
Weaver
How can I help you explore Laravel packages today?