Legacy Bridge Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Legacy System Integration: The bundle is specifically designed to bridge non-frontcontroller legacy PHP applications into a Symfony/Laravel ecosystem, making it a strong fit for projects with:
  • Spaghetti-style PHP scripts (e.g., procedural code, no MVC structure).
  • Monolithic applications where incremental modernization is desired.
  • Mixed tech stacks where Symfony/Laravel is the new core, but legacy code must coexist temporarily.
• Symfony-First Design: While Laravel is PHP-based, this bundle is Symfony-centric (uses Symfony’s DI container, routing, and frontcontroller). Laravel’s service container and routing are conceptually similar, but direct compatibility is untested (see Technical Risk).
• Incremental Modernization: The bundle enables gradual refactoring by exposing Symfony’s container to legacy code ($_SERVER['SYMFONY_CONTAINER']), allowing legacy scripts to consume Symfony services (e.g., Doctrine, HTTP clients) without full rewrite.

Integration Feasibility

• Laravel Compatibility:
  • Pros:
    • Laravel’s service container ($app) can be exposed similarly to Symfony’s container (via $_SERVER or middleware).
    • Routing: Laravel’s router can dynamically generate routes for legacy files (though the bundle’s auto-routing logic would need adaptation).
    • Middleware: Legacy requests can be wrapped in Laravel middleware (e.g., auth, CORS) before hitting old scripts.
  • Cons:
    • No native Laravel support: The bundle assumes Symfony’s Kernel, Request, and EventDispatcher. Laravel’s equivalents (Illuminate\Foundation\Application, Illuminate\Http\Request) would require custom glue code.
    • Event system: Symfony’s event system (e.g., KernelEvents) won’t map 1:1 to Laravel’s events.
• Legacy Code Constraints:
  • Assumes legacy scripts are stateless or can tolerate Symfony/Laravel’s request lifecycle (e.g., no reliance on $_REQUEST being populated before legacy code runs).
  • Output buffering: Legacy scripts may break if they assume direct output (e.g., echo without headers). Laravel’s response system would need to handle this.

Technical Risk

Key Questions for TPM

1. Legacy Code Assessment:
   • What percentage of legacy scripts are stateless? Can they tolerate Laravel’s request lifecycle?
   • Are there hard dependencies on global state (e.g., $_SESSION, register_globals)?
   • Do legacy scripts output raw HTML or rely on direct echo (may need response buffering).
2. Modernization Goals:
   • Is this a temporary bridge (1–2 years) or a long-term hybrid?
   • Are we extracting services from legacy code (e.g., moving business logic to Laravel)?
3. Laravel-Specific Constraints:
   • How will we handle Symfony’s EventDispatcher in Laravel? (Laravel uses events too, but differently.)
   • Can we replace the bundle’s auto-routing with Laravel’s Route::get() for finer control?
4. Team Skills:
   • Does the team have experience shimming frameworks (e.g., making Symfony classes work in Laravel)?
   • Is there bandwidth to maintain custom glue code if the bundle breaks?

Integration Approach

Stack Fit

• Laravel Compatibility Matrix:

  Laravel Component	Bundle Equivalent	Feasibility	Workaround
  Service Container	Symfony’s DI Container	Medium (shim $app to $_SERVER)	Custom middleware to expose $app globally.
  Router	Symfony’s Router	Low (Laravel’s router is different)	Replace auto-routing with manual Route::get().
  Kernel/Events	Symfony KernelEvents	Low	Use Laravel events or middleware hooks.
  Request Handling	Symfony Request	Medium	Convert Symfony Request to Laravel Request.
  Response Handling	Symfony Response	Medium	Buffer legacy output into Laravel Response.

• Recommended Stack:

  • Laravel 8+ (for service container stability and middleware flexibility).
  • Symfony Components (only where absolutely necessary; e.g., HttpFoundation for request/response).
  • Custom Middleware to:
    • Expose Laravel’s container to legacy scripts (via $_SERVER or a global helper).
    • Wrap legacy requests in Laravel middleware (auth, CSRF).
    • Buffer legacy output into Laravel’s response system.

Migration Path

1. Phase 1: Proof of Concept (2–4 weeks)

   • Goal: Verify 1–2 critical legacy scripts work in Laravel.
   • Steps:
     • Create a custom middleware to:
       • Expose Laravel’s container to $_SERVER['LARAVEL_CONTAINER'].
       • Convert Laravel Request to a Symfony-like object (or vice versa).
     • Manually route one legacy file (e.g., /legacy/script.php → script.php).
     • Test output buffering (legacy echo → Laravel Response).
   • Success Criteria: Legacy script renders correctly with Laravel’s middleware (e.g., auth) applied.

2. Phase 2: Auto-Routing Replacement (3–6 weeks)

   • Goal: Replace the bundle’s auto-routing with Laravel’s Route::get().
   • Steps:
     • Scan the legacy directory for .php files.
     • Dynamically register routes in routes/web.php:

       Route::get('/legacy/{script}', function ($script) {
           return app(LegacyBridge::class)->handle($script);
       });
       

     • Implement LegacyBridge service to:
       • Load the legacy file.
       • Inject the Laravel container.
       • Buffer output.
   • Success Criteria: All legacy routes work without conflicts.

3. Phase 3: Incremental Modernization (Ongoing)

   • Goal: Extract services from legacy code into Laravel.
   • Steps:
     • Use $_SERVER['LARAVEL_CONTAINER'] to inject Laravel services (e.g., DB, Cache) into legacy scripts.
     • Gradually replace legacy logic with Laravel controllers/services.
   • Success Criteria: 20–30% of legacy dependencies moved to Laravel per sprint.

Compatibility

• Laravel-Specific Adjustments Needed:
  • Container Injection: Replace Symfony’s $_SERVER['SYMFONY_CONTAINER'] with Laravel’s container (e.g., $_SERVER['LARAVEL_CONTAINER'] = $app).
  • Request/Response: Create adapters between Symfony’s Request/Response and Laravel’s Illuminate\Http\Request/Response.
  • Event System: Use Laravel’s events or middleware hooks instead of Symfony’s KernelEvents.
• Legacy Code Constraints:
  • Avoid:
    • Early exit() or die() in legacy scripts (breaks Laravel’s response cycle).
    • Direct header() calls without checking if headers are sent.
  • Mitigate:
    • Use output buffering (ob_start()) in legacy scripts.
    • Wrap legacy code in a try-catch to handle errors gracefully.

Sequencing

1. Pre-Integration:
   • Audit legacy code for stateful dependencies (e.g., global variables, early output).
   • Set up a staging environment with Laravel + legacy code side-by-side.
2. Integration:
   • Start with non-critical legacy scripts (e.g., static pages, simple forms).
   • Gradually add complex scripts (e.g., those with DB access or sessions).
3. Post-Integration:
   • Monitor performance (auto-routing adds overhead).
   • Plan for deprecation (legacy scripts should be sunsetted as they’re replaced).

Operational Impact

Maintenance

• Custom Code Overhead: