When the PHP2Shell vulnerability hit, companies had to switch their software off because it ran on PHP 8.1 and worked on no newer version. So that this does not happen to you, we move existing code to a current PHP version without rewriting it, and harden the server while we are at it.
PHP 8.1 has received no security updates since the end of 2025. When the PHP2Shell vulnerability hit in October 2026, there was no new 8.1 release, only makeshift fixes to build in yourself. The clean way out is a newer version, and that is exactly where a lot of older software stops working without changes.
Every PHP version cleans up. Functions that only raised a warning for years get removed or behave differently. In a booking system or shop that several people have written over the years, those spots are spread across hundreds of files.
We find those spots, fix them and test everything on a copy before the new version goes live. Your software looks and works the same afterwards. It just runs on a PHP version that gets security updates again.
ANALYSE // VOR DEM PREIS
We run your code through automated checking tools and read it ourselves. Afterwards you know how many places are affected, what it costs and how long it takes. Only then do you decide.
TEST // OHNE AUSFALL
The changes happen on a test environment running the new PHP version. Your live system keeps running unchanged in the meantime. We only switch once booking, payment and forms run cleanly on the copy, and the way back stays open.
SERVER // ÜBERWACHT
A current PHP version is half the job. We also check the server: updates, access, permissions. And we set up monitoring that reports as soon as files change or new ones appear. That way a break-in gets noticed before it does damage.
A complete rebuild when an upgrade will do. Many agencies propose redoing everything as soon as they see old software. That takes months and costs several times as much. In most cases the existing code can be adapted, and that is what we suggest first.
Simply switching the version at the host and hoping. That is exactly how booking systems and shops go offline on a Monday morning. Without testing on a copy, a PHP upgrade is a gamble with your revenue.
And an open hourly rate. After the code check you get a fixed price. If the work turns out to take longer, that is our risk, not yours.
Source: php.net, Supported Versions. Moving to 8.2 today means facing the same question again in just over two months.
If you hesitate at any of these questions, send us a short message. We will tell you honestly whether action is needed, even if the answer is no.
It depends almost entirely on how much custom code is affected. A plugin with three outdated spots is different from a booking system that was written over ten years. So we look at the code first and then name a fixed price. We do not work on an open hourly rate.
Yes. PHP 8.1 has received no security updates since 31 December 2025. When the PHP2Shell vulnerability hit in October 2026, there was no new 8.1 release, only makeshift fixes you have to build in yourself. That is nothing to rely on. Your software keeps running, but from then on every new vulnerability is your problem.
For now yes, for the long run no. PHP 8.2 only gets security updates until 31 December 2026. If you have to make changes anyway, go straight to 8.3 or 8.4. The extra effort is usually small, and 8.4 gives you just over two years of peace instead of two months.
No. We work on a copy running the new PHP version, and your live system keeps running unchanged in the meantime. We only switch once everything runs on the copy. That takes minutes, and the old version stays ready as a way back.
Yes. WordPress, Shopware, older shop systems and custom applications such as booking or reservation systems. What matters is not the system but the custom code inside it. We read it, whoever wrote it.