Inventory of the application
PHP version, extensions, libraries and dependencies, including those nobody maintains.
Upgrading to PHP 8, step by step and with tests
Security updates for PHP 8.2 end on 31 December 2026, and for PHP 8.1 and older they have already ended (As of 2026-10). We move long-running PHP applications, including those with Smarty templates and jQuery front ends, to PHP 8.4 or 8.5 and test every stage.
- PHP, Smarty and Slim since 2012
- Reply within one working day
When your host, insurer or auditor asks about your PHP version
Many PHP applications run for years without maintenance until someone asks which version they use. These are typical reasons for an upgrade:
- The hosting provider charges extra for your PHP version or announces that it will switch it off.
- A client, an audit or the insurer asks whether your versions are supported.
- An earlier upgrade attempt failed, and nobody has touched the application since.
- The developer has left, and the application still runs on PHP 7.4 or older.
The hosting panel, or the command php -v on the server, shows which version is running. The support dates of all versions are further down this page and under PHP versions and end of support.
Why continuous PHP updates matter: PHP2Shell in October 2026
On 21 October 2026 the PHP project released fixes for two critical flaws in the PHP core, known as PHP2Shell. Details had been circulating online a day earlier. Every PHP installation serving web requests was affected, whether it runs PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. An attacker needed no account and no credentials, only a request to the web server.
- CVE-2026-109618, remote code execution after running out of memory: if PHP runs out of memory during a request, it can stop halfway through setting up internal request data. The cleanup then treats the half-built data as valid.
- CVE-2026-109619, remote code execution through stale state: internal state of a request can survive after its memory has been freed. A later request handled by the same worker can use it before it is reset.
Attack attempts were seen the same day. Because updated packages were missing for many servers, public authorities, police portals and a large university hospital in Germany took their websites offline as a precaution, as did organisations in other European countries. Germany's federal cyber security agency BSI had recommended taking websites offline until they were updated.
On a supported version, a small update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 was enough. PHP 8.1 and older got no official release, only minimal source fixes or packages from LTS vendors (As of 2026-10).
Sources: security advisory of the PHP project of 21 October 2026 (opens in a new window), GHSA-w8hw-w9fx-j79w (opens in a new window) and GHSA-6wmf-4rv5-p3rp (opens in a new window).
Conclusion: if you update continuously, a new patch release is tested and rolled out in hours. A jump across several versions takes days to weeks.
How the migration to PHP 8 works: from inventory to changeover
-
Review: what has to change in the application for PHP 8
We record the version, extensions, libraries, Smarty, jQuery, database and server, and check the code for incompatibilities with PHP 8. The result is a staged plan with effort estimates in working days.
-
Test environment and test cases
We set up a test environment with a copy of code and database and leave your production system unchanged. For the critical processes we create test cases before any change, so that any differences become visible.
-
Upgrade in stages
We upgrade the application in stages, usually one version at a time, for example from 7.4 through 8.0 and 8.1 to the target version. The test cases run after each stage, so the application stays in working order.
-
Changeover with a fallback plan
We switch production over in a quiet period and keep a tested fallback plan ready. Afterwards we monitor error logs and response times and fix anything that stands out.
What the review result contains
-
-
List of incompatibilities
Places in the code that break under PHP 8, ordered by risk and effort.
-
Staged plan with target version
Sequence of steps, target version 8.4 or 8.5 and effort in working days.
-
Test report after each stage
What was tested, what has changed and what is still open.
-
Fallback plan and handover
How the changeover runs, the tested fallback plan and the documentation of the new state.
Until when each PHP version receives security updates
| Date | Event | Source |
|---|---|---|
| 2018-12-31 | PHP 5.6: end of security updates. | php.net (opens in a new window) |
| 2019-01-10 | PHP 7.0: end of security updates. | php.net (opens in a new window) |
| 2019-12-01 | PHP 7.1: end of security updates. | php.net (opens in a new window) |
| 2020-11-30 | PHP 7.2: end of security updates. | php.net (opens in a new window) |
| 2021-12-06 | PHP 7.3: end of security updates. | php.net (opens in a new window) |
| 2022-11-28 | PHP 7.4: end of security updates. | php.net (opens in a new window) |
| 2023-11-26 | PHP 8.0: end of security updates. | php.net (opens in a new window) |
| 2025-12-31 | PHP 8.1: end of security updates. | php.net (opens in a new window) |
| 2026-12-31 | PHP 8.2: end of security updates. | php.net (opens in a new window) |
| 2027-12-31 | PHP 8.3: end of security updates. | php.net (opens in a new window) |
| 2028-12-31 | PHP 8.4: end of security updates. Possible target version. | php.net (opens in a new window) |
| 2029-12-31 | PHP 8.5: end of security updates. Possible target version. | php.net (opens in a new window) |
What typically breaks when moving between PHP versions
| Version jump | What typically breaks | What we check |
|---|---|---|
| From PHP 5.6 to 7.x | The old mysql interface and the ereg functions are removed, and mcrypt has not been part of the core since 7.2. The database layer needs mysqli or PDO. | All database access, encryption and helper libraries. |
| From PHP 7.4 to 8.0 | Comparisons of numbers and text give different results, many earlier warnings become errors, and functions such as each() and create_function() are removed. | Validation, error handling, database access and constructors in the old PHP 4 style. |
| Between PHP 8.1 and 8.5 | The application usually keeps running, but the log shows deprecation notices for constructs such as null as a function argument, dynamic properties or utf8_encode(). | We collect the notices and fix the affected code before the constructs are removed. |
| Around the code | Character encoding (latin1 or utf8mb4), unmaintained libraries for PDF, Excel or SOAP, scheduled jobs and the database version. | We check these points in the inventory, not only in testing. |
We check Smarty, jQuery and the database as well
Smarty. The Smarty project provides security fixes only for the latest minor versions of Smarty 4 and 5; Smarty 2 and 3 are no longer supported (As of 2026-10). The effort usually lies in templates with custom plugins or {php} blocks.
jQuery. jQuery runs in the browser and does not depend on PHP, but it often sits in the same templates. jQuery 1.x and 2.x are no longer supported (As of 2026-10). Usually it is enough to move to jQuery 3 or 4 with jQuery Migrate.
Database. We check the version of MySQL or MariaDB in the same inventory as the code and plan a database upgrade together with the PHP upgrade where needed.
The migration guides in the PHP manual (opens in a new window) list all changes per version. Our engineers' work with PHP is described on the page PHP, and the kinds of systems they know under Experience.
Our engineers' experience with PHP, Smarty and databases
- PHP
- Since 2012, with Smarty, Slim and WordPress
- Full stack and DevOps
- Since 2012, from code to server
- Databases
- MySQL and MariaDB, including Galera clusters; migrations such as Firebird to MariaDB
- Servers
- Linux, Nginx, Apache and Docker
How we start the PHP update
- Code, credentials and documentation stay with you.
- At the end you receive a handover that another provider can continue from.
- We also tell you when an upgrade is not worth it, for example because the application will soon be replaced.
And if someone on our side drops out? We write the documentation on request. The repository is normally with you. We arrange cover on request.
The PHP upgrade is part of our service Migration and modernisation.
The first step: Legacy review or PHP 8 compatibility scan
Legacy review
For companies with a system that nobody knows well any more: before an update, before a migration or when changing service provider.
- Inventory of versions and dependencies
- Map of application, database, server and email
- Risk register covering security, support and knowledge
- Assessment of backups and restores
- Recommendation “stay, upgrade or migrate” with an options matrix that also covers “move into a container” and “expose as an API”
- Effort estimate in days
The price covers one system, meaning one application with its database and its server. We price further systems individually.
What the result contains
A written report with inventory, risk register, recommendation and effort estimate. The report is yours.
PHP 8 compatibility scan
For companies with a long-running PHP application that want to know what will break under PHP 8 and how much work the upgrade takes.
- Inventory of PHP version, extensions, libraries and database
- Check of the code for places that no longer run under PHP 8
- Smarty templates and jQuery front end in the same pass
- List of incompatibilities ranked by risk and effort
- Staged plan up to the target version with an effort estimate in working days
We agree the scope and price in the intro call and confirm them in writing before we start. If you wish, the upgrade itself follows as a separate assignment.
What the result contains
A written list of incompatibilities with a staged plan and an effort estimate. The list is yours.
A case from our work
-
PHP 8.2 and the 30-second limit: pages waiting for the session lock
Web portals · 4 hours
After the move from PHP 7.4 to PHP 8.2, the same page loaded normally one moment and failed after 30 seconds the next. We rebuilt both versions side by side and found the cause: about 20 parallel AJAX calls of one user waited for the lock on the session file, one after another. Fixed with one line per script, without rewriting the application.
Questions about upgrading to PHP 8
Do we have to rewrite our PHP application for PHP 8?
Usually not. If the problem is only the PHP version, we update the application in stages and leave its logic unchanged. A rewrite is rarely worthwhile.
It becomes an option when the framework is no longer maintained, there are no tests and the business rules can be written down. Whether that applies to you is shown by the legacy review, which gives a recommendation and an effort estimate in working days.
What does the update to PHP 8 cost, and how long does it take?
A reliable figure is only possible once we have looked at your application. Effort and duration depend on its condition, not on its size alone. The deciding factors are the starting version, unmaintained extensions and libraries, Smarty, the database, character encoding and existing tests.
We quote fixed prices for the entry products, here the Legacy review with a PHP 8 inventory. It delivers the effort estimate in working days. After that we send you an offer for the update. It is at a fixed price if the scope is clear, otherwise on a time and materials basis.
Will the application behave exactly as before after the update?
That is the aim, and the tests demonstrate it for the workflows they cover. Before we change anything, we write test cases for the critical functions. They run again after every stage, so any deviation shows up immediately.
For workflows that nobody has tested there is no guarantee, which is true of any software that has evolved over many years. That is why a test environment and a rollback option are part of the method. Production is switched over only when the test cases pass, and the rollback to the previous state stays possible until operations are stable.
What happens if the update is not finished in time?
The application keeps running. After 31 December 2026, however, PHP 8.2 no longer receives security updates (As of 2026-10), and the risk grows with every vulnerability that becomes known later.
If there is not enough time for the whole update, there are two ways to bridge the gap. An intermediate target such as PHP 8.3 receives security updates until 31 December 2027 (As of 2026-10) and buys you a year. In addition, access can be restricted, a WAF placed in front of the application and administrator access limited to a VPN. This lowers the risk but does not remove it.
Is my host's extended support an alternative to updating?
In the short term it can buy time, but it is not an alternative to the update. It applies only at the host in question and ends at the latest when that version is switched off. It also says nothing about whether your application runs on a newer version.
Saving the surcharge is not the reason to update. The surcharge is a warning sign: your version counts as end-of-life at the host. If you want to move away from classic hosting anyway, see From hosting to containers.
Is a WAF enough?
Not on its own. A web application firewall (WAF) filters typical attacks in front of the application and buys time. It does not close a vulnerability in the code. That is why we combine it with fixing known vulnerabilities, network segmentation and administrator access through a VPN only.
A WAF with rules written for your application triggers fewer false alarms and protects better in practice than the default configuration. If the code cannot be changed quickly, a WAF with isolation is a stop-gap until the update. The risk then falls but does not disappear.
When can you start?
You will receive a first reply within one working day. When we begin work depends on our current workload and on the scope. We give you a binding answer in the intro call. If it is urgent, the 48-hour emergency assessment starts as soon as we have access to the system.
Which PHP version are you running?
Tell us the version, your host and what prompted the question, in a few sentences. We reply within one working day and suggest a first step.