Laravel Data Migrations Laravel Package

Product Decisions This Supports

• Build vs. buy for data versioning. This package separates data migrations (seeding reference rows, backfilling computed columns, normalizing legacy values) from schema migrations, with a history table so each data change runs once per environment. Adopt it rather than building an in-house runner when you already have recurring, ordered data-change needs across staging and production.
• Roadmap and platform-upgrade timing. v3.0.0 sets a hard floor of PHP 8.2+ / Laravel 11–12, and PHP 8.3+ / Laravel 13. If your roadmap still includes Laravel 10 or earlier, this package cannot be part of the plan until that upgrade lands — conversely, teams already on Laravel 11+ should treat it as available now.
• Vendor and maintenance risk. This is a fork: the original author (jlorente/laravel-data-migrations) handed maintenance to Lacodix. The fork is new, the maintainer set is small (one contributor on the initial release), and there are no namespace aliases and no Composer replace of the upstream package. That is a genuine supply-chain signal to weigh in a build-vs-buy or dependency-approval decision, especially if the package would touch production data.
• Release and deployment process design. Because data changes become versioned, reviewable, deployable artifacts, this supports decisions like "data fixes ship through CI, not ad-hoc SQL by hand" and "every environment can be brought to a known data state" — useful for onboarding, ephemeral/preview environments, and audit trails.
• Laravel 13 readiness. The release includes the upstream fix for command registration on Laravel 13.24+, preserving Laravel's native migrate:install alongside the package's commands. This makes the package a viable pick for teams planning a Laravel 13 upgrade rather than a blocker.
• Not a fit for: simple one-off seed data (db:seed + seeders), schema-only work (native migrations), or teams unwilling to absorb a namespace refactor.

When to Consider This Package

Adopt when all of the following hold:

• You are on Laravel 11 or 12 (PHP 8.2+) or Laravel 13 (PHP 8.3+), and you accept the stated caveat that "Laravel 11 compatibility does not imply ongoing security support" — i.e. you have your own plan for staying on a supported Laravel line.
• You have repeatable, ordered data changes that must run exactly once per environment and must not be re-run: reference/lookup table seeding, backfills after schema changes, data normalizations, tenant or config row provisioning.
• You want those changes in code review and CI, with a history table providing idempotency and an audit trail.
• You can own a one-time migration cost for existing installs: swap jlorente/laravel-data-migrations for lacodix/laravel-data-migrations (^3.0), rewrite every Jlorente\DataMigrations import to Lacodix\LaravelDataMigrations, update manual service-provider/class references, then refresh the autoloader and cached config/provider metadata. Existing migration files, directories, history table, and history records are preserved — no data rewrite or replay — provided the prior install was explicitly configured. If it was not, verify the history-table location before running anything.
• You are comfortable with a young, single-maintainer fork of a previously established package, and you have an exit plan (the migration surface is small and the history table is plain data, so a fallback is feasible).

Look elsewhere when:

• You are on Laravel 10 or earlier — explicitly unsupported in v3.
• Your data needs are genuinely one-shot or trivial; native seeders and manual steps are cheaper than a dependency.
• Your dependency policy forbids recently forked packages or requires a bus-factor above one maintainer for anything touching production data.
• You need legacy namespace compatibility or a Composer-level drop-in replacement — neither exists, so any upgrade is a deliberate code change, not a version bump.
• Never install both packages side by side; the docs are explicit about this, so treat dual-install as an unsupported configuration.

How to Pitch It (Stakeholders)

For executives: This is a small, focused Laravel library that makes data changes — reference data, backfills, cleanups — versioned and reviewable like code, instead of being run by hand in production. It was just taken over by a new maintainer (Lacodix) from the original author, released as v3.0.0, and modernized to support Laravel 11–13 on PHP 8.2+. The trade-off to acknowledge is maintenance risk: it is a new fork with a thin maintainer base, so it belongs in the "useful but monitor" bucket rather than the "critical path" bucket. Cost of adoption is low for new projects and a bounded, mechanical rename for anyone already using the upstream package.

For engineering: v3.0.0 is a fork-and-rename release, not a feature release. Two breaking changes: the Composer package moves from jlorente/laravel-data-migrations to lacodix/laravel-data-migrations, and the namespace moves from Jlorente\DataMigrations to Lacodix\LaravelDataMigrations. There are no aliases and no Composer replace, so upgrading means removing the upstream dependency, installing ^3.0, updating imports and any manual service-provider/class references, then clearing autoloader and cached config/provider metadata. Do not install both packages together. Migration files, directories, the configured history table, and existing history records carry over — no data rewrite or replay — but installations without explicit configuration should confirm the history-table location before the first run. Support matrix tightens to PHP 8.2+ with Laravel 11/12 and PHP 8.3+ with Laravel 13; Laravel 10 and earlier are dropped. The release also carries the upstream command-registration fix for Laravel 13.24+, which keeps Laravel's native migrate:install working alongside the package's commands. Net: adopt for data-versioning needs on supported Laravel lines, plan the rename as a discrete ticket, and keep an eye on release cadence given the new maintainership.