Stuck on an Old PHP Version? Your Options for Legacy and Bespoke Systems

It usually starts with an email from your hosting company: “PHP 7.4 will be removed from your account on the 1st of next month.” Or it starts with nothing at all — the host upgrades the server overnight, and in the morning your booking system, intranet, customer portal or custom shop shows a blank white page.

The system was built years ago, often by a developer or agency who has since moved on. It does exactly what your business needs, nobody has documentation, and the honest answer to “can we just upgrade it?” is “we don’t know what will break.” Rewriting it from scratch would cost a fortune and take months.

If that sounds familiar, you have more options than “rewrite it” or “leave it and hope.” This guide explains why old systems can’t simply be switched to a newer PHP version, what the real risks of staying put are, and the practical routes we use to keep legacy and bespoke systems safe — from hosting them as they are, to bringing them up to date one step at a time.

Why You Can’t Just Change the PHP Version

In cPanel it’s a single drop-down: pick a newer PHP version and click apply. For a modern WordPress site, that usually just works. For older custom code, it often doesn’t, because each major PHP release removes things that older code relied on:

• The old MySQL functions are gone. Code written with mysql_connect() and mysql_query() stops working completely on PHP 7 and later. In systems from the mid-2000s, these calls can be on almost every page.
• Removed language features. ereg(), split(), each(), create_function(), magic quotes and the old-style constructors all disappeared along the way. Each one is a fatal error if it’s still in use.
• PHP 8 is much stricter. Things that used to be quiet warnings — passing the wrong type to a function, reading an array key that doesn’t exist, comparing strings and numbers loosely — are now errors or behave differently. Code that “worked” for 15 years can fall over on the first page load.
• Old frameworks and libraries. If the system is built on CodeIgniter 2, Zend Framework 1, an early Laravel, an old Joomla or Magento 1, or bundles an ancient copy of PHPMailer, TCPDF or a payment SDK, those pieces have their own compatibility problems on top of your code.
• Encoded files. Some commercial scripts were shipped encoded with ionCube or Zend Guard for a specific PHP version. Without the original vendor, they can’t simply be edited.

And it isn’t only PHP. Newer database servers cause their own breakages: MySQL 8 and recent MariaDB releases use stricter SQL modes (so “lazy” queries with zero dates or missing values are rejected), add new reserved words that clash with old column names, change the default password authentication method that old database drivers can’t speak, and default to the utf8mb4 character set, which can upset old tables and indexes. A system can work perfectly on PHP and still fail because the database underneath it moved on.

The Risk of Doing Nothing

When a PHP version reaches end of life, the PHP project stops releasing security fixes for it. Any vulnerability found after that date stays open forever on a standard installation.

In practice, an old system on an unmaintained server faces several problems at once:

• Known holes stay open. Attackers scan the internet for old PHP versions, old frameworks and old library versions with published exploits. They don’t need to know your system — only what it’s built on.
• Your host will eventually force the issue. Mainstream hosts remove end-of-life PHP versions, upgrade database servers and retire old operating systems. You find out when it breaks.
• Years of updates pile up. Very often the system could have been updated, but the first update that broke something got rolled back — and after that, nobody dared to try again. Ten years later, there’s a decade of skipped security fixes sitting between you and a supported version.
• Compliance and payments. If the system handles customer data or card payments, running unsupported software is hard to defend under UK GDPR, POPIA or PCI DSS — see our POPIA compliance guide.

The good news: you don’t have to fix all of this in one go, and you don’t have to rewrite anything to make it safe.

Your Options, From Simplest to Most Thorough

Every legacy system is different, so there’s no single right answer. These are the routes we use, and most projects combine two or three of them over time.

1. Keep it running safely, as it is

If the system works and you simply need it to keep working, the fastest option is to host it somewhere that will run the PHP version it needs, safely. That’s very different from running an old version on a forgotten server:

• Hardened PHP builds, patched directly. Every PHP version on our servers, from old 5.x releases to current 8.x, is CloudLinux’s hardened build, not cPanel’s standard PHP packages. CloudLinux patches these builds directly and keeps back-porting security fixes from newer releases into versions the PHP project has stopped supporting. Your code still sees the PHP version it was written for, but the known vulnerabilities in PHP itself are fixed.
• Isolation. Each account is locked into its own space with CageFS, so even an old application can’t see or affect anything outside its own account.
• Server-level protection. BitNinja blocks the automated scans and exploit attempts that target old software before they reach your code.
• Per-site PHP versions. The legacy system can stay on the version it needs while your main website runs current PHP 8.x on the same account.

This buys you time — months or years — to plan the next step properly instead of in a panic. For systems we host and maintain, legacy hosting at the PHP version your application needs comes at no additional cost.

2. Patch the application itself

Patching PHP protects the engine, but not your own code or the libraries bundled inside it. The next step is a security audit and patch of the application:

