Legacy Bridge Laravel Package

Technical Evaluation

Framework fit — the headline caveat. This is not a Laravel package. ezsystems/legacy-bridge is a Symfony bundle (EzSystems\LegacyBridgeBundle) that lets an eZ Platform (Ibexa) application boot the eZ Publish Legacy kernel alongside the modern stack and route matching requests into it. There is no Illuminate contract, no service provider, no Laravel package manifest, and no support for Laravel's HTTP kernel, queue, or container. For a Laravel-centric roadmap, its only legitimate role is as an external system behind a strangled reverse-proxy boundary — not as a Composer dependency inside a Laravel app. A TPM should treat "Laravel/PHP package" here as "PHP ecosystem package adjacent to Symfony," and record the mismatch as a first-order finding rather than a footnote.

Architecture fit. Where it does fit, the pattern is sound: one deployable, two kernels, shared database and session, URL/module-level routing deciding whether the legacy kernel or the Symfony stack serves a request. That is the classic incremental-migration shape a TPM wants, because it avoids a big-bang rewrite of legacy modules, templates, and content model. But it only fits if the organization actually runs eZ Publish Legacy today. Without an existing legacy install, there is nothing to bridge and the package is inert.

Integration feasibility. Moderate-to-poor, dominated by version pinning. The last release was November 2020, the repo is archived, and it targets the eZ Platform 1.x/2.x era. eZ Publish Legacy itself is effectively frozen and constrains PHP to the 5.6–7.x window, while the modern side of the bridge increasingly wants 7.4+/8.x. Running both kernels means satisfying the intersection of two runtimes — usually an old PHP the platform team does not want to patch. That intersection, not the bridge code, is the real integration cost.

Technical risk.

• Unmaintained upstream: archived, zero dependents, no security response. Any CVE in either kernel or in the bridge itself is ours to fix.
• License ambiguity: NOASSERTION. eZ Publish Legacy heritage is GPL-2.0, which carries copyleft obligations if we distribute or expose the combined work. This needs legal review before it becomes load-bearing, not after.
• Zero-dependency signal: 17 stars and no dependents means almost no community hardening; we will be the largest user.
• Dual-schema coupling: shared database with legacy ez* tables and platform tables creates migration-order hazards and one-way-ish content changes.

Key questions. Is there a live eZ Publish Legacy estate, and how many modules/templates actually need bridging? What is the smallest PHP version intersection we can accept, and for how long? Is GPL-2.0 acceptable for our distribution model? Has anyone budgeted for owning an archived fork? Is the strategic alternative a rewrite of the residual legacy modules rather than a bridge?

Integration Approach

Stack fit. Place the bridge outside the Laravel application. The Laravel side should never require it; instead, terminate legacy URLs at nginx/ALB (or a thin Laravel route that reverse-proxies) and route them to an eZ Platform deployment that includes LegacyBridge. This keeps Laravel's dependency graph clean, keeps PHP version requirements separated by process, and preserves a single future cutover point.

Migration path. Strangler-fig, module by module: inventory legacy modules and URL prefixes, stand up eZ Platform + LegacyBridge with legacy routing enabled for all of them, then retire legacy routing one prefix at a time as each module is reimplemented in Laravel or eZ Platform. The bridge is the scaffolding, not the destination — plan its removal date at kickoff.

Compatibility. Verify the exact matrix before committing: eZ Publish Legacy version, eZ Platform/Ibexa version, PHP version on both sides, database engine/version, and whether any auth/session assumptions hold across kernels. Because the repo is archived, expect to vendor a fork and possibly backport PHP and security fixes ourselves. Treat composer.lock as a frozen artifact and mirror packages internally.

Sequencing. 1) Legal/license opinion. 2) Legacy estate inventory and URL map. 3) Runtime intersection decision and infrastructure spike. 4) Fork-and-vendor if approved. 5) Pilot with one low-risk legacy module behind the proxy. 6) Ramp module-by-module with a decommission checklist per module. Do not invert this order — the license and runtime questions can invalidate the entire approach.

Operational Impact

Maintenance. This is the dominant cost. We inherit an archived bundle plus an end-of-life legacy kernel plus a frozen PHP runtime. Budget for a named owner, an internal fork, a CVE watch on both stacks, and periodic patch backports. Dependency upgrades on the modern side will repeatedly collide with legacy constraints; expect to pin and defer.

Support. No upstream support channel and a shrinking pool of engineers who know eZ Publish Legacy's template language, module system, and data model. Hiring and vendor support are both thin. Institutional knowledge must be documented deliberately, because attrition here is a single point of failure.

Scaling. Two kernels in one request lifecycle means higher memory and slower cold paths; legacy cache and Symfony cache must both be warmed and invalidated coherently. Horizontal scaling works, but per-request latency and cache-coherence bugs will surface under load. Shared sessions and shared database concentrate the blast radius.

Failure modes. Legacy kernel fatals bleeding into platform responses; database schema drift between ez* tables and platform tables; cache invalidation split-brain; session/auth mismatch across kernels causing intermittent logouts; and silent behavioral divergence where a module is half-migrated. Each needs an explicit rollback switch in routing.

Ramp-up. Two to three weeks for a PHP/Symfony engineer to be productive, longer for the legacy template and module layer; realistically a quarter before a team can safely own it. Treat the bridge as a time-boxed tactical asset with a scheduled end-of-life, and make decommissioning a tracked deliverable rather than an aspiration.