If your application runs on PHP 7.3, 7.4, 8.0 or 8.1, the fixes released on 21 October do not reach it. We move legacy PHP, Laravel, CodeIgniter and CakePHP applications to a supported version at a fixed price, with tests that prove nothing else changed.
About four in ten PHP sites run a version that no longer gets fixes. On 21 October that stopped being an abstract risk: two critical remote code execution bugs were patched for PHP 8.2 and newer only. Anything older has, at best, a source patch that almost no hosting setup can apply. The developers who wrote these apps have moved on, and a modern agency would rather quote a rebuild at ten times the price. We do the unglamorous thing instead: take the application you have, carry it forward release by release, and prove at every step that it still does what it did.
You get a number before any work starts, and it does not change unless you change the scope.
Before we change a line, we write tests that pin how your app behaves today. They stay green on the new runtime.
Every stage ships as a reviewed pull request with a written spec. Your next developer inherits a codebase that explains itself.
Start with the exposure check if you are on PHP 8.1 or older right now. Otherwise start with the assessment. Both are credited against a migration.
We confirm your PHP version and whether CVE-2026-109618 and CVE-2026-109619 reach your application, apply the vendor source patch or a hardening workaround where your hosting allows it, and hand you a fixed quote for the move to a supported version. The stopgap buys weeks, not years; the quote tells you what the real fix costs.
We read your codebase and run the analysis tools, then you get a report: versions, abandoned packages, what breaks on the target, risks, bugs we found on the way, a staged plan, and a fixed quote.
Move from PHP 5.6, 7.x or 8.1 to PHP 8.4 on the framework you have. Removed functions, deprecations, dependency chains, hosting runbook.
Laravel 5 to 11, CodeIgniter 3, CakePHP 2, Zend 1 or raw PHP to current Laravel. Module by module behind a safety net, with the old app running until the final cutover.
Keep-current retainer, from $500 a month. After the migration we keep you on supported versions: framework and PHP updates within 60 days of release, dependency audits, security patches, and the test suite maintained.
You tell us what the app does and what is forcing the move. We tell you whether we can help and what the assessment covers.
Read-only access to the repository. One week later you get the report and a fixed quote, delivered on a second call.
Safety net first, then one stage per framework release. Each stage is a pull request with the tests green. Production stays on the old runtime.
Staging with a copy of your data, a runbook, go-live, and thirty days of fixes. Then the retainer, if you want it.
Before quoting this work to anyone, we did it on our own application: a Laravel 7 and PHP 7.2 CRM back end, moved to Laravel 13 and PHP 8.4 using exactly the process above. Our own assessment had sized it at eight working days.
Eleven files changed to cross six major framework versions, and the only controller edit was one argument to a json_decode call. The test suite, written first, found seven defects nobody knew about in five-year-old production code. Then 38 endpoints compared old against new, side by side, with no unexplained difference.
Composer refuses every release of both, because all of them carry security advisories with no patched version in that line. Nobody can park your application there, even temporarily, so any plan to get you partway now and finish later cannot be delivered. Run composer audit in your project to see where you stand.
These are real assessments, one on a small private CRM back end and one on a public open-source ticketing platform. Read them to see exactly what you would receive.
A lead-tracking back end for medical practices. Three abandoned packages, no tests, and a plain-text password emailed to every new user. Quoted at $6,500 over eight days.
Read the report →An event-ticketing platform with Stripe payments and PDF tickets. 63 views on an abandoned form helper, a 2013-era PDF engine, and a payment error handler that never fires. Quoted at $24,000 over six weeks.
Read the report →If you are on PHP 8.2 or newer, yes: update to the point release and you are done. Below 8.2 there is no package to install. PHP published source patches for 7.4, 8.0 and 8.1, which means compiling PHP yourself on every server, and nothing at all for 7.3 and older. Most hosts will not do that for you. The exposure check applies what can be applied as a stopgap, but the only durable fix is a supported version, and that is the migration.
That is the whole point of the method. Before any change we write tests that capture how the app behaves today, including its quirks, and run them on your current PHP version in a container. Every stage must keep them green. Where there is a real behaviour change, such as a date format in a JSON response, it is listed in the report and you decide.
Yes, and we would be suspicious of anyone who said no in 2026. Mechanical rewrites run through Rector, a rule-based tool. The judgement work, untangling a two-thousand-line controller or replacing a dead package, is done with an AI coding agent working under a written spec, and a senior engineer reviews every change. The tests, not the tools, are the guarantee. That is also why the price is lower than a traditional agency's.
The assessment checks whether your host offers the target PHP version. If it does not, the plan includes a Docker image or a move to a host that does. Hosting migration itself is quoted separately.
Yes. Everything happens on branches and a staging copy. Production stays on the old runtime until the cutover stage, which you schedule.
Then the report says so, with reasons, and you keep the assessment. It happens, usually when the data model no longer matches the business. You are not obliged to order anything after it.
We work from the repository, not production data, and scrub credentials and fixtures before any analysis. If a staging copy of the database is needed for cutover, it stays on your infrastructure. A short data-handling clause is part of the agreement.
keepPhpUp is a specialist practice with fifteen years of building and maintaining PHP and Laravel applications in production. Every engagement has a single senior engineer accountable for it from assessment to cutover, not a rotating team you never meet.
We work to a spec-driven method: each unit of work has a written specification, a verification checklist and a test. That is what makes a fixed price possible, and it is why the handover explains itself.
We are deliberately narrow. We do not build new products or redesign interfaces. We keep working software working.
Founded by Mel Valencia.
One email with the PHP version, the framework, and roughly how big the application is. If you are exposed, you will hear back the same day with what the exposure check covers. If you are not, we will say so.
melchor@keepphpup.com