PHP development company: crossing the 31 December 2026 PHP 8.2 cliff

Summary. PHP 8.2 stops receiving critical security fixes on 31 December 2026, four months from now, according to the PHP Group's supported versions table. PHP 8.1 already went dark on 31 December 2025. On 16 August 2026, W3Techs measured PHP 8 at 63.0% of PHP sites, PHP 7 at 29.0%, PHP 5 at 7.9% and PHP 4 at 0.1%, so 36.9% of the PHP web is running a major version that nobody patches. PHP itself still powers 70.3% of sites whose server-side language is known. The framework layer has its own calendar and it does not line up: Laravel 12 stopped getting bug fixes on 13 August 2026 and keeps security fixes only until 24 February 2027, while Symfony 6.4 LTS still accepts PHP 8.1.0 as its floor. eCorpIT scopes PHP work against those dates rather than against a rewrite pitch. The real cost is usually the migration, not the code.

The dates that set the scope

Every serious PHP engagement in the next two years is shaped by one table. These are the branches the PHP Group still patches, as published on 17 August 2026.

Each branch gets two years of active support and two more of security-only fixes, then it is done. PHP 8.6.0 Beta 1 was announced on the PHP homepage on 13 August 2026, which puts 8.6 on the usual November cadence.

Two things follow. First, an application sitting on PHP 8.2 has four months of patches left and a two-step problem: get to 8.3 or 8.4, then stay on a branch that will not expire mid-project. Second, an application on PHP 7.4 or 8.0 is already unpatched by the project, and the only community-supported target worth aiming at is 8.3 or higher.

There is a paid escape hatch. TuxCare sells Extended Lifecycle Support for end-of-life PHP, and the Plesk extension for it covers PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0 and 8.1, migrating sites onto patched builds without touching application code. That buys calendar time. It does not move the application forward, and it adds a licence to renew every year.

What a PHP engagement with us actually covers

We build and modernise server-rendered and API-backed PHP applications. Concretely:

Application portfolio analysis first: which repositories exist, what PHP version each one runs, what the composer.json constraints allow, and which of them are pinned by a single unmaintained package. Runtime upgrades from PHP 7.x and 8.0 to 8.3 or 8.4, done incrementally behind tests rather than as a big-bang cutover. Framework upgrades across Laravel and Symfony, including the deprecation work that a major version demands. Strangler-pattern extraction, where a heavy legacy monolith gives up one bounded context at a time to a new service, rather than being rewritten wholesale. API layers over legacy data, so a modern front end or mobile client can ship before the back end is finished. Dependency and supply-chain hardening using composer audit and blocking policies. Long-run maintenance, with a named senior engineer rather than a ticket queue.

What we do not sell is the reflex rewrite. A rewrite discards working business logic that took years to get right, and it makes the migration risk worse, not better.

The framework floor and the language ceiling do not match

This is the part buyers get wrong, and it is where a badly scoped project loses a quarter. The framework's minimum PHP version and the language's support window are set by different people on different calendars.

Read the Symfony 6.4 row again. It is a long-term support release with security fixes running to November 2027, and its stated minimum is PHP 8.1.0, a branch the PHP Group stopped patching on 31 December 2025. A team can be fully inside framework support and completely outside language support at the same time. That combination passes most internal compliance checks and fails every real threat model.

Laravel's schedule is tighter than teams expect. Laravel's release notes give every release 18 months of bug fixes and 24 months of security fixes, with a major version each Q1. Laravel 13 shipped on 17 March 2026 and raised the floor to PHP 8.3. Laravel 12 left bug-fix support on 13 August 2026, four days before this article was written.

Symfony's own guidance argues against hoarding LTS releases. Writing on the official Symfony blog on 26 November 2025, Javier Eguiluz set out both paths and closed with a flat recommendation: "The official Symfony recommendation is to use regular versions whenever possible." His reasoning is that a team on regular releases fixes deprecations a few at a time between minors, while a team parked on an LTS pays for all of them at once, two years later, in a single upgrade.

How we run a PHP modernisation

Five steps. We do not skip them and we do not run them in parallel.

1. Inventory and freeze the facts. We read every composer.json and composer.lock, record the running PHP version per environment, and run composer audit. Composer reports advisories in table, plain, JSON or summary format, and its audit configuration can block affected package versions outright during update and require. That switch converts a report nobody reads into a build failure somebody fixes.

2. Get a safety net before touching code. Most legacy PHP has thin tests. We add smoke tests over the highest-traffic URLs first, which is the same shortcut the Symfony team recommends for projects with no suite: they are quick to write and they surface deprecations. Then we set a PHPStan baseline. PHPStan ships 11 rule levels, 0 loosest to 10 strictest, and the baseline file lets existing errors stay recorded while new code is held to the higher level.

3. Automate the mechanical upgrade. Rector applies PHP version sets, and its withPhpSets() call reads the target version straight from composer.json. On genuinely old code you step through sets from PHP_53 upward instead of jumping. Rector handles the syntax and signature changes. It does not handle behaviour changes, which is why step 2 comes first.

