.NET 8 and 9 support has ended, and PHP 8.2 is next: what to do now

Two support deadlines land within seven weeks of each other at the end of 2026. If your business runs a .NET or PHP application, at least one of them probably affects you.

Platform	End of support	What to move to
.NET 8 (LTS)	10 November 2026	.NET 10
.NET 9 (STS)	10 November 2026	.NET 10
PHP 8.1 and older	31 December 2025 (already ended)	PHP 8.4 or 8.5
PHP 8.2	31 December 2026	PHP 8.4 or 8.5

What happened with .NET 8 and .NET 9

.NET 8 was a long-term support release, shipped in November 2023 with three years of support. .NET 9 was a standard-term release, originally due to lose support in May 2026. In September 2025 Microsoft extended standard-term releases from 18 to 24 months, which moved .NET 9’s end date to exactly the same day as .NET 8’s: 10 November 2026.

So teams that skipped ahead to .NET 9 gained nothing in runway. Both versions are now out of support. The version to move to is .NET 10, the current long-term support release, which Microsoft supports until November 2028. (.NET 11 shipped on 10 November 2026 as a standard-term release and is supported until the same month, but for most business applications the long-term release is the safer target.)

And PHP 8.2

PHP gives each version two years of active support and two years of security-only fixes. PHP 8.2 has been on security fixes only since the end of 2024, and those stop on 31 December 2026. PHP 8.1 already reached end of life at the end of 2025.

Frameworks and hosts move with these dates. Some managed hosting providers have already started removing PHP 8.2 ahead of its end-of-life date, and recent Laravel and WordPress releases expect newer PHP versions.

“End of support” does not mean “stops working”

Your application will run tomorrow exactly as it did yesterday. Nothing switches off. What changes is this:

• No more security patches. Any vulnerability discovered from now on stays open in your application, and attackers know which versions are unpatched.
• Compliance gets harder. Security questionnaires, cyber insurance forms, PCI DSS and ISO 27001 audits routinely ask whether you run supported software.
• The ecosystem moves on. New versions of libraries and NuGet or Composer packages stop supporting old runtimes, so even small changes get harder over time.
• Upgrades get more expensive the longer you wait. Jumping one version is routine. Jumping three, with several years of package drift, is a project.

How to approach the upgrade

1. Find out exactly what you are running

Start with an inventory. For .NET, check the TargetFramework in each .csproj file and the runtime installed on your servers. For PHP, check php -v on each server and the require section of composer.json. Note your framework version (ASP.NET Core, Laravel, Symfony, WordPress) and any packages that have not been updated in years.

Many businesses discover they are running more than one version, often a forgotten admin panel or background job still on something much older.

2. Decide how big the jump is

• .NET 8 or 9 to .NET 10 is usually the easiest upgrade in this list. Update the target framework, update packages, work through Microsoft’s list of breaking changes, and test. For a typical web application, this is days to a few weeks, not months.
• .NET 6 or 7 to .NET 10 is similar but with more breaking changes to review, because you are crossing several versions at once.
• .NET Framework 4.x to modern .NET is a different kind of project. Web Forms, WCF and some Windows-specific libraries do not exist in modern .NET, so parts of the application need rewriting. This is best done in stages rather than as one big switch.
• PHP 8.2 to 8.4 or 8.5 is usually manageable for well-maintained code. The work is mostly in updating Composer packages and fixing deprecation warnings. Older custom PHP, or applications that skipped several Laravel versions, take longer.

3. Put tests around what matters before you change anything

If your application has few automated tests, add a small set covering the flows that make money or would cause real damage if they broke: logins, checkout, invoicing, data exports. These do not need to be exhaustive. They need to tell you quickly whether the upgrade broke something important.

4. Upgrade in a branch, deploy to staging, then production

Keep the upgrade separate from new feature work, so if something goes wrong you know why. Run it on a staging environment that mirrors production, including the same database version and server setup, before switching over.

5. Do not stop at the runtime

While you are in there, update the hosting stack too: operating system, web server, database version and container base images. An application on .NET 10 running on an unsupported Windows Server or Linux release has only solved half the problem.

What if you cannot upgrade yet?

Sometimes there is a genuine reason to wait: a major release is about to go out, or the original developers are gone and nobody understands the code. In that case:

• Put the upgrade on the calendar with a fixed date, not “next quarter”.
• Reduce exposure: put the application behind a web application firewall, restrict admin areas by IP, and review who has access.
• Monitor logs for unusual activity.
• Consider paid extended support from a third party if you are under strict compliance requirements, but treat it as a bridge, not a plan.

The short version

If you are on .NET 8 or 9, upgrade to .NET 10 now. It is usually a contained piece of work. If you are on PHP 8.2 or older, plan the move to PHP 8.4 or 8.5 before the end of the year. If you are still on .NET Framework or an old PHP 7 application, start with an audit so you know how big the job really is before anyone gives you a quote.

Support dates are taken from Microsoft’s .NET support policy and the official PHP supported versions page, current as of November 2026.