Laravel Conditional Migrations Laravel Package

Product Decisions This Supports

• The underlying capability is worth deciding on; this package is not. The need — running schema changes only in specific environments, or making a migration optional — is a real product problem that teams hit as soon as they have local, staging, and production databases diverging. That decision is still open. The delivery vehicle is closed: the package is archived, deprecated in favor of mll-lab/laravel-utils v4.0.0, and will receive no further updates.
• Build vs. buy, resolved to "buy the successor." Migration is low-effort: the successor is from the same maintainer, so the mental model and API surface should be familiar. Buying from an actively maintained package beats both (a) adopting an archived one and (b) hand-rolling environment guards in migrations, which is where teams end up by default.
• Roadmap input: none, by definition. An archived dependency cannot appear on a roadmap as a forward-looking commitment. It can only appear as a scheduled removal or upgrade item. Treat this as a sunset/consolidation decision, not an adoption decision.
• Feature scoping. Conditional migrations enable work that is otherwise awkward to sequence: backfills that should only run once against production, seed-like changes that must not touch staging, optional schema changes gated behind a config flag, and per-environment column adds during staged rollouts. If those use cases are on your roadmap, the capability is a prerequisite — but it should be sourced from a maintained dependency.
• Risk-register entry. A deprecated, archived, 1-star package with zero dependents is a negative signal on three axes at once: maintainer intent, community validation, and failure blast radius if it breaks. The prior technical evaluation flagged patch-level version exclusions (e.g., "mark Laravel 9.21 as unsupported") as a fragility indicator. That fragility is now moot for this package and inherited by whatever replaces it — validate the successor's version matrix the same way before committing.
• Vendor-consolidation decision. If this is already in a codebase, the decision it drives is a scheduled dependency removal, not a feature bet. If it is not, the decision it drives is "add laravel-utils with the same scrutiny as any new dependency, or add twenty lines of internal convention."

When to Consider This Package

Consider only in one narrow case: it is already installed and pinned in a legacy Laravel 9.x application, composer.lock holds it, the Laravel patch version is confirmed outside the excluded 9.21, and the cost of migrating to the successor is genuinely higher than the cost of carrying it for one more release cycle. Even then, this is a deferral, not a choice — scope the removal date at the same time you accept the deferral.

Look elsewhere in every other case:

• New projects. Do not add an archived, deprecated package to a new codebase. The successor exists and is the maintainer's stated path forward.
• Laravel 10 or 11. Support breadth beyond the 9.x line is not established here, and no further releases are coming to establish it. Assume unsupported.
• Any team that needs security patching to flow through dependencies. An archived package cannot track Laravel patch releases. You will eventually be choosing between a Laravel upgrade and this dependency, and you will lose that choice.
• Any team that needs support or a bug fix. There is no upstream to escalate to, no issue triage, and zero dependents means no de facto community maintenance.
• Multi-service or multi-tenant estates. Patch-level compatibility constraints multiply across services; maintaining an unmaintained dependency across N applications is a recurring tax with no upside.

The alternative worth weighing against any third-party option: an internal convention. A plain environment or config guard at the top of a migration, plus a documented standard for how optional migrations are written, captures most of the value for teams whose need is "sometimes skip a migration in staging." Reach for a package when you need rollback-awareness, migration-history consistency, and a consistent API across many migrations and many engineers — which is exactly the problem the successor package claims to solve.

How to Pitch It (Stakeholders)

For executives — one paragraph. There is a legitimate engineering need to run database schema changes selectively across environments, and we should address it. The specific open-source package we evaluated for this is no longer viable: it is archived, officially deprecated by its own maintainer in favor of a successor package, has one GitHub star, no downstream dependents, and has not shipped since February 2023. Adopting it would create a dependency we cannot patch, cannot get support for, and will have to remove later. The recommended path is either the maintainer's designated successor (mll-lab/laravel-utils v4.0.0) or a small internal convention, and the cost of either is a fraction of the cost of carrying a dead dependency. No customer-facing impact either way; this is infrastructure hygiene and a minor scheduling item.

For engineering — the short version. Capability: good, and worth having. Package: dead. Route to laravel-utils v4.0.0 or implement env/config guards directly in migrations. If a service already depends on this, it is a removal ticket with a date, not a supported component. When evaluating the successor, carry forward the lesson from this one: a release note that excludes a specific Laravel patch is a warning about framework-internals coupling. Confirm the successor's supported version matrix, whether exclusions are enforced via composer.json conflict entries or only documented, and pin the exact Laravel patch in CI so drift into an untested combination fails loudly rather than silently.