PHP Upgrade & Migration
Upgrade Your PHP Application Without Starting Over
From urgent patch assessments to legacy PHP and Laravel migrations, we help teams assess compatibility, plan the upgrade and move toward a supported production environment.
We work with teams in the US and Canada that run custom PHP applications, Laravel backends and WordPress sites with custom plugins. Our engineers work from our office in Noida, India, and the first step is a 30-minute technical discovery call with an engineer.
PHP 8.2 upstream security support ends December 31, 2026. The button opens a short form; please do not send passwords or server credentials through it.
At a glance
PHP Upgrade & Migration at a Glance
| What's delivered | Security patch assessments, compatibility reviews, staged PHP and framework upgrades, regression testing, production release planning and ongoing maintenance |
|---|---|
| Engagement model | Fixed-scope projects, monthly retainers, or a combination, agreed after the discovery call |
| How it starts | A 30-minute technical discovery call with an engineer |
| Pricing | Pricing is scoped per project after the discovery call. |
| Related case studies | None published yet. Browse all case studies |
What we build
What Does Peregrine's PHP Upgrade & Migration Service Include?
Peregrine's PHP upgrade and migration service covers three kinds of work: assessing an urgent security patch against your runtime and hosting, moving a legacy PHP, Laravel or WordPress application to a supported PHP release in controlled steps, and maintaining the runtime, dependencies and release process once the application is current.
Urgent security patch assessment
We identify which PHP versions and builds are running and where, and the deployment constraints around them. We check whether your host or Linux distribution has shipped a patched package and whether the application works on it, then plan a safe remediation and retest after it is applied.
Legacy PHP application migration
We inventory the PHP version, framework and every Composer package or plugin, identify deprecated APIs, removed functions and unsupported packages, and move the application to a supported release in controlled steps, each tested and released on its own.
Ongoing maintenance
A plan for runtime and dependency updates, coordination of security patches with your host or infrastructure team, and the monitoring, automated tests and release support that make each update routine.
Industries: All industries
What we modernize
What Kinds of PHP Systems We Modernize
- Custom PHP applications
- Plain PHP codebases, often written before Composer or a framework was in place, that rely on functions and behavior newer PHP versions have deprecated or removed.
- Laravel backends and SaaS products
- Applications several Laravel versions behind, where the framework, its packages and the PHP version have to move together. Our Laravel upgrade checklist sets out the phases.
- WordPress with custom plugins
- Sites where WordPress core is current but custom or abandoned plugins and themes have not been tested on a newer PHP version.
- PHP APIs and integrations
- Backends that serve mobile apps, partners or webhooks, where a runtime change must not alter the responses other systems depend on.
- Business portals and internal platforms
- Customer portals, admin tools and back-office systems that staff use every day, where any maintenance window has to be planned and short.
- Legacy systems with complex dependencies
- Applications tied to particular PHP extensions, old database drivers, a specific server image or vendor SDKs that have not kept up. Here the dependency map is the first deliverable.
For CTOs and founders
Why Not Just Change the PHP Version?
On most hosts, switching PHP versions is a menu option or one package change. The hard part is what it does to the application: the runtime sits under every library, extension and integration you use, and each has its own compatibility range. These are the areas we check before production is switched.
- Composer dependencies
- Each package declares the PHP versions it supports. An old lock file can block the new version, or install cleanly and fail at runtime.
- Framework constraints
- Laravel, Symfony and other frameworks each support a range of PHP versions, so the framework may have to move first or in step.
- Removed and changed functions
- Functions deprecated in one release are removed in a later one, and stricter type handling turns old warnings into errors.
- Extensions
- Every extension the code relies on has to be available, and maintained, for the new version on the target server.
- Sessions and authentication
- Session handlers, serialization settings, cookies and password hashing are where users notice a regression first.
- Database drivers
- Older drivers and connection options may be missing or behave differently on a newer runtime.
- Payments and third-party APIs
- Payment SDKs and vendor API clients have their own PHP requirements, and a change in HTTP client behavior can break a call that worked before.
- Queues and cron jobs
- Workers and scheduled jobs often run under a different PHP binary or configuration from the web server, and are easy to miss.
- Web server configuration
- PHP-FPM pools, Apache modules, Nginx settings and php.ini values have to be carried across and reviewed.
- Regression risk
- Without tests, the first sign of a broken path is often a customer report. Tests around the critical paths come before the switch.
None of this means an upgrade has to be large. It means the work starts with an inventory, so the size of the job is known before production is touched.
PHP support status
Which PHP Versions Are Still Supported?
The PHP project publishes the support window of each branch on its supported versions page. As shown there on October 27, 2026:
| PHP branch | Active support until | Security support until | Status on October 27, 2026 |
|---|---|---|---|
| 8.5 | December 31, 2027 | December 31, 2029 | Active support |
| 8.4 | December 31, 2026 | December 31, 2028 | Active support |
| 8.3 | December 31, 2025 | December 31, 2027 | Security fixes only |
| 8.2 | December 31, 2024 | December 31, 2026 | Security fixes only. Upcoming: security support ends December 31, 2026 |
PHP 8.2 is still supported today, and it received the October 21, 2026 security fixes in PHP 8.2.35. After December 31, 2026 the PHP project stops publishing security releases for it, so an application on 8.2 needs a plan for the move; our PHP 8.2 end-of-life upgrade guide compares 8.3, 8.4 and 8.5 as targets. PHP 8.6 is still a release candidate, not a production release, and PHP 8.1 and older no longer receive updates from the PHP project.
For the October 2026 security releases, which versions are patched and what to check first, read our PHP2Shell guide.
Dates read from php.net on October 27, 2026. The page changes with each release, so check it again before planning.
Timeline
How Long Does a PHP Upgrade & Migration Project Take?
Peregrine does not quote a timeline before the inventory, because two applications on the same PHP version can need very different amounts of work. An urgent patch assessment is scoped to the patch. A migration is planned in steps that can each be released on their own, and larger work runs in two-week sprints with weekly demos.
Inventory what is running
Record the PHP version and build on every server, container and worker, plus the web server, extensions, framework, and Composer or plugin versions. For example, production on PHP-FPM, a queue worker on a different image, and a cron server nobody has listed.
Check advisories, support status and compatibility
Compare those versions with the PHP project's security releases and support dates, your host's or distribution's package status, and the PHP range each framework and package supports.
Map the blockers
List what stops the move: framework constraints, missing or unmaintained extensions, packages with no compatible release, and code that uses removed functions. For example, an abandoned PDF library or a plugin last updated for PHP 7.
Prepare a safe path
Add regression tests around the critical paths, confirm backups can be restored, set up a staging environment that matches production, and write down how each step is rolled back.
Patch or migrate in controlled steps
Apply the patched runtime, or move one version and one group of dependencies at a time, releasing each step through staging before production.
Validate and set up maintenance
Check the critical paths in production, watch error logs and monitoring, then agree how future PHP and dependency updates are planned and released.
Upgrade or migrate
Upgrade or Migrate?
The right first move depends on where the application stands today. This table shows how we would usually start in common situations. It is an aid for the conversation, not a prescription: the inventory of your system decides.
| Situation | Likely first action | Longer-term direction | What needs investigation |
|---|---|---|---|
| Supported PHP branch with a patch available | Apply the patched release, or your host's or distribution's patched package, after a check in staging | Keep to a regular update schedule and plan the next branch before support ends | Whether the package you run includes the fix: vendor version numbers can differ from upstream ones |
| Older release with vendor backports | Apply the vendor's backported package and confirm it covers the specific advisories | Move to a branch the PHP project still supports | What the backports cover and for how long |
| End-of-life PHP with no suitable supported patch | Reduce exposure: restrict or isolate the system, or take it offline until it is fixed, as CISA and the UK NCSC advise for systems that cannot be updated | Migrate to a supported PHP version, in stages if the code is far behind | Which code, extensions and packages block the move |
| Legacy Laravel with abandoned dependencies | Find which packages block the next Laravel and PHP version, and their replacements | Upgrade in place one major version at a time, or replace parts in stages | Test coverage, changes made to framework code, and what each abandoned package does |
| Custom PHP without reliable tests | Write tests around the critical paths before changing the runtime | Upgrade in steps, refactoring where the code is being changed anyway | Which paths matter most to the business, and which code uses removed or changed functions |
| WordPress with incompatible themes or plugins | List each theme and plugin with its tested PHP range, and run the site on the target version in staging | Update, replace or rewrite what blocks the move, then keep core, plugins and PHP on a schedule | Custom plugin code, abandoned plugins and the PHP versions your host offers |
Typical starting points only. What applies to your application depends on what the inventory finds.
Published guidance
What the PHP, Laravel and WordPress Projects Publish
The version facts on this page come from the projects themselves. Each item links to its source, read on October 27, 2026.
Cost
What Does PHP Upgrade & Migration Cost?
Peregrine takes on PHP upgrades as fixed-scope projects, monthly retainers, or a combination, agreed after the discovery call. Cost depends on how far behind the versions are, the packages, plugins and integrations involved, and existing tests. We publish no price list. For the framework side, read Laravel Upgrade and Modernization Checklist: Upgrade in Place, Replace in Stages or Rewrite.
Laravel Upgrade and Modernization Checklist: Upgrade in Place, Replace in Stages or Rewrite
A phase-by-phase Laravel upgrade checklist from the official support policy and upgrade guides, plus a decision table: upgrade, replace in stages or rewrite.
Read the guidePHP2Shell in 2026: Vulnerabilities, Patched Versions & What Website Owners Should Do
The October 2026 PHP security releases: the two CVEs, which PHP versions are patched, and what WordPress, Laravel and custom PHP site owners should check.
Read the guideGetting started
How Does a PHP Upgrade & Migration Project Start?
A Peregrine PHP Upgrade & Migration project starts with a 30-minute technical discovery call with an engineer, not a salesperson. Larger builds then begin with a discovery sprint that maps requirements, designs the architecture and produces a written technical plan. Smaller, well-defined tasks can use the quick project form for a scoped estimate.
Engagement options
Ways to Work With Us on a PHP Upgrade
- Security and upgrade assessment
- A scoped review of the runtime, hosting, dependencies and code, ending in written findings: what is exposed, what blocks an upgrade and the order in which to fix it.
- Defined migration project
- An agreed move to a supported PHP version, and framework version where needed, delivered in tested steps with a rollback plan for each release.
- Ongoing maintenance
- Runtime and dependency updates, security patch coordination and release support after the application is current.
Engagements are fixed-scope projects, monthly retainers, or a combination, agreed after the discovery call. The first step is a 30-minute technical discovery call with an engineer.
Before the call
What to Send Us
Send whatever you know. Incomplete is fine: anything missing becomes the first item on the call.
- The website or application URL
- The PHP version, if you know it
- The framework or CMS and its version, for example Laravel 10 or WordPress
- Where it is hosted: shared hosting, a managed host, a VPS or a cloud provider
- Whether a staging environment exists that we could use later
- Known issues, errors or updates that are blocked
- Any deadline, such as a support end date or a notice from your host
Please do not send passwords, server credentials or code through the form. Access is arranged securely after the scope is agreed.
Case studies
Which Case Studies Show Peregrine's PHP Upgrade & Migration Work?
Peregrine has not published a PHP upgrade case study, so this page makes no project claims about PHP work. Every published case study lists Node.js in its stack. Ask about your PHP version, framework and hosting on the discovery call, and an engineer will tell you plainly whether we are the right team.
Stack
Technology We Use
Related services
Services Often Scoped With PHP Upgrade & Migration
FAQ
Frequently Asked Questions
Can you upgrade an application from PHP 5 or PHP 7?
Yes, though usually not in one jump. Code written for PHP 5 or 7 often uses functions and behavior that later versions removed or changed, and its packages may have no release for current PHP. We inventory what blocks each step, add tests around the critical paths, and move in stages to a version the PHP project still supports.
Do we have to rewrite our Laravel application?
Usually not. Most Laravel applications can be upgraded in place, one major version at a time, with tests written first. Replacing parts in stages makes sense when abandoned packages or heavily modified framework code block every step. A full rewrite is the riskiest route and the last resort.
Can you patch a security issue without rebuilding the application?
Often, yes. If your PHP branch is still supported, the fix is a patched PHP release or your host's or distribution's patched package, checked against the application in staging first. Applying a runtime patch does not require a rebuild. The harder case is an end-of-life PHP version with no patch, where reducing exposure and a migration plan come first.
How do you avoid breaking production?
By keeping every change small, tested and reversible: regression tests around the critical paths, a staging environment that matches production, backups that have been restored, a written rollback plan, and releases in steps. We check the critical paths again in production after each release. No upgrade is free of risk, so the plan is built to catch problems early.
Is PHP 8.2 safe to keep using until December 31, 2026?
PHP 8.2 is in security-only support until December 31, 2026, according to php.net, and it received the October 21, 2026 security fixes in PHP 8.2.35. Running the patched 8.2 release is reasonable for now, but after that date the PHP project stops publishing security fixes for 8.2, so plan the move to a newer branch.
Should we move to PHP 8.4 or PHP 8.5?
It depends on what your framework, extensions, plugins and host support. According to Laravel's release notes, Laravel 12 supports PHP 8.2 to 8.5 and Laravel 13 supports 8.3 to 8.5, and WordPress recommends PHP 8.3 or greater. We choose the newest version that every part of your stack supports, not the newest version for its own sake.
Will our WordPress plugins and theme work on a newer PHP version?
WordPress itself recommends PHP 8.3 or greater, but each plugin and theme has its own compatibility. We list them with the PHP versions they are tested on, run the site on the target version in staging, and update, replace or fix whatever breaks before production is switched.
How is a PHP upgrade estimated?
From the inventory: how far behind the PHP and framework versions are, how many packages, plugins and extensions are involved, how much of the code is covered by tests, and how hosting and deployment work. The scope is agreed after the discovery call as a fixed-scope project, a monthly retainer or a combination. We do not publish a price list.
Can we keep our current host?
Often, yes, if the host offers a supported PHP version and lets you choose it. Some shared hosts limit versions or extensions, and managed hosts may patch PHP on their own schedule, so we check what yours supports first. If the host cannot run a supported version, moving is part of the plan and is agreed with you.
Who owns the IP rights to what Peregrine builds?
You do. Once the work is paid for, the client owns the intellectual property (IP) rights to what Peregrine builds for the project, whether it is delivered as a fixed-scope project, a monthly retainer or a combination of the two.
Questions about the team, contract models and how progress is shown are answered on the services page.
Technical consultation
Planning a PHP Upgrade or Concerned About an Existing Application?
Tell us what you're running. We'll discuss the risks, compatibility requirements and a practical upgrade path.
- A 30-minute technical discovery call with an engineer, not a salesperson.
- Fixed-scope projects, monthly retainers, or a combination, agreed after the call.
- Small, well-defined tasks get a scoped estimate. We reply within 1 business day.
Prefer to pick a time? Book a call on Calendly
