For over a decade, Zend Framework was the backbone of our PHP development. It was enterprise-grade, well-documented, and familiar. When Zend Framework reached end of life and transitioned to the Laminas project, we faced a decision that many PHP shops have encountered: migrate to Laminas, switch to Laravel, or explore something else entirely. After careful evaluation, we chose Laravel, and the migration taught us as much about managing change as it did about PHP frameworks.
The decision was driven by three factors. First, Laravel's ecosystem is significantly larger than Laminas. Packages for authentication, queues, caching, file storage, and API development are maintained by a well-funded team and a massive community. Second, developer recruitment became easier. Laravel is the framework most PHP developers want to work with, and that matters for a consultancy that needs to scale teams quickly. Third, Laravel's opinionated approach to application structure reduces the architectural decisions that each project team needs to make, leading to more consistent codebases across our portfolio.
A framework migration is not a rewrite. It is a disciplined, incremental replacement that maintains production service throughout.
We did not rewrite our applications from scratch. Instead, we adopted a strangler fig pattern, routing new features through Laravel while maintaining existing Zend functionality. Both frameworks ran side by side, sharing the same database and session store. Over a period of six months, we migrated each module individually: authentication first, then API endpoints, then background jobs, and finally the remaining controller logic.
The Incremental Migration Path
The most challenging aspect was the service layer. Our Zend applications used a heavily customised dependency injection container with service factories that had no direct equivalent in Laravel. We wrote adapter classes that allowed Laravel's service container to resolve our existing service definitions, then gradually replaced each service with native Laravel implementations. This approach prevented a big-bang migration that would have introduced risk across the entire application.
The results were measurable. Development velocity for new features increased by approximately 30%, primarily because Laravel's Eloquent ORM and built-in tooling eliminated boilerplate that we previously wrote manually. Our test suite execution time dropped by 40% thanks to Laravel's in-memory SQLite testing support. And our recruitment pipeline improved immediately when we started advertising Laravel positions rather than Zend Framework ones.
- Use the strangler fig pattern to migrate incrementally rather than rewriting
- Run both frameworks in parallel during the transition period
- Migrate authentication and session handling first to establish the foundation
- Write adapter classes for service layer compatibility during migration
- Measure velocity improvements to justify continued migration investment
The lesson we would share with any team facing a similar migration: do not wait for the old framework to become unmaintainable. Plan the migration while the existing system is stable, so you can move incrementally rather than under pressure.