4. Move the runtime, then the framework. Language version first, because it is the smaller blast radius and the harder deadline. Framework major second, with deprecations cleared under --display-deprecations before the jump. Deploy each step behind a flag or a canary, not on a Friday.

5. Harden and hand over. Dependency policy in CI, an upgrade calendar keyed to the table above, and a runbook the client's own team can execute for the next branch. If we have done this properly, the next upgrade does not need us.

The stack we work in

PHP 8.3 and 8.4 on the runtime side, with 8.5 for greenfield work. Laravel 12 and 13, Symfony 7.4 LTS and 8.1. Composer with audit blocking enabled. Rector for automated upgrades, PHPStan at level 5 and above for static analysis, PHPUnit for the test suite. MySQL 8.0 and PostgreSQL, Redis for cache and queues. Docker for parity between local and production, deployed to AWS or Azure, both of which eCorpIT holds partner relationships with.

WordPress and Drupal work sits alongside this. WordPress Core's own guidance, updated on 22 May 2026 by John Blackbourn, retired the "beta" label from PHP 8 support entirely: WordPress 6.9 and 7.0 are documented as fully supporting PHP 8.5, 6.8 and later fully support PHP 8.4, and 6.4 and later fully support PHP 8.3. The minimum recommended version is 8.3; the minimum supported is 7.4. If a host is still telling you PHP 8 support is experimental, that guidance is fifteen months out of date.

For teams whose plugin estate is the real constraint rather than core, our WordPress development company page covers that path. Teams standardising on one framework should read the Laravel development company page, and anyone weighing a language change should compare it against our Node.js development company and Python development company work before committing.

Why eCorpIT

eCorp Information Technologies Private Limited has been building software since 2021, from Gurugram. We are CMMI Level 5 appraised, ISO 27001:2022 certified and MSME registered, and we hold partner relationships with AWS, Microsoft, Google, Shopify, Kaspersky and Desktime. Engagements are senior-led: the engineer who scoped your upgrade is the engineer who runs it.

The practical reason to bring in a partner for this specific job is that the work is unglamorous and time-boxed. An in-house team can do a PHP 8.2 to 8.4 upgrade. What they usually cannot do is run it alongside a roadmap, because the upgrade has a fixed date and the roadmap does not, and the roadmap always wins the argument until the date has passed.

What drives the price

We do not publish a rate card, because the number that matters is not a day rate. It is the number of days, and that is set by four things: how many distinct PHP versions are running across the estate, how much test coverage exists before we start, how many abandoned Composer packages are pinning the version constraints, and whether the database and hosting layer move at the same time.

For a sense of the market: a Symfony developer role advertised on the official Symfony jobs board in August 2026 listed €25 to €50 per hour, fully remote. That is the labour market a modernisation competes with, whether the work is done in-house or outside.

We scope in three shapes. A fixed-price upgrade audit that ends with a written plan and a day estimate. A time-and-materials modernisation sprint sequence, typically several weeks, with the runtime move in the first block. A retained maintenance engagement for teams that want the upgrade calendar handled permanently. Which one fits is a fifteen-minute conversation, and it is worth having before the December date rather than after.

India-specific considerations

Two things differ for Indian buyers. Hosting estates here skew towards shared cPanel and Plesk servers, where the PHP version is a control-panel dropdown rather than a Dockerfile line. That makes the runtime move fast and the regression risk high, because nobody knows what else is on the box. Inventory first, always.

Second, the Digital Personal Data Protection Act 2023 raises the cost of running unpatched software that touches personal data. An application on PHP 8.1 or 7.4 is not receiving fixes from the PHP Group, and "the framework still supports it" is not a defence anyone will accept. We design applications aligned with DPDP requirements, and for legacy estates the version inventory is the first artefact that conversation needs. Teams building out a wider India delivery footprint can start from our software development company in India page, or the web development company in Gurgaon page if the work is local.

FAQ

How eCorpIT can help

We run PHP upgrade audits that end with a written plan, a day estimate and a version target keyed to the PHP Group's support dates, then execute the migration in blocks your team can absorb alongside its roadmap. The work covers runtime moves, Laravel and Symfony major upgrades, Composer supply-chain hardening and the strangler-pattern extraction that replaces a rewrite. Senior engineers run the engagement end to end. Tell us what you are running and by when it has to move at /contact-us/.

References

1. PHP: Supported Versions - The PHP Group

1. Usage statistics and market share of PHP for websites - W3Techs, 16 August 2026

1. Release Notes and Support Policy - Laravel 13.x documentation

1. Symfony Releases - Symfony SAS

1. Preparing for Symfony 7.4 and Symfony 8.0 - Javier Eguiluz, Symfony blog, 26 November 2025

1. The Release Process - Symfony contributing documentation

1. PHP support clarification, spring 2026 edition - John Blackbourn, Make WordPress Core, 22 May 2026

1. PHP compatibility and WordPress versions - Make WordPress Core handbook

1. Set Lists - Rector documentation

1. Rule Levels - PHPStan user guide

1. Command-line interface: audit - Composer documentation

1. Config reference: audit and dependency policies - Composer documentation

1. TuxCare Extended Lifecycle Support for PHP extension - Plesk

Last updated: 17 August 2026.