How to migrate from PHP 5 to PHP 8
Migrating PHP 5 to PHP 8 requires four steps in order: establish a test baseline (PHP 5 tests must run green before any change), upgrade Composer dependencies to versions that support PHP 8, fix the breaking-change list (mysql_* removed, ext-mcrypt removed, strict-type enforcement tightened, deprecated functions removed), and re-baseline the deployment pipeline. Most migrations take 8 to 16 weeks. Rewriting from scratch is almost never the right answer.
The longer answer
PHP 5 to PHP 8 is the largest PHP version migration of the last decade. PHP 5.6 reached end-of-life in December 2018; codebases still running on it in 2026 are accumulating substantial security debt. The migration is well-documented, low-risk when done in the right order, and almost always cheaper than the rewrite-from-scratch alternative.
Step 1: Establish a test baseline (1-3 weeks)
Before changing any code, get the existing PHP 5 codebase running green tests. If there are no tests, write smoke tests against the critical paths first — you cannot migrate safely without something that signals when migration breaks behavior. Use PHPUnit if the codebase already has it; install a current version that supports PHP 5 if needed. The test baseline is the load-bearing safety net for everything that follows.
Step 2: Upgrade Composer dependencies (2-4 weeks)
Most PHP 5 codebases have Composer dependencies pinned to old versions, and many of those dependencies have abandoned upper-bound updates. The dependency-resolution work is usually the longest tail of the migration. Some packages will need to be replaced (abandoned packages, packages whose maintainer never shipped a PHP 8 release); some will need an upper-bound bump; some will need a fork. Plan time for this; it is the most common reason migrations slip schedule.
Step 3: Fix the breaking-change list (3-6 weeks)
PHP 7 removed mysql_* functions, ext-mcrypt, and many deprecated functions. PHP 8 tightened type strictness around implicit casts (null to non-nullable types, string to int), removed several more deprecated APIs, and changed the way named arguments interact with reflection. The migration list is well-documented in the official PHP migration guides; work through it methodically, running the test baseline after each batch.
Step 4: Re-baseline the deployment pipeline (1-3 weeks)
The deployment / CI pipeline that built PHP 5 packages probably needs to be updated for PHP 8. Test on PHP 8.0 first (the minimum supported version with new features) before moving to 8.3 or 8.4. Staged rollout with feature flags or blue-green deployment is the right pattern for the production cutover.
What the migration is NOT
A re-architecture. If the existing codebase has fundamental design problems — a monolith that should be a few well-scoped services, a database schema that fights every query, a domain model that doesn't match the business — those are separate engagements. Conflating migration with re-architecture is the most common reason migration budgets balloon. Modernize first; re-architect later if the modernization audit explicitly recommends it.
Common follow-up questions
How long does the whole migration take?
Eight to sixteen weeks for most mid-sized codebases (20,000-100,000 lines). Smaller codebases with good test coverage can be done in 4-6 weeks; larger codebases with no tests can take 9-12 months.
Can I migrate one piece at a time?
PHP version migration is fundamentally all-at-once for a given deployment unit — you cannot run half the codebase on PHP 5 and half on PHP 8 in the same process. You can split the codebase into separately-deployed services if the architecture supports it, and migrate one service at a time.
What if my codebase has zero tests?
Write smoke tests against the critical user paths before changing any code. Twenty to fifty tests covering the load-bearing flows is usually enough for the migration safety net — you are not aiming for 80% coverage at this stage.
If this answer is useful and you have a real engagement in mind, the contact form routes directly to the principal — James Henderson is the single engineer who scopes, writes, and supports every engagement end-to-end.