Legacy Wrapper Bundle Laravel Package

Product Decisions This Supports

• Replatform strategy: incremental "wrap and carve" over big-bang rewrite. This package is a prior-art artifact for the strangler-fig migration pattern — running a legacy PHP app behind the same domain and session as a modern app so new features can ship on the new stack before the old one is retired. The decision it informs is roadmap shape (parallel-run vs. freeze-and-rewrite), not a feature choice.
• Sequencing: can the new stack ship before auth migrates? The bundle's core capability — bridging request/response and session between two runtimes — is the technical precondition for "new surface area now, full identity migration later." That unlocks a quarter or more of parallel delivery that a big-bang plan would spend in a feature freeze.
• Scope of a coexistence window. The pattern only pays off if the dual-run is bounded (months) and both codebases are under your control. It is a de-risking lever for a planned transition, not an architecture for a permanent split.
• Integration/M&A product consolidation. Two acquired PHP apps, one session, one login: the same seam pattern applies when merging products onto a shared identity layer before the eventual data merge.
• Scope correction that materially changes the decision: despite being catalogued as a Laravel/PHP package, this is a Symfony bundle (TheodoEvolutionLegacyWrapperBundle, Symfony 1.x→2.x era). If your stack is Laravel, it does not support your build decisions — it only informs them as a readable design reference. Its in-process dispatch model has no Laravel analogue (no bundle system, no HttpKernel sub-request contract).
• What it does not decide: it is not a vendor selection, not a buy signal, and not a supported component. Stars 0, dependents 0, score 0, unmaintained, sitting directly on the session/auth path.

When to Consider This Package

Treat it as reference reading when all of the following hold:

• You are planning a legacy PHP → modern-framework migration and need evidence that incremental cutover is technically viable.
• You need a concrete checklist for the seam: route fallback for unowned paths, request/response translation, shared session propagation, and cookie/domain reconciliation.
• An engineer has a few days to read it and extract the pattern — you are not installing it.
• The coexistence window is bounded and both apps are yours.

Look elsewhere — or do not adopt at all — when:

• Any production dependency is contemplated. Zero adoption, no security-response process, no maintenance guarantee, and it touches sessions. That is an unacceptable risk profile on an auth path, and in a regulated or long-lived environment it is a compliance finding waiting to happen.
• Your stack is Laravel. Wrong framework; the concept transfers, the code does not.
• You are on Symfony 5/6/7 or PHP 8.1+. The codebase is almost certainly PHP 5.3–5.6 idioms and symfony/symfony ~2.x constraints. It will not install; any port is a rewrite of the dispatch layer, not an upgrade.
• A simpler, supported alternative solves the same problem. A reverse proxy (Nginx/Envoy) routing unmatched paths to the legacy vhost, plus a shared session store, signed interop token, or SSO/OIDC, delivers roughly 90% of the bundle's intent with vendor backing, independent scaling, and a clean rollback lever. This should be the default option on the table.
• In-process wrapping is a preference rather than a hard infrastructure constraint. It forces the legacy app to share the modern app's PHP-FPM pool, deploy cadence, and memory ceiling; it multiplies blast radius (legacy fatals, output-buffer leaks, duplicate Set-Cookie headers surfacing inside the modern request lifecycle) and provides no observability hooks.

PM recommendation: adopt the pattern, reject the package. Fund a proxy-based seam in sprint one, then carve out route families. Budget days, not weeks, for the seam itself — and spend the saved effort on the security review and instrumentation the package cannot provide.

How to Pitch It (Stakeholders)

For executives: This is not a purchase — it is a migration-strategy decision. The package is a small, unmaintained, zero-adoption Symfony component that demonstrates how to keep users logged in while we rebuild a legacy application piece by piece. Its value is proof that incremental migration is technically viable, which lets us avoid a risky big-bang rewrite and ship customer-facing features quarters sooner instead of freezing the roadmap. We should not take a dependency on it; we borrow the architecture and implement it ourselves — a reverse proxy plus a supported identity/session mechanism — for negligible cost. Risk avoided: an unsupported third-party component sitting on our authentication path, and a maintenance liability with no upstream to patch it.

For engineering: It is a Symfony bundle that bridges legacy PHP session/auth into a modern Symfony kernel by dispatching sub-requests into the legacy front controller. Zero stars, zero dependents, no issue history — treat it as a design reference only. Read it for the route-fallback discipline and the session-bridging checklist, then implement the seam at the proxy layer: unmatched paths go to the legacy vhost, Laravel/Symfony owns new routes, session coherence comes from a signed interop token rather than a shared session store. That gives us one domain, independent deploys and scaling per tier, and a single rollback lever. Only escalate to a middleware proxy — and only then to owning a fork — if the proxy is genuinely blocked by an infrastructure constraint we cannot negotiate. Either way, instrument both sides of the seam with correlation IDs and per-route-family error rates before go-live, so on-call debugs from data and not folklore.