Legacy Bridge Laravel Package

Product Decisions This Supports

• Migration strategy (incremental vs. big-bang): The core decision this enables is whether to re-platform in one cutover or run a strangler-style migration. The bridge lets legacy eZ Publish modules, templates, and content-model behavior keep serving traffic behind the new Symfony-based eZ Platform stack while features are ported piecemeal. That changes the risk profile of the whole program, not just the technical approach.
• Scope and sequencing of the migration backlog: Because legacy functionality can be temporarily "carried" through the bridge, you can rank features by usage and business value instead of being forced to reach full parity before launch. This is a direct input to roadmap phasing and release planning.
• Build vs. buy for the compatibility layer: The alternative to adopting this is building and maintaining an in-house eZ Publish/eZ Platform shim. The bridge represents a "buy" (well, adopt) option that saves a likely multi-month engineering effort — provided the deprecation risk is acceptable.
• Feature parity and decommission criteria: Adoption forces a product decision on what must be re-implemented natively, what can live behind the bridge indefinitely, and what gets retired. It should produce an explicit exit milestone: target date, parity checklist, and decommission owner.
• Vendor/partner negotiations and budget: A bridged migration typically shifts cost from a large, risky upfront build to a longer, lower-peak maintenance tail. That reframes SI estimates and lets you argue for staged funding.
• Platform destination decision: The bridge only pays off if the destination is eZ Platform/Ibexa. If the strategic decision is to leave the eZ ecosystem, this package is a distraction.
• Supply-chain and maintenance budgeting: Because the package is archived, adopting it is also a decision to own a fork. That is a resourcing decision (headcount or partner retainer) that belongs on the roadmap, not buried in engineering.

When to Consider This Package

Consider it when:

• You run eZ Publish Legacy (4.x/5.x kernel) with a meaningful surface of custom extensions, legacy templates, or deep third-party integrations.
• The destination is eZ Platform / Ibexa DXP, and you need legacy functionality live during the transition.
• A hard cutover is infeasible — content volume, traffic, or business continuity rules out a freeze window.
• You need to migrate content and features in parallel workstreams to hit a timeline.
• You have in-house PHP/Symfony capacity (or a committed partner) to maintain a bridge component.

Look elsewhere when:

• You're greenfield, already on Ibexa DXP, or leaving the eZ ecosystem entirely — the package has no value.
• Maintenance risk is disqualifying. It is archived, last released 2020-11-16, has 17 stars and zero dependents. There will be no upstream fixes or security patches, and compatibility with current Ibexa releases is highly unlikely without your own fork work.
• License is unresolved. The repository reports NOASSERTION; procurement and legal should treat this as blocking until a definitive license is confirmed and cleared for your distribution model.
• Your legacy footprint is small enough that porting the handful of affected features is cheaper than operating a bridge.
• A supported alternative exists — vendor-assisted migration, Ibexa's own migration tooling, or a data-level export/re-import into the new content model — which usually beats owning an abandoned dependency.

How to Pitch It (Stakeholders)

For executives: This is a de-risking tool for the CMS migration, not a strategic platform bet. It lets us move to the modern eZ Platform/Ibexa stack incrementally, keeping the current site live and revenue-generating while we port capabilities at a controlled pace. It reduces big-bang cutover risk and opens up parallel workstreams, which is usually the difference between a migration that lands and one that stalls.

For engineering: It's the former LegacyBundle, extracted from eZ Platform core so it can be adopted optionally. It runs the legacy kernel alongside Symfony so legacy modules and templates can be served through the new stack. Be explicit about the constraints: archived, last release November 2020, minimal adoption, unclear license. That means no upstream fixes, no security patching, and version compatibility only with older eZ Platform releases. Adopting it means forking it and funding maintenance.

Recommendation: Treat it as time-boxed scaffolding with a funded exit plan, not a permanent architecture component. Gate adoption on four things: legal confirms the license, an engineering spike proves compatibility with your target eZ/Ibexa version, the roadmap carries an explicit decommission date and migration budget, and a fallback path is documented. If any gate fails, prefer a supported vendor-assisted or data-level migration instead.