How to keep an old PHP 5 or PHP 7 website online safely in 2026

Keeping an old PHP website online safely has less to do with the code than with what surrounds it. Separate the old application from everything else. Keep everything that is not the old application completely current. Shrink both what the site can reach and what can reach it.

Done properly, an old PHP 5 or PHP 7 site becomes a contained thing with a small blast radius rather than a soft spot on a busy shared server. This is the engineering side of it, written out so you can either do it yourself or ask a host to prove they already have.

Old PHP does not mean an old server

This is the point most people miss, and it is the one that does most of the work.

PHP is one component. The operating system, the web server, the TLS library, the database and every other package on the machine have their own release cycles. There is no technical reason a site running PHP 5.6 needs a 2015 operating system underneath it. Frozen application, current everything else, is what a decent legacy setup looks like.

The web server in front matters most. When a current nginx or Apache handles the connection, it is the modern software that speaks TLS to the internet, negotiates the ciphers, deals with the certificate and parses the incoming request. Your old PHP never touches the network directly. It receives a request that has already been through a properly maintained front door.

So the first question for a host offering to keep your old site running is not about PHP at all. Ask what the operating system is and when it was last patched. If the whole machine is as old as the site, walk away.

One site, one user, no neighbours

The nightmare with old code on ordinary shared hosting is not really the old code. It is the company it keeps: hundreds of accounts on one machine, files often readable across accounts, and PHP processes running as the same user for everybody. One compromised site becomes everybody’s problem, and the site running unpatched code is the one that gets picked first.

Containment means the old site runs as its own system user, in its own PHP process pool, restricted with open_basedir so the code cannot read its way out of its own directory, and without other customers sharing the machine in a way that lets anything cross over. On a site with real value attached, its own container or its own small server is cleaner still, and it makes rolling the whole thing back to a known-good state a five minute job instead of an evening.

The test to apply: if this site were fully compromised tomorrow, what else does the attacker now have? On a well-arranged legacy setup the honest answer is “that site and nothing else”. On cheap shared hosting nobody can tell you.

Take away what the code never uses

Most old PHP applications use a fraction of what PHP can do. The rest is capability sitting there for someone else’s benefit.

• Switch off the functions that run system commands unless the application genuinely needs them. Most brochure sites and plenty of bespoke systems never call one.
• Stop PHP fetching and including files from remote addresses. Old code rarely wants this and injected code almost always does.
• Make the upload directory unable to execute PHP at the web server level. A file that gets uploaded is then just a file rather than a way in.
• Give the code the narrowest write permissions that let it work. Plenty of old sites are running with everything writable because that was the quickest way to make something save ten years ago.
• Delete the leftovers. Old installers, a copy of phpMyAdmin somebody dropped in, backup zips in the web root, a folder called old or test. These turn up constantly and every one of them is reachable.

If the site is genuinely finished and only exists to be read, consider making the whole file tree read-only and giving the database user select rights and nothing more. An archive that cannot change cannot be changed by anyone else either.

Watch the traffic going out

Filtering incoming traffic is the part everybody thinks about. A web application firewall in front of an old site is worth having, and we put one there as standard, but it is pattern matching and it will not catch everything aimed at code nobody has patched in years.

The other direction is where old sites betray themselves. Once something has got in, almost everything it wants to do involves the server making outbound connections: sending spam, calling home for instructions, mining, or being rented out as a relay. A legacy site that should only ever talk to a payment gateway and a courier API has no business connecting anywhere else, and limiting where it can reach turns a compromise into a nuisance rather than a disaster.

Alongside that, keep an eye on the files. Old PHP applications change rarely, which is a gift: a monitor that alerts on any PHP file appearing or changing when nobody deployed anything will spot an injected shell long before a customer does. On a WordPress site that alert would be noise. On a bespoke system last touched in 2014 it is nearly always real.

Give the database its own limits

Old code and SQL injection go together, so assume some of the queries in there are less careful than they should be and limit what a successful injection could do.

The application’s database user needs to read and write rows. It very seldom needs to create or drop tables, and it certainly does not need permission to read files from disk. Old sites routinely connect with an account that has every privilege going, because whoever set it up in 2011 used the root credentials and it worked. Cutting that account back is an hour’s work and removes a whole category of outcome.

Keep the database itself on a current version, and check the site still behaves after it moves, because newer releases are stricter about the sloppy queries old applications are full of.

Hold a copy you own

Backups need to live somewhere the site cannot reach, with enough history to go back past a compromise nobody spotted for a fortnight. That much is standard.

The legacy-specific job is different, and hardly anybody has done it. Get the source code into your own hands, in version control, with a written note of the PHP version it needs, the database version, the extensions it depends on, which cron jobs run and what every external service it talks to is called. On an old bespoke system that information usually lives in one person’s head, and that person left in 2019.

Do that and you own the site instead of renting it from circumstance. You can move hosts, get a quote from a different developer, or rebuild it, none of which is possible when the only complete copy is the one running on a server you cannot log into.

The jobs no host can do for you

We can isolate it, patch around it, watch it and back it up. The rest stays yours.

• Deciding what data the site should still be holding. Ten years of customer records in an old database is ten years of liability, and deleting what you no longer need is the cheapest security work available.
• Turning off features nobody uses. Old sites accumulate forms, exports and login areas that have not been touched in years and still work perfectly for anyone who finds them.
• Auditing who has an account. Former staff, former developers, former agencies.
• Keeping card details off the box, by using a gateway’s hosted payment page rather than any code of your own.

When we would tell you no

Better said out loud than left for someone to assume. If a site is already compromised, it gets cleaned before it moves, not after. If it stores card numbers in its own database, that stops before anything else happens. And if a system holds sensitive personal data and the code cannot be contained enough to sit behind these arrangements comfortably, we will say the risk is too high and talk to you about replacing it instead. Weighing what the system holds against what it earns is the exercise that usually settles which side of that line a site falls on.

Everything else, we can generally take. Our legacy PHP hosting exists because old sites get abandoned by hosting companies long before they get abandoned by the businesses running on them, and an old OpenCart shop falls under the same arrangement, with the shop-specific jobs written up on their own page.

Old PHP hosting FAQs

Let us look at the site first

Send the web address and whatever you know about the code, and you will hear what containing it would involve and what it would cost, before you commit to anything. Ring 01623 650 333 and there is a person on the end of it, weekends included. The bottom of our range is £1 a day + VAT, and a contained legacy setup is priced on what it actually takes to contain it.