Old PHP application modernisation
Most old PHP business systems Solve With Software takes over are on PHP 5 or 7, both long out of support, on a framework that stopped being maintained and hosting that was set up by someone who has left. Only PHP 8.2 to 8.5 are supported in September 2026, and 8.2 ends on 31 December 2026. We take the code over, get it running on a supported PHP version on hosting you control, and then modernise it in stages, keeping the rules and the data throughout.
Free · 1 hour · no obligation
Where old PHP stands
PHP itself is healthy. The problem is which PHP. In September 2026 the supported versions are 8.2, 8.3, 8.4 and 8.5, and 8.2 reaches end of life on 31 December 2026. PHP 8.1 ended last December. PHP 7 ended in 2022. PHP 5 ended in 2018, and a surprising number of business systems still run on it, because the hosting provider never forced the change and the application never broke.
Each major version removed things the old code relied on. The move from 5 to 7 took away the original MySQL extension that half of PHP 5 code used for every query. The move to 8 tightened types and errors so that code which used to limp along now stops. That's why an old PHP system can't simply be moved to a new server: the server's PHP is the new one, and the code isn't.
What we usually find
One of four shapes:
- A framework of its era. CodeIgniter 2 or 3, CakePHP 2, Zend Framework 1, Symfony 1, or an early Laravel. Some of these have modern successors; some don't.
- A framework the developer wrote. Their own router, their own database layer, their own templating. Readable, usually, and entirely dependent on conventions that lived in their head.
- A WordPress site that became the system. Plugins and custom code holding orders, members or bookings, on a WordPress that can't be updated because the custom code would break.
- Plain PHP. Files that mix HTML, logic and SQL, one per page, from the days when that's how it was done.
Under all four there's usually MySQL with a sound data model, hosting on a shared server or a single VPS with no staging environment, FTP deployment, and no source control. The rules are in there. They're just tangled up with everything else.
The paths
Get it onto supported PHP, as it is. Take the code into source control, stand it up on a test server running a current PHP, and fix what breaks: removed extensions, changed behaviour, deprecated syntax. For plain PHP and self-written frameworks this is often a contained piece of work, and it takes the system off the end-of-life list without changing what users see. It's the first stage whatever follows.
Modernise in stages onto a maintained framework. Usually Laravel. The data model stays; the rules move across one process at a time into a proper structure with tests, with the old application running alongside on the same database until each process has moved. The right path when the business still wants the system and wants to keep changing it.
Replace. When the data model is the problem or the business has changed shape. Even then, alongside, with the data shared until the new system has proven itself.
The assessment reads the code and prices each path as a fixed number.
Hosting and the things nobody remembers
Old PHP systems live in odd places: a shared hosting account in the founder's name, a VPS nobody has logged into since 2020, a server at the old developer's office. Part of the takeover is finding where it runs, who owns the account, whether there's a backup, and moving it to hosting you control, with a staging environment beside it so nothing is ever tested on live again. The domain, the DNS, the email and the SSL certificate are on the same list.
Your data
Usually MySQL, and it comes with you unchanged. Old and new run against the same database throughout a staged modernisation. Any change to the schema is tested on a copy, then in staging with the data reconciled, before anything connects to live, and the old application stays available as a fallback until you're confident.
What it costs
The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a PHP system it stands the code up on a supported PHP in a test environment to see what breaks, maps the rules and the hosting, and prices each path as a fixed number. What drives the price and the payment terms each have a page.
The risks of waiting
An unpatched language runtime on a public web server. That's the risk with PHP 5 and 7, and it's the one insurers and Cyber Essentials assessors ask about. After that: a hosting provider that upgrades PHP without asking and takes the site down, a framework with a published vulnerability and no fix, and the plain fact that PHP 5 developers are as rare as VB6 ones.
How we approach it
Source control, a supported PHP and hosting you own first; then stages. Marc Allington has taken over PHP systems of all four shapes above and builds on Laravel now. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.
The technical checklist for a PHP takeover
| Check | Why it matters |
|---|---|
| PHP version in production, and what a current version does to the code | The end-of-life status, and the size of the first stage. |
| Framework and version, and whether it's still maintained | Decides between fixing in place and moving to a maintained one. |
| Database extension in use: mysql, mysqli, PDO | The original mysql extension is gone from PHP 7 onwards; every query using it has to change. |
| Where it's hosted, who owns the account, and is there a backup that restores? | The account is often in someone else's name; the backup is often assumed. |
| Deployment: FTP, git, something else | FTP means no history and no rollback. Source control is the first job. |
| Where the rules live: framework code, plain pages, database | Sets how much has to be read before any process can move. |
| Integrations and cron jobs | Payment gateways, email, scheduled tasks, all with credentials in someone's old inbox. |
| Domain, DNS, SSL, email | Part of ownership, and often split across three providers. |
Each answer goes into the report with its stage and a fixed price.
Questions
What people ask before they book.
Can't the host just upgrade PHP?
They can, and it will break the site. Old code relies on things newer PHP removed. The fix is to stand the code up on a current PHP in a test environment first, fix what breaks, then move. That's the first stage.
Our system is built on WordPress. Is that different?
The shape is different, the job is the same. Custom plugins and theme code hold the rules, and they're what stops WordPress being updated. The assessment reads them and prices either fixing them in place or moving the business logic out into a system of its own.
Do we have to move to Laravel?
No. Getting onto supported PHP as it is can be the whole answer for a while. Laravel is where we'd take a system the business wants to keep changing, because it brings structure and tests. The assessment recommends one from the code.
We don't have the hosting login. Can you still help?
Usually. The code can often be recovered from the running site, an old backup or the developer's repository, and the domain is recoverable through the registrar. Finding where everything is and who owns it is part of the assessment.
How long does it take?
It depends on how much the code fights a current PHP and how tangled the rules are, which the assessment measures. The shape is the usual one: supported PHP on hosting you own within about six weeks, then stages, each priced before you commit.
Start with a free consultation
An hour on your system, online or by phone. From there we size the assessment, from £395 + VAT, and give you an exact price before you commit.
Want the numbers first? See how pricing works.
Written by Marc Allington, founder. .