Ezpublish Legacy Laravel Package

Product Decisions This Supports

• Legacy CMS: maintain vs. migrate. This package is the incumbent baseline, not a candidate. Use it to frame the roadmap decision: keep a frozen eZ Publish deployment on life support, or fund a migration to Ibexa DXP / eZ Platform or a modern headless CMS.
• Build vs. buy (as "sunk cost vs. replacement cost"). Quantifies what the current platform costs to own (hosting, PHP version ceiling, contractor rates for a niche stack) against the cost of migration. There is no "build" case here — only "stay" vs. "leave."
• Migration scoping and content-modeling. The kernel + 3 legacy extensions architecture maps directly onto content types, workflows, URL aliasing, and permission structures that must be preserved or deliberately retired in the target platform.
• Risk register entries. EOL upstream (archived), last release 2020-10-16, NOASSERTION license, PHP ceiling, deprecated dependency graph — each becomes a tracked risk with an owner and a target remediation date.
• Vendor and procurement review. Confirm whether commercial support exists through Ibexa, what the actual license terms are, and whether code can be reused in the successor platform.
• Sunset / decommission planning. Data retention windows, export formats, redirect strategy, and a kill date the business has signed off on.
• Audit and compliance documentation. What the running code does, for security review or regulatory evidence.

Low star count (251) and low opportunity score are consistent: this is a maintenance artifact, not a growth lever.

When to Consider This Package

Consider it only when:

• You already operate an eZ Publish 4.x/5.x installation and need to patch, containerize, or freeze it while a migration runs.
• You need reference behavior — legacy extension semantics, content mapping, URL rules — to make migration decisions.
• You are running a cost-of-ownership or vendor-dependency audit of the incumbent platform.
• Compliance requires documenting the archived code's behavior or license terms.

Look elsewhere when:

• Any greenfield project. Use Ibexa DXP, Symfony-based eZ Platform, or a modern headless CMS.
• Security-sensitive or regulated workloads. No upstream security releases since 2020; NOASSERTION license is a legal ambiguity.
• You need PHP 8+, an actively maintained framework, or vendor SLAs.
• The real question is "should we migrate?" The package is evidence for that decision, not the answer — don't let "evaluate the package" substitute for "fund the migration."

How to Pitch It (Stakeholders)

To executives: We run a retired CMS. Upstream is archived, the last release was in 2020, the license terms are non-standard, and the stack caps us at older PHP. Every quarter we stay is unpatched risk plus rising contractor cost for a shrinking skills pool. The proposal is not "adopt this package" — it's "fund the migration." Evaluating the package gives us the baseline numbers: migration scope, content model, integration surface. Frame it as technical-debt retirement, not a new dependency.

To engineering: Treat this as read-only reference. Use it to understand legacy extension behavior, content mapping, and semantics the new platform must preserve — then migrate off. Do not introduce it into a new service. For the interim deployment: pin the PHP version, isolate behind a WAF/reverse proxy, and track CVEs manually since no upstream patches are coming. Have legal confirm the NOASSERTION license before any code is copied into the successor platform.