Symfony 8 and the 8.2 Release: What Changes From 7.4 and When to Move

A Symfony 8 upgrade looks straightforward until the support dates come into view. Symfony 7.4 LTS and Symfony 8.0 shipped on the same day, November 27, 2025, with identical features; 8.0 simply removed everything 7.x had deprecated and raised the PHP floor to 8.4. Symfony 8.0 already lost support on July 29, 2026. The current stable release is 8.1, supported until January 2027, and 8.2 is due this month, November 2026, on the same eight-month support cycle. Most business applications are better served staying on 7.4 LTS, which runs on PHP 8.2 and keeps getting security fixes until November 2029. The 8.x train only makes sense for a team ready to upgrade roughly every six months, indefinitely.

Two releases, one day, two different jobs

On November 27, 2025, Symfony published both 7.4 and 8.0 with the same feature set. 7.4 is the long-term support release of the 7.x branch: bug fixes until November 2028, security patches until November 2029, and it still runs on PHP 8.2. 8.0 is the first release of a new major version, and its only real job was to delete everything 7.x had marked deprecated, over 13,000 lines of code by Symfony's own count. Nothing in 8.0 gained new capability on its own; it lost the old escape hatches.

A team that kept its 7.4 codebase deprecation-free can run on either branch with almost no code changes. A team carrying old deprecated code has to fix it either way, on 7.4 or on 8.0, before the upgrade is even possible.

What actually broke moving from 7.4 to 8.0

The PHP floor is the change that stops most projects cold: Symfony 8.0 needs PHP 8.4, dropping support for 8.2 and 8.3. That alone rules out a lot of production servers that have not touched their PHP version recently, and it is worth checking before anything else on this list.

Past that, 8.0 removed ContainerAwareInterface and ContainerAwareTrait, so code still pulling services out of the container at runtime needs constructor injection instead. The fluent PHP configuration format that 7.4 deprecated is gone, and XML stopped being a first-class configuration format; YAML and PHP array configuration are what remain. Internally, Symfony dropped its own LazyGhostTrait and LazyProxyTrait in favor of PHP 8.4's native lazy objects, which mainly matters for a project that built custom proxies on top of those traits. HTTP method override through a query parameter or header now only works for POST; GET and HEAD lost that override entirely.

On the feature side, 8.0 added a built-in multi-step form wizard called FormFlow, automatic registration of #[Route]-attributed controllers so routes.yaml can shrink to a directory pointer, and UUIDv7 as the default UUID version, which produces time-ordered identifiers instead of fully random ones. ObjectMapper and JsonStreamer moved from experimental to stable. None of this required a rewrite; it sits on top of what 7.4 already had.

Our Symfony 7 upgrade guide covers the 6.4-to-7.4 deprecation cleanup that both 7.4 and 8.0 share, which is the harder part of either upgrade path.

Why Symfony 8.0 is already a dead end

Symfony 8.0 stopped receiving any fixes on July 29, 2026, with version 8.0.16 as the last release: eight months of support, start to finish. A team that moved to 8.0 in early 2026 and has not upgraded since is running an unsupported framework version right now, in November 2026, with no security patches coming if something is found.

That is how the 8.x line works, not a one-off gap. Each 8.x minor gets about eight months of support before the next one takes over, and a new minor ships roughly every six months. Symfony 8.1 shipped May 29, 2026, with no breaking changes from 8.0, and it is supported until January 2027. Staying current on the 8.x track means budgeting an upgrade roughly twice a year, for as long as the project uses that track.

What 8.1 added, and what is coming in 8.2

8.1 is the current stable release, and because it carries no breaking changes from 8.0, moving from 8.0 to 8.1 should be a Composer version bump and a full test run, nothing more. The main additions are an HTTP-less kernel option, where AbstractKernel and KernelTrait moved into the DependencyInjection component so a CLI or worker application can skip the HTTP layer entirely, a #[RateLimit] attribute that applies limits declared in framework.rate_limiter directly on a controller action, and a --fetch-size option on messenger:consume that lets a worker pull several queue messages per round trip instead of one at a time.

Symfony 8.2 is still under development as of this writing, due this month, and will be supported until July 2027, following the same eight-month pattern as 8.0 and 8.1. The preview posts on Symfony's blog point to several concrete additions still in progress: polymorphic form collections, where a single collection field can mix different form types and match entries by identity instead of position; an interop serializer for Messenger that lets a Symfony application exchange messages with non-PHP applications; an inbox feature for Messenger that skips a message it already processed even if the worker crashed before acknowledging it; broader support for security expressions, including a current_user() function usable in more places; and stricter, generics-aware type handling in the Serializer component. None of this is final until the actual release, so treat it as a preview rather than a changelog.

7.4 LTS or the 8.x train: the real Symfony 8 upgrade decision

This is the actual decision, and it comes down to how often the team wants to upgrade. The 8.x train gets new features roughly every six months but demands an upgrade on nearly the same schedule to stay supported, and it needs PHP 8.4 today, which rules it out for any server still on an older PHP version. 7.4 LTS has none of 8.0's new features, since it is deliberately the same codebase minus the removal, but it runs on PHP 8.2 or higher and keeps getting security fixes until November 2029, nearly three years from now.

For most of the client applications we work on, that makes 7.4 LTS the right default: a long, predictable support window without a recurring upgrade cycle every six months. The 8.x line fits a team that wants the newest Symfony features as they ship and has the test coverage to keep pace with the release cadence. Our overview of Symfony LTS versions goes into how that trade-off plays out across different project types and support horizons.

The practical path, either way

Start with the PHP version running on the actual server before beginning a Symfony 8 upgrade or committing to 7.4 LTS. Symfony 8.x needs PHP 8.4; 7.4 LTS needs 8.2 at minimum, though PHP 8.2 is already past active support upstream, so PHP 8.4 is worth targeting regardless of which Symfony track gets picked. If the codebase is still on Symfony 6.4, run it with deprecation warnings enabled and fix every one before touching the version constraint; the deprecations in 6.4 are exactly the breaks that 8.0 made permanent. Once the code is deprecation-free, changing the Composer constraint to either 7.4 or 8.1 is a small, mostly mechanical step.

A project doing more with PHP 8.4's language features directly, rather than through Symfony, is also worth looking at from that angle. Our piece on property hooks and entity design covers one of the clearer practical wins PHP 8.4 brings, regardless of which Symfony version sits on top of it.

Run the full test suite before and after switching the constraint, not just a smoke test. Composer will resolve to a new major version without complaint; it will not tell you that a bundle your project depends on has not published a compatible release yet, which is still the most common thing that stalls one of these upgrades in practice.

If you are deciding between tracks, or need an outside read on what a specific codebase actually requires before committing to one, Wolf-Tech helps teams make that call and carries out the migration itself. Our tech stack strategy service covers exactly this kind of framework-version decision. Reach out at hello@wolf-tech.io, or see more at wolf-tech.io, and we will look at the codebase in front of us rather than the general case.