PHP Upgrade Cost: Estimate It Before PHP 8.2 Runs Out

Short answer

PHP upgrade cost depends mainly on the starting version, the framework version, test coverage, outdated dependencies and how much custom code there is. In the worked example below, a mid-sized Symfony 6.4 application moving from PHP 8.1 to PHP 8.4 and Symfony 7.4 takes about 25 developer days, roughly £11,750 at the UK median contract rate.

Technician crouching with a laptop in front of an open server rack in a data centre — Photo: Derrick Coetzee from Berkeley, CA, USA, CC0, via Wikimedia Commons

PHP 8.2 stops receiving security fixes on 31 December 2026. PHP 8.1 already lost them at the end of 2025. If you run either version in production, you have a date in the calendar whether you like it or not.

Plenty of people do. W3Techs data from October 2026 shows 27 percent of PHP websites still on PHP 7 and just under 8 percent on PHP 5. And the Perforce 2026 PHP Landscape Report found that 76 percent of the PHP users it surveyed had an upgrade or migration planned, while 68 percent had completed one in the previous 12 months.

When each PHP version runs out

Each PHP release gets two years of active support and then two years of security fixes only. The official dates are on php.net.

End of support for current PHP versions

31 Dec 2025PHP 8.1: no more security fixes
31 Dec 2026PHP 8.2: security fixes end; PHP 8.4: active support ends
31 Dec 2027PHP 8.3: security fixes end
31 Dec 2028PHP 8.4: security fixes end
31 Dec 2029PHP 8.5: security fixes end

Source: php.net, Supported Versions (October 2026)

My advice: don’t stop at the oldest version that’s still supported. Going from 8.1 to 8.3 today puts you back in the same position at the end of 2027. PHP 8.4 or 8.5 buys two more years for similar effort.

The five things that drive the cost

No serious supplier quotes a fixed price without looking at the code. The effort comes down to a handful of factors you can check yourself.

The starting version matters most. Going from 8.3 to 8.4 changes little. From 7.4 to 8.x, a lot changes, including how numbers compare with strings and stricter errors for patterns PHP used to tolerate.

Then the framework. Frameworks support specific PHP ranges. Symfony 7.4 needs at least PHP 8.2, and the Symfony 8 line needs PHP 8.4, according to symfony.com/releases. Laravel 10 only runs up to PHP 8.3. So a PHP upgrade often drags one or two framework upgrades with it. How the two frameworks differ on support windows is covered in Laravel vs Symfony.

Tests come third. With good coverage, a test run after each step shows what broke. Without tests, someone clicks through the app for hours and hopes. JetBrains’ State of PHP 2025 found that 32 percent of PHP developers write no tests at all. On those projects, adding tests is usually the single largest line item.

Dependencies are fourth. One abandoned package can delay an upgrade by weeks while you replace it or maintain a fork.

Custom code is fifth. Applications with no framework, a home-made template engine and their own database layer are the hardest to estimate, because tools don’t recognise their patterns.

A worked example

To give a sense of scale, here’s an example with assumed effort. It describes a mid-sized Symfony 6.4 application on PHP 8.1, with some tests but gaps around critical flows. The goal is PHP 8.4 and Symfony 7.4 LTS.

Worked example: Symfony 6.4 on PHP 8.1 to Symfony 7.4 on PHP 8.4

Inventory and plan: 3 days
Tests for critical flows: 6 days
Clear all deprecations on Symfony 6.4: 5 days
PHP 8.1 to 8.2, then Symfony 7.4: 4 days
PHP 8.4 with Rector and manual fixes: 2 days
Update or replace packages: 2 days
Staging test, rollout, aftercare: 3 days
Total: 25 days × £470: £11,750
Net, before contingency: about £11,750

Effort figures are assumptions for this example, not market data. Day rate: ITJobsWatch UK median for PHP contracts, six months to 18 Oct 2026. Your project could cost half or twice as much.

The order isn’t accidental. Symfony’s upgrade approach is deprecation-driven: once your app runs on 6.4 without triggering any deprecations, moving to the next major is mostly a matter of updating version constraints. That’s why the deprecation clean-up gets its own line, and why it sits before the framework jump.

