We move legacy PHP applications from PHP 5 and 7 to PHP 8.5, the current release, together with the frameworks and libraries underneath, and keep them ready for 8.6. Step by step, covered by tests, while your business keeps running.
30-minute call. You leave with a risk read-out and a ballpark price.
No security fixes since 31 Dec 2018.
Almost eight years of PHP vulnerabilities that will never be patched, plus a framework and libraries just as old.
We have upgraded apps from PHP 5.6 before. We go in stages through 7.4 to PHP 8.5.
No security fixes since 2019–2021.
Five years or more without patches, depending on the exact version.
A well-trodden path: through 7.4 to PHP 8.5, without stopping the business.
No security fixes since 28 Nov 2022.
Almost four years of known holes. Many libraries have already dropped 7.4 too.
The jump to PHP 8 is the hardest one. It is also the one we do most often.
No security fixes since 26 Nov 2023.
Close to three years without patches, despite feeling modern.
Usually a short, low-risk project to PHP 8.5.
Security fixes ended 31 Dec 2025.
Ten months without patches, and the list grows with every PHP release.
Usually a short, low-risk project to PHP 8.5.
Security fixes end 31 Dec 2026.
About ten weeks left. After that, 8.2 is in the same position as 7.4.
Plan the move to 8.5 now, while it is calm.
Supported until Dec 2027 (8.3) to Dec 2029 (8.5).
You are current. Your framework and libraries may not be: worth a check.
Our stay-current plan keeps you here with one small step a year.
Dates from the official PHP supported-versions schedule (php.net).
PHP support timeline
Every PHP release gets two years of bug fixes and two of security fixes. After that, the PHP team stops patching it, and so does everyone who builds on it. PHP 8.2 joins the unsupported list on 31 December 2026.
| 5.6 | Ended 31 Dec 2018 | |
|---|---|---|
| 7.0 | Ended 10 Jan 2019 | |
| 7.1 | Ended 1 Dec 2019 | |
| 7.2 | Ended 30 Nov 2020 | |
| 7.3 | Ended 6 Dec 2021 | |
| 7.4 | Ended 28 Nov 2022 | |
| 8.0 | Ended 26 Nov 2023 | |
| 8.1 | Ended 31 Dec 2025 | |
| 8.2 | Ends 31 Dec 2026 | |
| 8.3 | Until 31 Dec 2027 | |
| 8.4 | Until 31 Dec 2028 | |
| 8.5 | Until 31 Dec 2029 |
Security
Security holes keep being found in old PHP versions after support ends. They are fixed only in supported branches, so yours stays exposed. And the runtime is rarely the only layer that has gone stale.
New CVEs in PHP core, its extensions and bundled libraries never reach end-of-life versions. Attackers know exactly which versions those are.
Old PHP pins you to old Composer packages, many with published vulnerabilities. You can’t update them until PHP itself is upgraded.
Symfony 2–4, Laravel 5–10, Zend Framework, CodeIgniter 2 and CakePHP 2 get no security releases either. Neither do their plugins.
SQL built by string concatenation, MD5 passwords, unserialize() on user input, homemade CSRF. Common in older code, and easy to exploit.
mcrypt, old OpenSSL and old cURL builds fall behind modern TLS. Payment gateways and APIs eventually stop accepting the connection.
Old PHP usually means an old operating system, also out of support. One stuck layer keeps the whole server stuck.
An upgrade opens every file anyway. We use that to close the holes the audit found, so you finish with more than a new version number.
Compliance
“Unsupported software in production” is one of the easiest findings to write up and one of the hardest to explain away. An upgrade turns it into a closed item, with evidence.
Personal data must be protected with measures appropriate to the risk and the state of the art. Software with no security fixes is hard to defend to a regulator after a breach.
Essential and important entities must manage vulnerabilities and the security of their suppliers. If you build or run software for one, expect them to ask you.
Req. 6.3.3 wants critical patches within a month of release; 12.3.4 wants a plan for end-of-life technology. Neither works on a PHP version that gets no patches.
Both expect known vulnerabilities to be identified and fixed in time. An end-of-life runtime shows up as a nonconformity or an exception you have to justify every year.
Underwriters ask whether you run unsupported software. The honest answer can raise the premium, and a breach through known end-of-life software can complicate a claim.
Larger customers send security questionnaires before they sign. “PHP 7.4” in your answers is enough to slow a deal down, or end it.
We’re engineers, not lawyers. What we hand over is evidence: a before-and-after version and dependency report, the vulnerability audit and a change log your compliance lead or auditor can file.
Ask about an audit-ready upgrade →Beyond security
PHP 8 runs typical web code markedly faster than PHP 5 and 7. We benchmark your app before and after, so you see your own numbers.
Hosts and cloud platforms retire old PHP versions or charge extra to keep them alive. Upgrade when you plan to, not when they force you.
Good PHP developers want modern PHP. Legacy code shrinks your hiring pool and raises the price of every change.
Current payment, email and API SDKs need PHP 8.1 or newer. On old PHP you write workarounds instead of features.
Types, enums, readonly properties and static analysis catch mistakes before your users do. Changes get cheaper, not riskier.
Once you’re current, staying current is routine: a small version bump each year instead of another rescue.
If two or more of these are true, the upgrade is already overdue. The good news: it is a solved problem, and we have solved it many times.
Talk to an engineerHow we upgrade
The same six steps, refined over many upgrades. Each one ends with something you can see and keep.
We map PHP and framework versions, extensions, dependencies and known CVEs, run static analysis and mark the risky corners of the code.
You get: a written report, an upgrade path and a fixed price.
Before touching code we wrap the flows that make you money in tests: login, checkout, billing, reports. Plus CI and a staging copy of production.
You get: a test suite that stays with the app.
Version by version, with automated refactoring and line-by-line review. The framework and libraries move with PHP. Your team keeps shipping.
You get: small pull requests you can review.
We close the security issues the audit found: queries, passwords, sessions, headers, secrets and dependencies.
You get: a security change log for your auditor.
The new version runs side by side with the old one, then traffic switches over with a tested rollback plan. Zero downtime is the default, not an extra.
You get: a quiet launch day.
Optional care plan: monitoring, security patches and the yearly minor upgrade, so this never turns into a project again.
You get: a supported app, permanently.
Upgrade or rewrite?
Your old code holds years of business rules and fixed edge cases. A rewrite throws that knowledge away and asks you to rediscover it in production.
| Incremental upgrade · our default | Full rewrite | |
|---|---|---|
| Business logic | Kept, edge cases included | Rediscovered, often the hard way |
| New features meanwhile | Keep shipping | Usually frozen |
| Risk | Small steps, each reversible | One big switchover |
| First security win | With the first release | At the very end |
| Cost | You pay for what changes | You pay to rebuild what you already own |
Sometimes rewriting one part is the right call: a module nobody understands, or a front end past saving. If so, the audit says it plainly, with reasons and a price for both options.
Experience
Every user login depended on mcrypt encryption, which PHP removed in 7.2. Re-encrypting the stored data would have meant a maintenance window and no way back. We replaced it with a supported method that reads and writes the exact same format, proven byte for byte by tests.
Result: ~200 compatibility issues down to 0 errors. No database migration, no downtime, no password resets, rollback-safe.
A legacy CakePHP 2 app and a modern Symfony 7 app running side by side, serving French and Spanish learners. Upgraded version by version while the product kept shipping new features.
Result: when a critical PHP remote-code-execution flaw was published in October 2026, production was patched and hardened the same day.
An old CakePHP app controlled how network devices behave, and was sold to large corporations. It no longer met their corporate software standards. Here the audit pointed to a full rebuild on modern PHP and current coding standards.
Result: corporate-grade software again: compliant with client standards, hardened for security and faster in use.
“Axart has been crucial to the development of our (very complex) site. They always find an easy solution to projects that we assumed would be much harder.”
Ways to start
Free
30 minutes. Tell us what you run; leave with a risk read-out and a ballpark.
Quoted per app
Full inventory, CVE scan, static analysis, upgrade path and a fixed quote. The report is yours, even if someone else does the work.
Fixed price
Scope and price come from the audit. Delivered in stages, released with zero downtime.
Quoted per app
Monitoring, security patches and the yearly upgrade, handled before anyone has to ask.
FAQ
No. The upgraded version runs next to the old one until it has proven itself, then traffic switches over. If anything looks wrong, we switch back in minutes.
No. We upgrade in small, mergeable steps alongside your normal work, and agree with your team how the two streams meet.
That describes most of the apps we upgrade. Adding a safety net of tests is step two of the process for exactly this reason.
No. We go in stages through PHP 7.4 to PHP 8.5, keeping the app working at every stop. It’s more work than from 7.4, not a different kind of work.
It depends on the size of the code, how far behind it is and how many libraries need replacing. The audit answers it with a fixed scope and price, so there are no open-ended invoices.
Yes. Some clients want us to do it all, others want the plan, the tooling and a reviewer. The audit report works for both.
We can move you to a fresh, supported server or containers as part of the release, or hand a clear spec to your hosting team.
Tell us your PHP version and framework. We reply within one business day.
