What stops PHP teams from upgrading

SaaS products are the most common type (36%), followed by business systems such as CRM or ERP (24%), websites (23%) and APIs (19%). 35% rate their tech debt as high or critical.

Business leads even though it offered five options, against six for dependencies and infrastructure.

That’s why an upgrade should start with a safety net, not a version bump.

“Upgrade ROI is mostly avoided future risk rather than immediately visible functionality, so the work tends to be postponed until security, dependency or infrastructure constraints turn it into an urgent project.”

Answers are anonymous and lightly edited for spelling and grammar. 20 “Other” entries held stray text rather than an answer, probably left by browser autofill; they were removed and aren’t shown.

1. Build the safety net before touching the version. Pin today’s behaviour with characterization tests on the paths that make money, then run the suite on the target PHP version in CI. Static analysis (PHPStan or Psalm, set to the target PHP version) catches many incompatibilities before production does.
2. Map the dependency graph first. composer why-not php 8.4 lists the packages that block a target version. To check whether your current version constraints resolve on the target version, set config.platform.php to it and run composer update --dry-run. composer audit flags abandoned packages (since Composer 2.7 it fails on them by default): replace or fork those, and plan the framework upgrade together with the PHP one.
3. Let tools do the repetitive part. Rector applies version-to-version code changes across a whole codebase. Compile-time deprecations, like implicit nullable parameter types, can be detected and fixed automatically. Runtime ones, like dynamic properties, appear only when the code runs, so lean on the tests from step 01 and the deprecation notices in your logs.
4. Remove the fear with production parity. A staging environment that mirrors production and a tested rollback plan turn a risky event into a routine deploy.
5. Make the business case with risk, not features. Support ends on a known date (31 December 2026 for PHP 8.2). Put the cost of staying behind next to the cost of upgrading: security exposure, hosting and OS support, compliance, hiring, performance.
6. Make upgrades routine, not projects. Small, regular bumps of PHP and dependencies cost far less than one big jump every five years.
7. Migrate obsolete frameworks incrementally. CodeIgniter 3, Zend Framework 1, symfony 1 and Yii 1.1 have no in-place upgrade path: the next major version is effectively a different framework. The Strangler Fig pattern moves one module at a time while the product keeps shipping.

• Sample: 203 responses collected from 27 July to 19 October 2026 through an opt-in Google Forms survey (people chose to take part, so it isn’t a random sample), promoted mainly on LinkedIn. Answers are self-reported. Leaving an email was optional (to receive the results), and all answers are reported anonymously. Each response describes one app; a few people answered for more than one.
• Timing: the PHP version question asked about “right now”, but at least 9 answers describe a migration done or under way (a framework given as “Laravel 8 to 13”, for example), so some blockers may be remembered from an earlier upgrade. That blurs the PHP 8 vs older comparison a little.
• Bias: people with upgrade problems are more likely to answer a survey about upgrade blockers, and the survey was run by an upgrade consultancy (Accesto) and shared mainly through its own network. Read the shares as “among respondents”, not “among all PHP apps”.
• Questions: blockers were tick-all-that-apply in four areas, each with an “Other” field, and not ranked: a share shows how widespread a blocker is, not how much it weighs. A few options were worded strongly (“Catastrophic downtime fears”, “Dependency hell”), and respondents’ roles weren’t asked. Blocker shares use all 203 responses as the base; profile shares use those who answered each question. Practice shares use the 195 who answered that question (5 of 46 older apps and 3 of 156 PHP 8 apps skipped it). Shares are rounded, so they may not add up to 100%.
• Comparisons: apps on PHP 8.x (n = 156) vs PHP 7.x or older (n = 46), tested with Fisher’s exact test. Gaps marked “clear” hold after a Benjamini–Hochberg correction across all 39 comparisons; treat the rest as indicative. The version gaps were rechecked with app age held constant (logistic and linear regression on the 186 apps with a PHP version and a usable age; 181 for practices). The link between verification gaps and fear of downtime was also checked against how many other blockers each respondent picked (Mantel–Haenszel odds ratio 1.85, p = 0.10).
• Cleaning: 20 “Other” entries held stray text rather than an answer, probably left by browser autofill, and were removed. Free-text answers were grouped by theme. App ages typed as text were normalized, and 8 answers that covered several projects or were ambiguous were left out. The team-size question was re-created mid-survey, and both versions were merged: where someone answered both (8 people), the newer one counts (2 of them differed).
• Comments: the “They say” comments are personal views from people in the PHP community, not survey results. We shared the report with them before publication, and each approved the wording of their comment. They speak for themselves, not for the organizations they work with. The exception is Michał Kurzeja, Accesto’s CTO, whose comment gives our own view.
• Sources: State of PHP 2026 survey announcement (The PHP Foundation, 9 June 2026) · PHP version stats, July 2026 (stitcher.io) · Supported versions (php.net, checked 19 October 2026).