Symfony 6.4 end of life: how to upgrade to Symfony 7.4 LTS, with a plan, timeline and real cost

When does Symfony 6.4 reach end of life?

Symfony 6.4 is a long-term support (LTS) release from November 2023. According to the official Symfony releases page, checked on 22 October 2026:

So the clock has two marks. From December 2026, a bug you report in Symfony 6.4 will not be fixed. From December 2027, a security hole will not be fixed either. Symfony 7.4 LTS, released in November 2025, is the version that carries a product to the end of 2029.

We work with Symfony every day: it is our main back-end framework and we have 15+ years of experience with it. The website you are reading runs on Symfony 6.4 as of October 2026, so this guide is also our own plan. If you would rather hand the upgrade to a team, see our Symfony development services.

What does "end of life" mean in practice?

End of life does not switch your application off. It changes who carries the risk.

• Until November 2026 you get bug fixes and security fixes. This is the comfortable window to upgrade.
• From November 2026 to November 2027 you get security fixes only. Regressions and compatibility bugs stay unfixed, so new PHP versions and new library releases start to cause friction.
• After November 2027 nothing is patched. Any vulnerability published in a Symfony component (HTTP kernel, security, forms, serializer) stays open in your app until you upgrade under pressure.

There are side effects that arrive earlier than the official date:

1. PHP is already ahead of you. Symfony 6.4 allows PHP 8.1, which has had no security fixes since the end of 2025. Many 6.4 apps still run on it.
2. Bundles move on. Maintainers of popular bundles drop Symfony 6 support in new major versions, so you cannot take their fixes either.
3. Due diligence notices. Customer security questionnaires, penetration test reports and investors' technical reviews flag unsupported frameworks.
4. The longer you wait, the more you skip. A 6.4 app that waits until 2028 will face 7.4 and 8.x changes at once.

Should you target Symfony 7.4 LTS or Symfony 8?

For most products, 7.4 LTS. It gets three years of bug fixes and four of security fixes, it runs on PHP 8.2 and newer, and it is the version third-party bundles test against first.

Symfony 8.x makes sense when your team upgrades every six months as routine maintenance. Each 8.x minor version is supported for about eight months and needs PHP 8.4. The good news: a codebase that runs on 7.4 without deprecation warnings is a small step from 8.0, because Symfony major versions only remove what the last minor version deprecated. Going to 7.4 now keeps both doors open.

How do you upgrade Symfony 6.4 to 7.4 step by step?

The official approach, which we follow, is "fix deprecations first, then switch". Here is the plan we use on client projects.

1. Audit the codebase and dependencies

Start with facts, not estimates:

• composer outdated and composer why-not symfony/framework-bundle 7.4 show which packages block the upgrade.
• List every third-party bundle and check whether it has a release that supports Symfony 7. Abandoned bundles are the main source of surprises.
• Count deprecations: run the test suite with the PHPUnit bridge, and check bin/console debug:container --deprecations plus the deprecation log in the profiler on key pages.
• Note the PHP version in production, CI and developer machines.

In our own site's composer.json the audit immediately finds two blockers: sensio/framework-extra-bundle and doctrine/annotations. SensioFrameworkExtraBundle is abandoned and does not support Symfony 7, and Symfony 7 no longer reads Doctrine annotations for routing, validation or serialization. Both have to go before the switch. These two are the most common blockers we see in 6.x apps.

2. Move to a supported PHP version

Symfony 7.4 needs PHP 8.2+, but PHP 8.2 security support ends on 31 December 2026 (php.net, checked October 2026). Go to PHP 8.4 if your hosting and extensions allow it; it is supported until the end of 2028. Do the PHP upgrade as its own release, still on Symfony 6.4, so that if something breaks you know which change caused it. Run PHPStan and Rector's PHP sets against the target version before you switch.

3. Remove deprecations on 6.4

This is where most of the work is. Typical items in a 6.4 codebase:

• Annotations to PHP attributes: @Route, @ORM\..., @Assert\..., @Groups. Rector converts most of them automatically.
• SensioFrameworkExtraBundle features to native ones: #[MapEntity] and argument resolvers instead of @ParamConverter, #[IsGranted] instead of @Security, #[Template] from the Twig bridge instead of @Template.
• Return types on overridden methods (voters, normalizers, commands, event subscribers), which become mandatory.
• Removed classes and interfaces such as ContainerAwareInterface and old security configuration keys.
• Your own code calling deprecated APIs found by the deprecation log.

Merge these fixes into the main branch in small pull requests while the product keeps running on 6.4. The goal is zero deprecation notices in tests and on the main user flows.

4. Update or replace bundles

Upgrade each bundle to a version that supports both Symfony 6.4 and 7.x, if one exists. For abandoned bundles, there are three options: a maintained fork, a replacement, or moving the small part you use into your own code. Doctrine ORM 3 and DBAL 4 often come up here; they are independent of Symfony 7.4 and can be done later if the bundles you use still allow ORM 2.x, which reduces risk.

