Skip to content
All posts

Still on PHP 5? Here's what happens when you do nothing

Andrés Reyes Galgani July 6, 2026
PHPsecuritymaintenance

We see the same pattern with PHP 5 apps, every time. The code works, revenue depends on it, and nobody wants to be the person who breaks it. So the upgrade keeps getting postponed. Here is what that postponement actually costs, in the order it usually arrives.

The scanners find you

PHP 5.6 stopped receiving security patches years ago. Every vulnerability discovered since then is permanent, and the internet knows it. Unpatched boxes get probed by automated scanners within hours of being exposed, and the scripts are not picky: they try known PHP 5 exploits in bulk and move on if they fail.

The first sign is usually a server that runs slow. That is not always “old hardware”. Half the time it is someone else’s crypto miner or spam relay running alongside your app.

Your payment processor starts writing letters

The next letter usually comes from the payment processor. Old PHP means old TLS, old ciphers, and a stack that fails their compliance scans. We have taken over projects where the client’s real deadline was not their roadmap. It was the date the processor said they would stop accepting cards.

Your team quietly becomes you

The developer who built it retired, or left, or simply refuses to touch it anymore. Modern developers avoid PHP 5 the way they avoid anything else that can only hurt their career. Every month that passes, the list of people who can work on your codebase gets shorter, and their hourly rate goes up.

Doing nothing has a price too

The common objection is that an upgrade costs money and risks downtime. Fair. But doing nothing is not free either. Between incident response, emergency patches that should not exist, and the slow bleed of candidates who decline the job, the status quo bills you every quarter. The difference is that the upgrade has an end date.

What a reasonable path looks like

For most PHP 5 apps the sequence is boring on purpose:

  1. Back up everything and verify the restore actually works.
  2. Put the app behind monitoring and, if you can, a WAF while you plan.
  3. Freeze deploys and write characterization tests around the money paths: pricing, inventory, checkout.
  4. Upgrade in place, behind a parallel environment, one module at a time.

We have done this enough times that step four is the least dramatic part. The dramatic parts are the first three, which is why we never skip them.

If you are running PHP 5, the cheapest day to start was years ago. The second cheapest is this week. Tell us what you are running and we will give you an honest read on the risk and the path out, before anyone signs anything.

Dealing with something similar?

Describe your situation and we will give you an honest read within 24 hours, including whether you need us at all.

Get in touch
Contact Get Estimate