Symfony 6.4, Drupal 10 and PHP 8.2: Three Support Deadlines Before 2027 and What to Do

Within five weeks at the end of 2026, three foundations of PHP websites lose support: bug fixes for Symfony 6.4, all releases for Drupal 10 and security fixes for PHP 8.2. Nothing switches off on those dates, but from then on every problem found stays unfixed. Here is what ends and when, how to find out in ten minutes whether your site is affected, the upgrade path for each case, and why the question matters twice as much if a sale or an investor is ahead.

Three dates

What ends and when

The three deadlines come from three different projects, and each one has its own rules. Together they cover a large share of the PHP websites and business systems built between 2021 and 2024.

The dates are linked. Drupal 10 runs on Symfony 6.4 components, so a Drupal 10 site meets the first two deadlines at once, and many of those sites run on PHP 8.1 or 8.2, which brings the third. Laravel sites are not outside the picture either: Laravel 10 lost its security support in February 2025 and Laravel 11 in March 2026, and both sit on Symfony 6 or 7 components of the same age. Why Laravel, Drupal and Symfony are so tied together is in Symfony in 2026: The Framework Modern PHP Is Built On.

What it means

The site does not switch off

On 1 December nothing happens. The site opens, orders come in, the admin panel works. That is exactly why these deadlines get missed: there is no moment when the problem becomes visible.

What changes is what happens next time something is found. When a vulnerability is discovered in Drupal core after 9 December, there will be no Drupal 10 release that closes it. When a bug in a Symfony 6.4 component breaks a form or a payment after 30 November, the fix will go into 7.4 and 8.x, not into 6.4, unless it is a security issue. And when PHP 8.2 gets a hole after New Year, the hosting company or the server administrator has nothing to install.

Around that core risk, smaller ones pile up month by month:

• hosting providers retire old PHP versions from their panels, sometimes with a few weeks' notice;
• new versions of libraries, payment modules and AI tools stop supporting old PHP and old framework versions, so every new feature costs more;
• security questionnaires from corporate clients, banks and insurers ask which versions you run and whether they are supported;
• card payment security standards require known vulnerabilities to be patched, and a component without support cannot be patched.

Each month without support makes the eventual upgrade a little longer, because the gap between your versions and the current ones grows. The cheapest time to move is while the old version is still supported and the path from it is well documented.

Nothing breaks on the deadline. Everything found after it stays broken.

How to check

Find out what your site runs on

You do not need to read code to know whether these dates concern you. Your developer or hosting support can answer in ten minutes, and if you have server access you can check yourself. These are the commands that show the versions:

# PHP version on the server
php -v

# Symfony application: version of the framework core
composer show symfony/http-kernel

# Laravel application
php artisan --version

# Drupal site (with Drush installed)
drush status

In Drupal there is also a page in the admin panel: Reports, then Status report. It shows the Drupal version and the PHP version at the top. Here is how to read what you find:

If the answer is "we do not know who has access to the server", that is a finding in itself, and an urgent one. Recovering access and documentation is the first step of any project takeover.

Symfony 6.4 to 7.4

The upgrade path for Symfony

Symfony makes this move predictable on purpose. Every change between 6.4 and 7.0 was announced in advance as a deprecation warning, so a 6.4 application already knows what it has to change. The usual order of work looks like this:

1. Clear the deprecations on 6.4. In the development environment Symfony logs every call to an outdated feature with the place in the code. The team fixes them one by one while the site still runs on 6.4, so nothing is at risk.
2. Check third-party bundles. This is where most delays come from. Each external package must have a version for Symfony 7; abandoned ones have to be replaced or taken into your own code.
3. Move PHP to 8.2 or newer. Symfony 7.4 requires PHP 8.2 at least. We recommend going straight to 8.4, which has security support until the end of 2028, so the server question is closed for two years.
4. Raise the version constraints to 7.4 in the dependency file, update, run the tests and go through the key scenarios by hand: login, forms, payments, emails, integrations.
5. Release in stages, with a copy of the database and a way back ready.

Why 7.4 and not 8.x? Symfony 7.4 is the long-term support version: bug fixes until November 2028 and security fixes until November 2029. The 8.x line brings new features but needs PHP 8.4 and an upgrade every six months until 8.4 LTS arrives in November 2027. For a business system that is supposed to work rather than follow releases, 7.4 is the calm choice, and from 7.4 the next step to 8.4 LTS will be just as mechanical.

Drupal 10 to 11

The upgrade path for Drupal

Drupal follows the same logic with its own tools. Drupal 11 needs PHP 8.3 or newer and runs on Symfony 7, and Drupal moves one major version at a time, so a Drupal 10 site reaches Drupal 12 through 11 anyway. Drupal 11 is supported until early December 2028, which gives two quiet years after the upgrade.

