Ezmigrationbundle Laravel Package

Technical Evaluation

Architecture fit. ezsystems/ezmigrationbundle is a Symfony bundle for eZ Platform / eZ Publish 5.x that provides Doctrine-style, programmatic deployment of database structure and content changes (the successor to the legacy ezxmlinstaller). It fits only a legacy eZ stack: PHP 5.6+ and eZ Platform / Enterprise 5.4 / Community 2014.11 or later, registered via registerBundles(). That describes a narrow, largely EOL deployment surface; nothing about the architecture targets modern Ibexa DXP or current Symfony/PHP.

Integration feasibility. Low. The repository is archived, carries 1 star, 0 dependents, and its own README states it is "an internal fork of kaliop migration bundle for use in our demos… not supported and will be completely replaced in the future." Critically, the installation instructions tell you to require kaliop/ezmigrationbundle ^5.0 rather than the fork — a signal the fork's Composer identity and actual runtime code may be inconsistent, and that the maintainable artifact is upstream, not this repo. GPL-2.0 is also a licensing consideration if any downstream code is proprietary.

Technical risk. High. Unsupported + archived means no security patches, no bug fixes, and no compatibility work for current PHP/Symfony. The PHP 5.6-era baseline will likely conflict with modern Composer constraints. Fork divergence from upstream creates a silent-drift hazard, and "will be completely replaced" gives no migration guarantee or timeline.

Key questions.

• What is the actual business need — content/structural migrations for demos, or production-grade deployment?
• Are we on eZ Platform/Publish 5.x, or Ibexa DXP (in which case this is a non-starter without significant re-evaluation)?
• Why not use upstream kaliop/ezmigrationbundle or Ibexa's official migration tooling directly?
• Does GPL-2.0 fit our distribution and licensing posture?
• If used, can we pin a commit and vendor it, and who owns the migration scripts long-term?

Integration Approach

Stack fit. Acceptable only for legacy eZ Platform / eZ Publish 5.4+ on Symfony 2/3-era stacks. Do not introduce it into fresh builds or modern Ibexa projects.

Migration path. Treat this fork as a demo-scoped artifact, not a platform dependency. Where the same capability is needed durably, evaluate upstream kaliop/ezmigrationbundle (the fork's own README points here) or Ibexa's supported migration mechanisms, and plan the exit from the fork before it is adopted.

Compatibility. Verify PHP version support against our runtime (5.6+ baseline; effectively untested on modern PHP) and check Composer constraints for Symfony version conflicts. Expect to pin versions and possibly patch constraints locally.

Sequencing.

1. Confirm the stack is genuinely legacy eZ and the need is demo/migration-only.
2. Pilot in a non-production environment with a small, representative migration.
3. Validate idempotency and rollback behavior of migration definitions.
4. If viable, vendor-pin the fork and constrain usage to demos with an explicit deprecation/exit plan.
5. Otherwise, substitute upstream or official tooling immediately.

Operational Impact

Maintenance. No upstream maintainer; the repo is archived. If adopted, ownership transfers entirely to us: patching, version pinning, and eventually replacement are internal responsibilities.

Support. None. Documentation is the fork's README plus whatever upstream Kaliop docs still apply; expect gaps and staleness, and no vendor escalation path.

Scaling. Migrations run via console commands; throughput is bounded by content volume and per-migration PHP execution. No active optimization or performance roadmap exists, so large content sets should be benchmarked in the pilot.

Failure modes. Silent drift between fork and upstream; PHP/Symfony incompatibility blocking upgrades; partial or non-idempotent migrations corrupting content state; missing security patches on a GPL-licensed dependency; an abandoned package becoming a hard blocker during platform upgrades.

Ramp-up. Shallow learning curve (DoctrineMigrations-like model, familiar to Symfony teams), but the real cost is long-term ownership and eventual migration off the fork. Recommend documenting it as a short-lived, demo-only dependency with a named owner and a dated exit criterion.