• Update or back-port fixes into bundled libraries (mailers, PDF generators, payment SDKs, editors and upload tools) with known vulnerabilities.
• Close the classic holes in hand-written code: SQL injection, cross-site scripting, unprotected file uploads, weak password storage and admin pages without proper login checks.
• Tighten the configuration: hide error output, protect config and backup files, and lock down directory permissions.

Where years of updates were skipped, we work through them in steps rather than one giant jump — applying and testing each batch on a copy of the system, so when something breaks we know exactly which change caused it. That’s how a decade of blocked security updates gets installed without a decade of downtime.

3. Add a compatibility layer

Sometimes the blocker is narrow: the code is mostly fine, but a handful of removed functions or an old database driver stand in the way. Instead of rewriting, we can add a compatibility layer:

• A drop-in replacement for the old mysql_* functions that uses modern, safer database connections underneath, so the rest of the code doesn’t need to change at once.
• Small replacements (polyfills) for removed functions such as ereg() or each().
• Database fixes so the system runs on current MySQL or MariaDB: adjusting SQL modes, renaming clashing columns, converting tables to utf8mb4 safely, and updating the connection method.

This is often what lets a legacy system move to a current, supported server — or a supported PHP version — quickly, with the deeper clean-up done later.

4. Upgrade step by step to a supported version

The long-term goal for most systems is a stable, supported release — today that means PHP 8.x. We don’t jump straight from PHP 5.6 to 8.4. We move through the versions in stages:

1. Copy the live system to a private staging environment, with its real database.
2. Scan the code with automated compatibility checkers to list every function, pattern and library that won’t survive the next version.
3. Fix, test, repeat — one PHP version at a time, checking the key workflows (logins, orders, invoices, reports) after each step.
4. Update or replace dependencies — moving bundled libraries to maintained versions, ideally managed with Composer so they can be updated properly in future.
5. Switch over with a rollback plan, so if anything unexpected appears, the old version is one step away.

Each stage leaves you with a working system, so the project can pause at any point without leaving you worse off. It also fits around a budget: you can stop at “safe and supported” and continue with improvements later.

5. Rebuild — only when it actually makes sense

Occasionally a rebuild is the right call: the business has outgrown what the system does, the code is unmaintainable even after clean-up, or it depends on something that can’t be replaced. When that’s the case, the steps above still matter — they keep the old system safe and running while the new one is built, so there’s no rushed cut-over. See our bespoke development services for new builds.

Choosing the Right Hosting for an Older System

The right environment depends on how old the system is and what it needs around it.

Whichever you choose, it’s fully managed: monitored, backed up and patched by us, in our UK data centres, billed in pounds or rand.

How We Approach a Legacy Project

1. Send us what you’ve got. A server login, a zip file or a repository — undocumented, half-migrated or written by someone who left years ago is fine.
2. Audit. We check the PHP and database versions it needs, what breaks on newer versions, the libraries it uses and known security issues.
3. Fixed quote and a plan. You get a clear picture of the options above and what each would cost, before any work starts.
4. Stabilise first. Move the system to a safe, patched environment and take proper backups, so the urgent risk is dealt with straight away.
5. Improve at your pace. Patch, add compatibility fixes and upgrade in stages — or simply keep it running safely for as long as it’s needed.

Frequently Asked Questions

Is it safe to keep running an old PHP version?

Not on a standard installation — once a version is end of life, new vulnerabilities in it are never fixed. It’s a different story with a hardened build that still receives back-ported security fixes, like the CloudLinux builds every PHP version on our servers uses, running in an isolated account behind a server-level firewall. That doesn’t make the application code itself secure, which is why we recommend an audit as well.

My host is removing the PHP version my site needs. What do I do first?

Don’t wait for the deadline. Take a full backup of the files and database now, then contact us. We can usually move the system to a safe environment on the version it needs before the old host switches it off, and then look at the longer-term fix.

Can you work on a system someone else built?

Yes — that’s most of this kind of work. We regularly pick up systems with no documentation and no original developer. If parts of it are encoded and the vendor no longer exists, we’ll tell you what that means for your options during the audit.

Do I have to upgrade eventually?

Not always. Some internal systems simply need to keep doing the same job until they’re retired, and safe legacy hosting is the right answer for them. For anything public-facing, handling payments or holding personal data, we’d recommend working towards a supported version over time — but on a schedule that suits you.

How long does an upgrade take?

It depends on the size of the code and how far behind it is. A small application may take days; a large system several PHP versions behind may be planned in stages over a few months. The audit gives you a realistic estimate and a fixed quote.

Is this only for PHP?

PHP is our speciality, with over 20 years of experience, but the same approach applies to old WordPress, Joomla, Drupal and Magento installs, WHMCS setups and other systems stuck on old versions. Our development team works at edznet.dev.

Send us your legacy system Bespoke development services