6.0 released 29 November 2021, latest 6.0.20.
Symfony 6.0 reached end of life on 31 January 2023.
What changed
Symfony 6.0 is a major compatibility boundary from the 5.x line. It requires PHP 8.0.2 or later and removes APIs that had been deprecated in earlier Symfony releases. Notable migration areas include replacing the legacy Security Guard authentication approach with the authenticator system, moving user implementations from getUsername() to getUserIdentifier(), adopting password hashers in place of deprecated encoder terminology, and replacing Swiftmailer integrations with Symfony Mailer. In general, code that ran with deprecation notices on Symfony 5.4 may fail once those deprecated APIs are removed in 6.0.
What staying costs
Symfony 6.0 has reached end of life, so upstream no longer provides fixes for security vulnerabilities, defects, or compatibility problems in this cycle. Keeping it in production leaves the application dependent on its existing framework behavior and on any local mitigations the team can maintain. The PHP 8 baseline also does not by itself ensure compatibility with newer PHP runtimes, while maintained libraries and bundles may eventually raise their Symfony requirements or stop testing against 6.0. Delaying migration can increase the work later, because application code, internal bundles, Composer dependencies, and deployment runtime constraints may all need to move across multiple unsupported compatibility boundaries at once.
What to do
Treat Symfony 6.0 as an intermediate state rather than a target for new work. First, inventory the application, custom bundles, and third-party packages; update Composer constraints; and verify that the chosen maintained Symfony target supports the intended PHP runtime. Run the test suite with Symfony deprecations enabled and remove uses of APIs deprecated in the 5.x and 6.x lines, especially legacy security authentication, user identifiers, password encoders, and Swiftmailer integrations where applicable. Upgrade in supported major-version steps, resolving Composer conflicts and running automated, integration, and security-authentication tests after each step. Deploy through a staging environment that mirrors production, validate background workers, console commands, caches, sessions, mail delivery, and authentication flows, then retain a tested rollback plan for the application and dependency lockfile.
We can tell you what moving off Symfony 6.0 involves.
What it takes to move off Symfony 6.0 depends on what you built on it — the version you are on, how much depends on it, and how much of the work is mechanical. Leave your email with this version and we can tell you what that looks like for you.
Not sure yet? Get my plan
