Symfony 6.4 end of bug fixes in November 2026: which version to upgrade to

Symfony 6.4 stops receiving bug fixes after November 2026; only security vulnerabilities will still be fixed, until November 2027. This guide gives the official dates, what the end of bug fixes changes, the version to upgrade to, the matching PHP version and the upgrade method.

It is written for technical leaders, CIOs and owners of PHP applications built on Symfony 6.4. Upgrading web applications is part of our web development and application maintenance offers.

When does Symfony 6.4 support end?

Symfony 6.4 support ends in two stages: bug fixes end in November 2026, security fixes in November 2027. Symfony publishes these deadlines to the month, without a specific day.

Symfony 6.4 was released in November 2023. It is a long-term support (LTS) version, like the last minor version of every branch (5.4, 6.4, 7.4): according to Symfony’s release process, an LTS receives bug fixes for three years and security fixes for four years. The other versions, called standard, are only maintained for eight months. Symfony 6.4 requires at least PHP 8.1; its latest release to date is 6.4.50.

The standard versions Symfony 7.3 and 8.0 are already unmaintained: an application left on either of them no longer receives any fix.

What does the end of bug fixes in November 2026 change?

After November 2026, a Symfony 6.4 application runs exactly as before, but patch releases of the 6.4 branch only contain security fixes. A bug found afterwards in a Symfony 6.4 component stays in the framework: the application has to work around it.

• Bugs. A framework defect reported after November 2026 is only fixed in maintained versions, 7.4 and 8.x.
• Security, one more year. Vulnerabilities are still fixed until November 2027. After that date, no more 6.4 release comes out, and a vulnerability found later stays open.
• PHP. A Symfony 6.4 application often runs on PHP 8.1 or 8.2. PHP 8.1 has been unsupported since 31 December 2025, and PHP 8.2 only receives security fixes, until 31 December 2026.
• Dependencies. Bundles and libraries follow the maintained Symfony versions: an application left on 6.4 gradually gets stuck on old versions of its dependencies.

The security-only year is room to plan, not a reason to wait: an upgrade started late in 2027 is done under deadline pressure. Once maintenance ends, Symfony points to professional support from SensioLabs, the company behind the framework; that support buys time, the upgrade still has to be done. The approach is the same as for a language reaching end of life, described in our article on the end of support for PHP 8.2.

Symfony 7.4 or Symfony 8: which version to upgrade to?

To leave Symfony 6.4, the preferred target is Symfony 7.4: it is the current LTS, released in November 2025, with bug fixes until November 2028 and security fixes until November 2029.

• Symfony 7.4, the default choice. Three years of fixes ahead, PHP 8.2 at minimum, and the shortest path from 6.4: a single major version to cross.
• Symfony 8, for teams that follow every release. Symfony 8.1 is the current stable version, but it is a standard version: maintained until January 2027, then replaced by 8.2, and so on every six months. It requires PHP 8.4 and means going through 7.4 first.
• Wait for the next LTS? At the pace Symfony publishes, one minor version in May and one in November, the next LTS, Symfony 8.4, is expected in November 2027: exactly when Symfony 6.4 loses its security fixes. Waiting for it means upgrading with no margin.

Which PHP version to choose with Symfony 7.4?

With Symfony 7.4, aim for PHP 8.4 or PHP 8.5. Symfony 7.4 accepts PHP 8.2, but PHP 8.2 only receives security fixes and ends on 31 December 2026: upgrading the framework without changing PHP would leave the application on an unsupported language a few weeks later.

PHP 8.4 is also Symfony 8’s minimum version: choosing it now closes no door. Changing the PHP version is prepared like the framework upgrade and shipped separately; our article on the end of support for PHP 8.2 details the steps.

How do you upgrade from Symfony 6.4 to Symfony 7.4?

Symfony’s official method comes down to one rule: an application with no deprecation left on 6.4 runs on Symfony 7, because Symfony 7.0 contains the same features as 6.4, minus the deprecated ones. The steps, in order:

• Take stock. Exact Symfony and PHP versions, bundles and libraries and their compatibility with Symfony 7, test coverage, deployment chain. An audit of the existing setup answers these questions.
• Remove deprecations on 6.4. In development, the debug toolbar and the profiler list deprecated calls. With the PHPUnit Bridge (composer require --dev symfony/phpunit-bridge), tests show the number of remaining deprecations, to bring down to zero. Rector, a third-party tool cited by Symfony’s documentation, automates part of the rewriting.
• Upgrade PHP, to 8.4 or 8.5, and ship it separately, on the Symfony 6.4 still in place.
• Change version. In composer.json, move the symfony/* constraints from 6.4.* to 7.4.* (symfony/polyfill-*, symfony/ux-* and bundles with their own numbering do not change), run composer update "symfony/*", then clear the cache by deleting the contents of var/cache.
• Update recipes. composer recipes:update aligns the configuration files installed by Symfony Flex; conflicts are resolved like Git conflicts.
• Read the UPGRADE-7.0 guide. This file in the Symfony repository lists the breaking changes, including changed defaults (see the next section).
• Test and ship. Critical user journeys, forms, authentication, background jobs. A test campaign prepared before the upgrade serves as the reference, and the production release comes with a rollback ready.

Targeting 7.4 directly rather than 7.0 is possible: Symfony’s backward compatibility promise lets you move from one minor version to the next without breaks, and the deprecations added between 7.1 and 7.4 stop nothing from working; they prepare Symfony 8.

What changes between Symfony 6.4 and Symfony 7?

Between Symfony 6.4 and Symfony 7, most changes are announced by deprecations as early as 6.4: an application with none left is ready. The points that take the most work, according to Symfony’s UPGRADE-7.0 guide:

• Annotations give way to PHP attributes. Doctrine annotations are no longer read for routes, validation and serialization: @Route becomes #[Route], and so on.
• Commands and message handlers. Command::$defaultName is removed in favour of the #[AsCommand] attribute, MessageHandlerInterface in favour of #[AsMessageHandler].
• Dependency injection. ContainerAwareInterface and ContainerAwareTrait are removed: a service is received by injection, no longer fetched from the container.
• Removed components. The Templating component is removed in favour of Twig; Twig 2 and Monolog below version 3 are no longer supported.
• Security. The enable_authenticator_manager option disappears, and enabling SecurityBundle without configuring at least one firewall is no longer allowed.
• Changed defaults. http_method_override becomes false, the session cookie becomes secure “auto” and SameSite “lax”, generated UUIDs move to version 7, e-mail validation moves to html5 mode. These changes must be checked one by one on the application.
• Stricter types. Symfony 7 adds native return types: application classes that extend framework classes must declare them. ParameterBag::getInt() and getBool() now throw instead of returning 0 or false.

An application that has fallen behind on its versions often hides other delays, in the code as in the infrastructure: it is part of technical debt, and catching up is a matter of evolutive maintenance.

Frequently asked questions

Symfony 6.4: set the upgrade date now

November 2026 breaks nothing, but it opens Symfony 6.4’s last year, and that year only covers security. The decision comes down to three points: the target version (Symfony 7.4, with PHP 8.4 or 8.5), the order of the releases (deprecations, PHP, framework), and a date for each, set after the dependency inventory.

The iones team upgrades Symfony applications, from the inventory to production, as part of its web development offer, and keeps them up to date over time with application maintenance. To review your applications, write to us.