Legacy Wrapper Bundle Laravel Package

Product Decisions This Supports

• Legacy modernization strategy: choosing between a big-bang rewrite and an incremental "strangler fig" migration of a PHP monolith. This bundle is the canonical artifact of the incremental approach — it lets a legacy app keep serving traffic while selected routes, controllers, and services are re-implemented inside a modern framework and cut over one slice at a time.
• Build vs. buy for the migration seam: the real deliverable here is a pattern, not code — a request-routing bridge, a shared session/auth contract, and a way to run legacy and modern code in one deploy. That is a decision to build a thin internal adapter (or adopt a maintained alternative) rather than purchase tooling.
• Roadmap sequencing and risk allocation: enables parallel workstreams — teams can ship new features in the modern stack while the legacy core is gradually drained, instead of freezing the roadmap for a multi-quarter rewrite. Useful input when scoping "how much of the roadmap can proceed during migration."
• De-risking cutover: supports phased, reversible releases (route-by-route switchover, feature-flagged coexistence) which materially lowers the blast radius versus a single launch event — a direct input to release governance and rollback planning.
• Reference architecture for engineering spikes: valuable as a design reference during a discovery phase, and as a source of prior art on session bridging, DI container coexistence, and URL routing handoff.
• Explicitly not supported: adoption as a production dependency. With ~40 stars, zero dependents, no release since April 2018, and a Symfony 2/3-era codebase, it does not meet any reasonable maintenance or security bar. It should inform decisions, not ship in the stack.

When to Consider This Package

Consider the approach (and study this bundle's source) when:

• You own a large PHP monolith — Symfony, Zend, CodeIgniter, or hand-rolled — where a full rewrite is politically or financially unviable, and the business needs continuous delivery during migration.
• You need a coexistence layer: reverse-proxy or front-controller routing, shared session/cookie handling, shared service container access, and a clear boundary so new code never reaches back into legacy classes except through an anti-corruption layer.
• You want a proven-in-concept template for how a smaller framework (Laravel or a newer Symfony version) can front-load a legacy request and delegate unresolved routes.
• You are producing a migration RFC and want concrete prior art for route delegation, autoloading coexistence, and DI bridging.

Look elsewhere — or build a small internal adapter — when:

• You are on Laravel. This is a Symfony bundle. Concepts port; the code does not. Budget for a bespoke Laravel bridge rather than a retrofit.
• You need maintained, supported code. No release since 2018, effectively zero downstream usage, minimal community, and no compatibility guarantee for PHP 8.x or current Symfony. No security response, no CVE path.
• Your target stack is different. There are actively maintained alternatives for the same job — an HTTP reverse proxy / ingress rewrite, a Laravel/Symfony route fallback handler, or the classic strangler facade pattern implemented in-house (typically a few hundred lines).
• The legacy app is small. Below roughly a mid-six-figure line count, a staged rewrite or module extraction is cheaper than maintaining a coexistence seam.
• You need vendor accountability. No commercial support, no SLA, no license review trail for a dependency you would have to justify to security and legal.

Adoption verdict: reference-only, not a dependency. Score of ~1.66 with zero dependents and an eight-year-old last release makes this an artifact for pattern mining.

How to Pitch It (Stakeholders)

To executives (one paragraph): We are evaluating how to modernize our legacy PHP platform without freezing the product roadmap. This library is an early, now unmaintained implementation of the "incremental migration" technique — run old and new code side by side and move features across one at a time. I do not recommend adopting it as a dependency: it has almost no users, no release since 2018, and no support path. I do recommend using it as the architectural reference for a small in-house migration layer of our own, which keeps our migration risk phased and reversible while the roadmap continues.

To engineering leadership: Treat it as prior art, not a package. The techniques worth borrowing are route delegation from a modern front controller to the legacy app, a shared session/auth contract, and DI container coexistence behind an anti-corruption boundary. We should expect to write and own this layer ourselves — in the range of a few hundred to low thousands of lines depending on session complexity — and we should gate on it being invisible to product teams and fully reversible per route.

To the engineering team building it: Do not composer require this. Read the routing and session-bridging code, then implement against our current framework version with tests, an explicit contract for what the seam is allowed to touch, and a deprecation path for every legacy route migrated. Measure success as the fraction of traffic still served by legacy, trending down per quarter, with zero regression in release cadence.