Glossary
PHP upgrade
Also: PHP 8 migration · PHP version change
Moving an application to a PHP version that still receives security updates. The effort rarely sits in the language, it sits in the dependencies.
The language changes between PHP 7 and 8 are manageable and well documented. What makes projects expensive sits next to them: a library with no successor, a framework three major versions behind, an extension that never existed for the target version.
On top of that comes the situation such projects usually start from. The code runs, it earns money, and the people who wrote it are no longer around. Without tests every change is a bet that you have found everything.
The deadlines are fixed years in advance. As of August 2026 everything up to and including PHP 8.1 no longer receives security updates, and for 8.2 the deadline ends on 31 December 2026. As a target 8.4 usually holds: out long enough for the libraries to have caught up, and supported until the end of 2028.
The mechanical part can be automated. Rector rewrites type declarations, deprecated calls and changed signatures, PHPStan finds what still does not fit afterwards. What a tool cannot rewrite safely belongs on a list for manual work rather than being changed quietly.
The most expensive mistake is doing everything in one go: language version, framework and dependencies at the same time. If something is broken afterwards, nobody knows what caused it. Separate steps take longer on paper and are back in production sooner.
How you notice it
- The PHP version in use no longer receives security updates.
- The hosting provider announces it is switching the old version off.
- Composer reports conflicts as soon as a single package is raised.
- An audit or a customer requires a supported runtime.
Frequently asked
How long does a PHP upgrade take?
From two weeks to several months, and the range does not come from the size of the codebase. What decides it are the dependencies and the test coverage. That is why an assessment comes first: static analysis against the target version plus a check of every package. After that the duration can be estimated, before that it cannot.
Which version should you aim for?
Usually not the very newest but the one before it: the libraries have caught up, the first teething problems are fixed, and there are still years of support left. As of 2026 that is PHP 8.4.
Can this be done without downtime?
Yes, as long as not everything happens at once. Language version, framework and dependencies are changed separately, each change rolled out on its own and reversible on its own. On the publishing platform from my case studies the language change, the new search and the platform move ran as three projects, without a single day of downtime.