Symfony 7.0

Symfony 7.0 is the major-version step after Symfony 6.4. It raises the minimum PHP version to PHP 8.2 and removes APIs, configuration options, and behaviors that had been deprecated during the Symfony 6 series. The practical effect is that code which only produced deprecation notices on 6.4 can fail after the upgrade, especially custom framework extensions, event listeners, controllers, commands, service definitions, and bundles that depend on removed APIs or no longer-compatible method signatures. It is therefore chiefly a compatibility-cleanup release rather than a reason to redesign an otherwise current Symfony application.

Symfony 7.0 has reached end of life. It no longer receives Symfony-maintained fixes, including security fixes and compatibility corrections. An application can continue to run, but newly discovered defects must be mitigated locally or accepted, and dependency updates may increasingly become constrained by the unsupported framework line and its PHP requirement. Staying also accumulates migration work: deprecated or changed integrations in third-party bundles, test tooling, database libraries, and PHP itself are more likely to surface at the same time as a later framework upgrade. Production systems should treat this as an unsupported-platform risk, not merely a missed feature upgrade.

Do not plan a move to 7.0 as the destination. First inventory the deployed PHP version, Symfony packages, Flex recipes, bundles, and direct uses of deprecated Symfony APIs. Run the application and its test suite with deprecations enabled on the latest compatible Symfony 6.4 patch level, resolve every deprecation that is relevant to the intended target, and update custom subclasses and interfaces for changed type signatures. Then select a currently supported Symfony line that fits the application’s PHP runtime and bundle compatibility, make the upgrade in a separate branch, and validate HTTP flows, console commands, background workers, cache behavior, forms, authentication, messaging, and deployment scripts. Pin the resulting Composer constraints, add automated dependency and security-update review, and remove the end-of-life line from production once the regression suite and rollback plan have been exercised.