Add 20 to 30 percent contingency. Nearly every project has one package or one corner of the code that takes more work than expected. How day rates are set is covered in our article on PHP developer hourly rates.

Tooling that cuts the effort

A few commands give you most of the inventory in under an hour:

composer outdated --direct
composer why-not php 8.4
bin/console debug:container --deprecations
vendor/bin/phpstan analyse --level=5 src
vendor/bin/rector process --dry-run

composer why-not lists the packages that block a given PHP version. It’s usually the most important line of the whole analysis. The Symfony console command shows deprecations collected while building the container. Rector needs a short config file:

<?php

// rector.php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets(php84: true)
    ->withPreparedSets(deadCode: true, typeDeclarations: true);

With --dry-run, Rector only shows what it would change. Your team can see up front how much mechanical work the tool takes off their hands, which on well-structured code is a lot.

Typical breaking points between 8.0 and 8.5

Each release brings changes that trigger warnings or errors in older code. Most are small, but they add up across hundreds of files.

Version	Change	Typical effect on old code
8.0	number-to-string comparison changed	`0 == 'abc'` is now false; conditions flip silently
8.1	passing `null` to non-nullable internal parameters deprecated	floods of notices, for example from `strlen(null)`
8.2	dynamic properties deprecated	classes that set undeclared properties
8.4	implicitly nullable parameter types deprecated	`Logger $logger = null` must become `?Logger`
8.5	backtick operator and casts such as `(integer)` deprecated	old helper scripts, legacy code

Rector handles most of these mechanical cases reliably. The hard ones are those no tool can see. The PHP 8.0 comparison change, for instance, produces no warning; a condition just quietly returns a different result. That’s exactly why you need tests that check business behaviour, not just whether a page loads.

What it costs not to upgrade

The calculation has another side. A PHP version without security fixes stays open to every vulnerability found after its end of life. Under Article 32 of the GDPR, which also applies in UK law, you must take appropriate technical measures to protect personal data. An unpatched runtime is hard to call appropriate. If you take card payments, PCI DSS expects known vulnerabilities to be patched too.

Then there’s the slow creep. New packages require newer PHP versions, developers dislike outdated tools, and every year you wait makes the next jump bigger. You’ll feel it when hiring: an ad that says “PHP 7.4, upgrade one day” attracts different applicants from one that says “PHP 8.4, Symfony 7.4”. What candidates expect is covered in our guide on how to hire a PHP developer.

Who should do the upgrade

If someone on your team has led upgrades before, that’s the best option. They know the code and the traps. Our article on senior PHP developer skills explains how to spot that experience.

If nobody has, a specialist contractor for a clearly scoped upgrade is a good choice. A fixed price after a paid inventory protects both sides. Our guide to hiring a freelance PHP developer covers vetting and contracts.

If the application should also be looked after long-term, including hosting and later upgrades, a studio like OnlineBuilders can take on development and operations together. The one-off project then becomes a predictable routine.

Run composer why-not php 8.4 in your project today. The list it prints is the starting point for any honest estimate, whether you plan the work internally or ask for quotes.

Questions people ask

How long does a PHP upgrade take?

A minor version step such as 8.3 to 8.4 on well-tested code often takes a few days. Moving from PHP 7 to 8.x with framework upgrades can take months. Two or three days of paid analysis produce an estimate you can rely on.

Can I just switch the PHP version in my hosting panel?

Only after testing. Functions disappear between versions and warnings become errors. Switch a staging copy first, run the test suite and check the error logs.

Is it worth upgrading an application we plan to replace?

If replacement is realistic within a year and the app isn't exposed to the internet, you can weigh it up. If it handles customer data online, running a PHP version without security patches is hard to defend. Replacements also tend to take longer than planned.

What is Rector?

Rector is an open source tool that rewrites PHP code automatically for a new PHP version or framework release. It doesn't replace tests, but it removes a lot of mechanical work. JetBrains found about 10 percent of PHP developers using it in 2025.