Legacy Wrapper Bundle Laravel Package

Technical Evaluation

Architecture fit — a reference implementation, not a build dependency. The cataloguing as a "Laravel/PHP package" is inaccurate: skigun/legacy-wrapper-bundle is a Symfony bundle (TheodoEvolutionLegacyWrapperBundle), a Symfony 2-era artifact of Theodo's Evolution toolkit for wrapping legacy PHP entry points inside a modern Symfony kernel. Its mechanism is in-process sub-request dispatch: the modern app intercepts routes it does not own, bootstraps the legacy front controller, and bridges request/response and session state. That model has no first-class analogue in Laravel — no bundle system, no HttpKernel sub-request contract, no framework-blessed legacy bridge. For a TPM, the correct framing is: the package is evidence that incremental migration is viable, and a checklist for where the seams are. It is not an installable component for a Laravel roadmap.

Integration feasibility — poor as a dependency, good as prior art. Ranked options for a Laravel shop:

1. Reverse-proxy strangler fig (recommended). Nginx/Envoy/ALB routes unmatched paths to the legacy vhost; Laravel owns new routes. Single domain, correct cookies, independent deploy and scaling, clean rollback at the proxy. This delivers the large majority of the bundle's stated intent with none of its coupling.
2. Laravel middleware catch-all proxying outbound via Guzzle, rewriting headers and cookies. Achieves the single-entry-point goal at the cost of an extra hop and careful streaming/header handling.
3. Fork and port the bridging logic into a Laravel package. Justified only under a hard infrastructure constraint (a single ingress you cannot change) plus an explicit decision to own a fork indefinitely.

Technical risk — high, concentrated on the auth/session path. Zero stars, zero dependents, no visible production users, and a vintage that implies PHP 5.3–5.6 idioms and symfony/symfony ~2.x constraints. It will not install alongside Laravel 10/11 on PHP 8.1+. Beyond the install problem: no upstream to absorb PHP 8 deprecations or security patches; in-process dispatch multiplies blast radius by pulling legacy fatals, output-buffer leaks, and header collisions into the modern request lifecycle; and there are no observability hooks tying into Laravel's logging, tracing, or exception handler. The 35.17 opportunity score is consistent with "read it, don't ship it."

Key questions a TPM must get answered before funding engineering:

• What is the legacy stack and PHP version, and what deadline is forcing the migration now?
• Is a second vhost or ingress route genuinely infeasible, or is in-process wrapping a preference?
• Do the two apps need true shared session/identity, or just a shared cookie domain plus a signed token?
• Who owns each table during dual-run, and is there a dual-write or backfill plan?
• What inconsistency window (logout loops, 403s) is tolerable for users mid-migration?
• Is there a named owner and a funded quarter count for a fork if we go that route?
• Has security signed off on any library sitting on the session path with no maintenance guarantee?

Integration Approach

Stack fit — mismatch by default, so plan a re-implementation. Laravel cannot consume this bundle unmodified. The realistic mapping:

• Routing: Route::fallback() (or an ordered catch-all with explicit exclusions) is the direct equivalent of the bundle's "unmatched route → dispatch legacy" behavior. This is the one concept that ports cleanly and cheaply, and it is worth writing down as team convention.
• Session/identity bridge: reconcile Laravel's session driver and cookie config with the legacy app's PHPSESSID-style session. Options are a shared session store (Redis with a common serializer — fragile across framework versions), a signed interop token, or forced re-auth at the boundary. Prefer the signed token; it gives one authoritative issuer and a clean revocation story.
• Assets and URLs: legacy-generated absolute links and asset paths will need rewriting. The bundle does some of this; at the proxy or in a small middleware it is far more transparent and debuggable.

Migration path — phased strangler fig, proxy seam first:

1. Inventory legacy routes by traffic and business criticality; tag each keep / rewrite / retire. This inventory is the roadmap artifact, not the code.
2. Stand up the seam at the proxy in sprint 1. One domain, both apps answering, cookies and assets verified. Low cost, fully reversible, de-risks everything downstream.
3. Carve out low-risk, high-churn routes into Laravel — auth surfaces, dashboards, read-only views — to prove the identity bridge under real traffic before it owns anything revenue-critical.
4. Define the data boundary. One writer per table, stated explicitly in writing. Two writers on one table is the most common way strangler migrations fail.
5. Cut over by route families, never individual endpoints, so each release is a coherent user-facing slice.
6. Traffic-shadow, then decommission. Retire the legacy app only after a full shadow period with matching error rates.

Compatibility caveats to budget for:

• PHP 8 strictness will surface legacy null-coercion as TypeError 500s the moment those code paths go live.
• Symfony 2's sub-request contract has no Laravel equivalent; any port is a dispatch-layer rewrite, not a translation.
• Legacy apps lean on register_shutdown_function, set_error_handler, and global state that conflict with Laravel's bootstrap. In-process wrapping amplifies this; the proxy approach eliminates it entirely.

Sequencing recommendation: proxy seam in sprint 1, identity bridge in sprint 2, first route-family carve-out in the following sprint. Escalate to middleware-proxying — and only then to a fork — solely if the proxy is blocked by an infrastructure constraint you cannot negotiate. Publish the route inventory as the roadmap so stakeholders see the carve-out order, not just the intent.

Operational Impact

Maintenance — the dominant, under-estimated cost. Taking this package means owning a fork: PHP 8 compatibility, Symfony API drift, security patching, CI, and release management, with no upstream to merge from and no obligation from the original author to respond to anything. A fork on the auth path is a multi-quarter liability. The proxy approach carries effectively zero package maintenance and shifts effort into configuration you already know how to run.

Support — no safety net. No community, no issue history to mine, no documented production users. Institutional knowledge will live entirely with whoever builds the seam. Require a written runbook, at least two engineers trained on it, and a stated fallback ("flip the proxy back") before go-live. This is a governance ask, not a nice-to-have.

Scaling — the legacy app is the constraint, and in-process wrapping couples you to it. Wrapping in-process forces legacy to scale on the modern app's cadence: same PHP-FPM pool, same memory ceiling, same deploy window. Legacy apps are typically stateful (local sessions, filesystem caches), which forces sticky sessions and blocks independent horizontal scaling. The proxy approach lets each tier scale on its own curve — a concrete, quantifiable operational win that belongs in the business case.

Failure modes to design for and instrument:

• Session divergence — authenticated in one app, anonymous in the other; presents as intermittent 403s and logout loops. Mitigate with a single authoritative token issuer.
• Cookie/domain collisions — duplicate Set-Cookie headers, path-scoping conflicts; breaks auth silently. Assert on header shape in staging.
• Header and output-buffer leakage — legacy echo before headers, stray whitespace, or a legacy error page rendered inside a Laravel response. In-process wrapping makes this the default, not the exception.
• Error attribution blindness — a legacy fatal surfaces as a generic 500 from the modern app and on-call debugs the wrong codebase. Mandate distinct error signatures and correlation IDs across the seam.
• Asset 404 storms after any URL-rewrite change; crawl before every cutover.
• Rollback ambiguity — mid-migration rollback may require reverting routing and session state. Keep the proxy as the single rollback lever so the answer is always one toggle.

Ramp-up — moderate, and routinely under-scoped. The conceptual model (route fallback, shared session, dual-run) is learnable in days. The real cost is the legacy application's undocumented behavior — expect 2–4 weeks before an engineer can confidently diagnose a cross-boundary failure. Fund onboarding explicitly, and pair it with instrumentation on both sides: request correlation, latency and error rate by route family. Teams that skip this debug from folklore and stall the migration.

Bottom line for a TPM: leverage this package as prior art and a seam checklist, not as a dependency. Fund a proxy-based seam plus a route-by-route carve-out plan, name an owner for the identity bridge, and secure a security sign-off on whichever token or session mechanism you choose. The engineering you avoid by not owning an unmaintained fork on the authentication path will comfortably exceed anything its in-process dispatch would have bought you.