5. Switch the version and update recipes

Change extra.symfony.require and the symfony/* constraints to 7.4.*, run composer update "symfony/*" --with-all-dependencies, then composer recipes:update to review configuration changes one recipe at a time. Read the UPGRADE-7.0.md to UPGRADE-7.4.md files for the components you use. Clear the cache, warm it in the production environment, and fix what breaks.

6. Test properly

Run the automated suite, then manual checks on the flows that make money: sign-up and login, checkout or billing, imports and exports, scheduled commands, Messenger workers, emails and PDF generation. Security (firewalls, voters, password hashing) and forms deserve explicit tests, because they changed the most across 6.x and 7.x. If the app has few tests, write characterization tests for these flows before step 3, not after.

7. Roll out in stages

Deploy to staging with production-like data, then to production with error monitoring open and a rollback ready. If the app has several servers or tenants, release to a small share first. Keep the 6.4 branch deployable for one or two weeks. After the release, raise PHPStan's level by one and add a CI job that fails on new deprecations, so the next upgrade to 8.x is short.

How long does the upgrade take by project size?

These are typical ranges from our upgrade work, for one or two senior engineers. They assume Symfony 6.4 as the starting point and include testing and rollout.

What moves a project up a row: abandoned bundles, heavy use of SensioFrameworkExtraBundle and annotations, custom security code, a PHP version gap, and missing tests. What moves it down: a deprecation-free 6.4 codebase and a CI pipeline that already runs PHPStan.

For reference, our Ritoria platform has 54 domain entities on Symfony, which puts it in the "medium to large" row. A business system like our custom ERP for a US aircraft service company, with scheduling, warehouse and real-time updates through Mercure, also sits in that range because of the number of flows to test.

Symfony 6.4 to 7.4 upgrade checklist

• Production, CI and local PHP versions listed
• composer outdated and blocking packages reviewed
• Every bundle checked for Symfony 7 support; plan for abandoned ones
• Error monitoring and a tested backup restore in place
• Tests on critical flows (characterization tests if coverage is low)
• PHP upgraded to 8.2+ (8.4 recommended) as a separate release
• Annotations converted to attributes with Rector
• SensioFrameworkExtraBundle and doctrine/annotations removed
• Zero deprecations in the test suite and on main pages
• symfony/* constraints and extra.symfony.require set to 7.4.*
• composer recipes:update reviewed recipe by recipe
• Security, forms, serializer and Messenger workers tested explicitly
• Staging release with production-like data
• Production rollout with monitoring and rollback plan
• CI job that fails on new deprecations

What are the main risks?

The upgrade itself is predictable. Projects go wrong when the audit is skipped and an abandoned dependency is discovered in week six.

What does a Symfony upgrade really cost?

Cost follows engineer-days. With typical 2026 market rates for senior Ukrainian engineers of roughly $30 to $50 per hour, the time table above translates into a few thousand dollars for a small, clean app and tens of thousands for a large platform. Western European and US agencies typically charge two to four times more per hour for the same work.

With us, a Symfony upgrade project starts from $10,000 with a fixed quote after a short scoping call. Typical ranges:

Most mid-size business applications land in a typical range of $10,000 to $30,000. If the audit shows the app is older than 6.4 or framework-less, the work becomes a modernization project; our guide on how to modernize a legacy PHP application covers that path. If you prefer a monthly budget for ongoing maintenance and upgrades, a dedicated development team is often simpler.

When should you combine the upgrade with adding AI?

Combine them when the AI feature touches the same code you are already testing during the upgrade, and when your deadline allows a few extra weeks. You pay for the test safety net, the CI work and the regression testing once instead of twice.

Good reasons to combine:

1. The AI feature needs modern Symfony features. Messenger workers, the rate limiter, attributes and the newer HttpClient are what AI features are built on, and new AI-related bundles target current Symfony versions first.
2. The same team and tests. Engineers who just mapped your bundles, security and data model build the AI feature faster.
3. One release plan. Upgrade first, then the AI feature on the upgraded core a few weeks later, under one project.

Keep them separate when the upgrade is urgent (for example a security audit deadline) or when the AI feature is still an idea without a clear user flow. In that case, upgrade now and validate the idea later as a separate step, for example as a 4-week AI Sprint at a fixed $10,000.

Our own AI Resume Master runs on PHP and Symfony with React and Python, and reached 50,000 monthly active users. How we add OpenAI or Claude to Symfony apps is explained in our guide on adding AI to a Symfony app.

Our verdict

Plan the upgrade now, while Symfony 6.4 still gets bug fixes, and target 7.4 LTS on PHP 8.4. Do it in three releases: PHP, deprecations, then the version switch. Start with a short audit so the abandoned bundle is found in week one. For a typical business application it is a 3 to 12 week project with a known cost, and every month of waiting adds to it.

If you want a team to take it on, see our Symfony development services or contact us with your current Symfony and PHP versions and the list from composer outdated.