The work usually goes in this order. First the Upgrade Status module is installed: it scans the site and lists which contributed modules have Drupal 11 versions and which custom code uses outdated features. Then contributed modules are updated one by one, and those that were abandoned are replaced. Then the custom modules and the theme are fixed, PHP on the server is raised, and the core is moved to Drupal 11.

The size of the job depends almost entirely on the custom code. A site built from standard modules with a custom theme moves quickly. A site where the business logic lives in a dozen custom modules, with integrations to a CRM or an accounting system, needs a proper audit first. We have written modules for the admin panel of a Drupal site of a large American company, so we know how much a Drupal module today is really Symfony code: services, events and routing, the same parts that change between Symfony 6 and 7.

The size of a Drupal upgrade is the size of its custom code.

One of our clients has an aging Drupal site that they wanted to rewrite on something new, and they are still weighing it. For a site like that, the end of Drupal 10 support turns a question that could wait into one with a date.

PHP 8.2

The server under it

PHP is the layer every one of these frameworks stands on, and it has its own calendar: two years of bug fixes and two years of security fixes for each version. PHP 8.1 lost security support on 31 December 2025, PHP 8.2 loses it on 31 December 2026, PHP 8.3 at the end of 2027 and PHP 8.4 at the end of 2028.

Changing the PHP version is often the smallest part of the work, and sometimes it cannot be done first, because an old framework simply does not run on new PHP. That is why the order matters: the framework is prepared on the old PHP, then PHP is raised, then the framework is moved. Our own site went through the same sequence: before moving it to Laravel 13 we prepared the code on the old PHP, and since October 2026 it has run on PHP 8.4. How that went is in Six Laravel Versions in Three Days.

Not always an upgrade

When an upgrade is not worth it

An upgrade is the right answer when the business logic is sound and the main problem is age. It is the wrong answer in two situations. The first is when the code has become a maze that nobody dares to touch: every upgrade step uncovers new surprises, and the cost of moving it forward approaches the cost of building it again. The second is when the business has changed so much that the old structure is in the way.

In those cases the choice is between a rewrite, often on Laravel, and keeping the old core while building new parts beside it with a clear boundary. A business solution more often needs the simpler and more widespread Laravel, which is cheaper for the owner to maintain; Symfony or Drupal stay the right base for heavy, complex systems and for sites that live on Drupal's content model. We described these options in more detail in Symfony in 2026, and the signs of a codebase worth keeping are in What Separates a Premium Laravel or Symfony Build.

Some companies sell paid extended security support for versions that have reached end of life. It can be useful as a bridge for a few months while the upgrade is prepared, but it buys time, not a solution: the gap to current versions keeps growing.

Cost and time

What it costs and how long it takes

There is no honest fixed price for an upgrade without looking at the code, and anyone who quotes one by phone is guessing. What decides the size of the job is known, though: how much custom code there is, how many third-party modules or bundles it depends on and whether they have new versions, whether there are tests, and how many integrations must keep working.

With us the work starts with an audit that answers those questions and gives a plan with a price. For website modernization the audit costs from $300 for a small site and from $1,000 for a large one. If the project comes from another contractor and access or documentation has to be recovered, it starts with a takeover audit, from $3,000. The work itself is priced after the audit at our team rate: $75 an hour for a senior developer and $45 to $50 for a middle one, and much of an upgrade can go to a middle developer under senior review.

Starting now costs less than starting in January. A move from a supported version, with documentation and community answers still fresh, is a list of known steps. A move from a version that has been out of support for a year starts with finding out what else has broken in the meantime.

If a sale is ahead

Why it matters twice before a deal

For an owner who plans to sell the company, bring in an investor or hand the business to a successor, outdated versions stop being a technical detail. A buyer's technical due diligence checks the framework, CMS and PHP versions and their support dates in the first days of the review. An unsupported core becomes a finding with a repair cost attached, and that cost is either taken off the price, held back from the payment until the fix is done, or written in as a condition before closing.

The difference between a seller who knows this and one who does not is timing. A finding that the seller has already fixed, or at least planned with a date and a cost, weakens the buyer's position far less than one the buyer discovers. That is the work of The Structure, our brand for technical due diligence in software deals: an exit readiness review finds what a buyer would find and helps fix it in time, and vendor due diligence gives the seller an independent report to put in front of buyers.

A fourth deadline falls in the same weeks for sites that send mail through Microsoft 365: at the end of December, sending with a plain login and password is turned off by default. How to find what is affected is in Microsoft 365 Turns Off SMTP AUTH Basic Authentication in December 2026.

FAQ

Sources

• Symfony Releases
• Drupal core release schedule
• PHP Supported Versions
• Upgrading a Major Version, Symfony documentation
• Laravel 13 Release Notes and Support Policy