Symfony upgrades to a supported LTS on PHP 8.5

Why upgrade Symfony now

Symfony releases a long-term support (LTS) version every two years, and each LTS gets security fixes for four years. Applications on Symfony 3 or 4, or on a non-LTS release, are running without framework security fixes. They are often stuck on an old PHP version too: Symfony 8 requires PHP 8.4, so the framework and the runtime have to move together.

The deprecation-driven upgrade

Symfony is designed to be upgraded, so long as you follow its rules. Every feature removed in a major version is deprecated first, in the last minor version before it. We use that:

1. Tests and a baseline. Functional tests on the critical routes and commands, plus a PHPStan baseline with the Symfony extension, before any change.
2. Upgrade to the last minor of your current major, for example 4.4, 5.4 or 6.4.
3. Clear every deprecation. The PHPUnit bridge and the deprecation log list everything that will break in the next major. Rector’s Symfony rules fix much of it automatically.
4. Jump the major version. With no deprecations left, the jump is mostly a composer.json change. Then repeat.
5. Upgrade PHP alongside, finishing on a supported Symfony LTS running on PHP 8.5.

Each step is merged as it’s finished, so your team keeps working on the same codebase.

What usually takes the time

• Symfony Flex migration for applications still on the pre-Flex directory structure from Symfony 3.
• Annotations to attributes for routing, validation and Doctrine mapping.
• Doctrine ORM and DBAL major versions, which have their own breaking changes.
• Third-party bundles that never got past an old Symfony version and need replacing.
• Security component changes: the authenticator system replaced guards and the old firewall setup.

Cost

Every Symfony upgrade starts with the fixed-price £350 audit: dependency and bundle compatibility, a deprecation count, a Rector dry run and a written plan for each version step. The upgrade is then a fixed quote.