Ibexa Migration Bundle2 Laravel Package

Technical Evaluation

Architecture fit

The package name is misleading in a Laravel context: mrk-te/ibexa-migration-bundle2 is a Symfony bundle for Ibexa DXP 5, not a Laravel package. It extends Bundle, registers console commands via the Symfony DI container, and depends on Ibexa's content repository APIs (ibexa/content, ibexa/core, Field Type services). It cannot be installed into a Laravel application without effectively standing up an Ibexa kernel alongside it — which is not a realistic integration.

• If the target stack is Ibexa DXP 5 / Symfony: strong architectural fit. It is a direct port of the long-standing Kaliop eZ-Migration Bundle, which was the de facto standard for scripted content migration in the eZ/Ibexa ecosystem for a decade. The mental model (YAML migration files + ibexa:migration:migrate CLI command) is well understood by Ibexa developers.
• If the target stack is Laravel: hard no. Different framework, different ORM, different content model. There is no adapter path worth pursuing.
• If the target stack is Ibexa 3.3/4.x: check compatibility explicitly — this bundle targets Ibexa 5, and the underlying repository API and Field Type namespaces shifted across major versions.

Integration feasibility

Low-to-moderate effort on Ibexa 5, but with unusually high diligence requirements given the adoption profile:

• Installation is a standard Composer require plus bundle registration in config/bundles.php, migration path configuration, and CLI invocation. A competent Ibexa developer can run a first migration in a day.
• The real work is in the migration files themselves: content type mapping, Field Type value structures, relations, locations, URL aliases, and object states. That effort is largely independent of which migration bundle you use.
• Critical unknown: Packagist availability and version constraints. With 0 dependents and 1 star, verify the package installs cleanly with composer require against a current Ibexa 5 skeleton before planning around it.

Technical risk

The dominant risks are licensing and bus factor, not code quality:

1. GPL-2.0 copyleft. The original Kaliop bundle was GPL-2.0, and this port inherits it. For a proprietary commercial Ibexa site, shipping a GPL-2.0 Composer dependency triggers a legal review. In PHP the "derivative work" boundary is contested, but most enterprise legal teams will either reject it outright or require it to be confined to dev/CI tooling never deployed to production. This is the single highest-probability blocker and should be resolved before any engineering spend.
2. Bus factor of one. A single maintainer (mrk-te), 1 star, 0 dependents, no ecosystem validation. The release date (2026-09-18) suggests it is actively maintained today, but the maintenance commitment is almost certainly driven by one agency's own client work.
3. No community test surface. With zero dependents there is effectively no field validation. You will be an early adopter discovering the edge cases.
4. API drift against Ibexa 5 minor releases. Ibexa's content repository is not a stable public contract across minors; expect breakage on upgrade and budget for it.

Key questions to resolve before committing

• What is our actual framework target — Ibexa DXP 5, or Laravel? (If Laravel, terminate the evaluation here.)
• Has legal signed off on a GPL-2.0 runtime dependency? If not, can we restrict this to CI/staging only, and is that acceptable to the migration use case?
• Is the maintainer available for a support arrangement, or do we need to plan for an internal fork from day one?
• Which Field Types, Page Builder blocks, and Commerce objects are in scope, and does the port cover them? The Kaliop original had gaps in custom Field Types; a fresh port likely has more.
• Is there a rollback story, or are migrations one-way?
• Does it handle Solr/Elasticsearch reindexing and legacy URL alias regeneration, or is that on us?

Integration Approach

Stack fit

• Target: Ibexa DXP 5 on Symfony 6/7, PHP 8.2+. Confirm the exact Ibexa 5 minor and PHP constraint from composer.json before scoping.
• Non-target: Laravel. The package has no Laravel service provider, no Eloquent integration, and no reason to exist in that stack. If the brief genuinely calls for a Laravel-side migration tool, the answer is a bespoke Artisan command set or a package like spatie/laravel-migration-style tooling — not this.
• Adjacent: If the organization runs both Laravel apps and an Ibexa CMS, this bundle belongs strictly on the Ibexa side; the Laravel app would consume migrated content via Ibexa's REST/GraphQL API.

Migration path

The realistic path is an upgrade of an existing Kaliop-based migration suite, not a greenfield adoption:

1. Inventory existing Kaliop migration YAML files if the project is coming from eZ Platform 2.x / Ibexa 3.x/4.x.
2. Diff the DSL: namespace changes, Field Type identifier changes, and removed helpers are the usual breakage points.
3. Re-run each migration against a restored copy of production content in a disposable environment; treat every migration as needing re-validation.
4. For greenfield Ibexa 5 projects, evaluate this bundle against writing one-off Symfony console commands. For a small, one-time content load, bespoke commands may be cheaper and carry no GPL exposure.

Compatibility

• Pin an exact version; do not use a floating constraint given the maintainer profile.
• Test against the specific Ibexa 5 patch level in use, and re-test on every Ibexa minor bump.
• Verify PHP version and Symfony version constraints align with the host project before promising a timeline.

Sequencing

1. Week 0 — license and framework gate. Legal review of GPL-2.0; confirm Ibexa 5 target. Kill the initiative here if either fails.
2. Week 1 — spike. Install into a throwaway Ibexa 5 skeleton, run a 3–4 migration proof covering a custom content type, a relation, and a location. This validates the port's completeness faster than reading code.
3. Week 2 — coverage audit. Map every in-scope content type and Field Type to a supported migration step. Flag gaps and estimate custom step development.
4. Week 3+ — build the migration suite behind a CI harness with a fixture database, so migrations are regression-tested rather than manually eyeballed.
5. Cutover against a production clone, with a documented rollback (database snapshot restore) and a scheduled search reindex.

Operational Impact

Maintenance

Assume internal ownership within 6–12 months. A 1-star, 0-dependent package with a single maintainer is a plausible abandonment candidate the moment that maintainer's client engagement ends. Practical mitigations:

• Vendor the package into the repo or maintain a private fork from the start, so upstream disappearance is a non-event.
• Track upstream via a pinned git ref and a documented rebase procedure.
• Budget roughly 5–10% of one engineer's time for dependency upkeep across Ibexa minor releases.

Support

Community-only. GitHub issues with a single responder, no SLA, no documented support tier. If migrations are business-critical (they usually are during a launch window), plan for an internal subject-matter expert rather than relying on upstream responsiveness. The Kaliop original's documentation remains the best functional reference; the port's docs are likely thin, and behavioral deltas between the two are undocumented.

Scaling

Migrations are synchronous CLI processes operating row-by-row against the content repository. That means:

• Large content sets (10k+ objects) require batching with explicit offsets and resumable migration design; a single long-running process will hit memory limits or timeouts.
• Writes go through the full Ibexa persistence stack, so throughput is materially lower than raw SQL — plan for hours, not minutes, on substantial imports.
• There is no built-in parallel execution; horizontal scaling means partitioning by content subtree and running multiple workers, which introduces ordering hazards for relations.
• Search index (Solr/Elasticsearch) and HTTP cache invalidation lag behind writes; a full reindex must be part of the runbook.

Failure modes

• Partial application. If migrations are not wrapped in per-step transactions (and Ibexa's repository does not offer clean cross-object transactions), a mid-run failure leaves content in a half-migrated state. Mitigation: idempotent, re-runnable steps and a database snapshot before every run.
• Silent partial success. Steps that swallow exceptions and log warnings produce a "successful" run with missing content. Mitigation: post-migration assertion counts in CI.
• Content ID drift. Re-running against a database that already has some objects can produce duplicates or overwrite unintended content. Mitigation: strict match-on-identifier semantics and a clean target database.
• Relation and URL alias breakage. Ordering dependencies between migrations are easy to get wrong; broken aliases surface as SEO damage weeks later.
• Search/cache desync. Content appears correct in the admin UI but not on the front end until reindex and cache clear.
• Upstream breakage on Ibexa upgrade. A minor Ibexa bump changes a repository API signature, and with one maintainer the fix may take weeks.
• License exposure. If GPL-2.0 obligations are triggered and unmanaged, the failure mode is legal, not technical — and it is the most expensive one here.

Ramp-up

• Ibexa-experienced developer: productive in 2–3 days; the Kaliop DSL is familiar territory.
• Laravel/general PHP developer new to Ibexa: 2–3 weeks. The bottleneck is not the bundle, it is Ibexa's content model — locations vs. content vs. versions, Field Type value objects, and the repository API.
• Team-level: plan a half-day knowledge share on the migration DSL plus a written runbook covering snapshot → run → assert → reindex → cache clear. Without that runbook, the migration becomes tribal knowledge held by one person, which reintroduces the bus-factor problem internally.

Bottom line for the TPM: this is a legitimate, narrowly-scoped tool for Ibexa DXP 5 content migration with a credible lineage, but it carries outsized licensing and maintenance risk relative to its 1-star adoption profile. Gate the decision on (a) confirming the stack is Ibexa, not Laravel, and (b) a legal ruling on GPL-2.0. If both clear, adopt with a private fork and a CI harness. If either fails, fall back to bespoke Symfony console commands — the migration file authoring effort is largely the same, and the dependency risk disappears.