Hire PHP developers in 2026: the 31 December 8.2 cliff that shapes your contract

Summary. PHP 8.2 leaves security support on 31 December 2026, four months from now, and its active support already ended on 31 December 2024, according to php.net. PHP 8.1 went end of life on 31 December 2025. Laravel 12 stopped receiving bug fixes on 13 August 2026 and keeps security fixes only until 24 February 2027. Meanwhile W3Techs measured on 17 August 2026 that PHP still runs 70.3% of sites with a known server-side language, and that 28.9% of those PHP sites are on version 7 and 7.9% on version 5, both long dead. If you are about to hire PHP developers, that gap is the brief. A mid-level Indian IT contractor sits in a ₹80,000 to ₹1,60,000 per month gross band on Team Management Services' 2026 rate card, with loaded cost typically 22% to 35% above gross, so the difference between a team that clears the cliff and one that arrives after it is measured in lakhs, not opinions.

The four dates that set the brief

Most PHP hiring requests arrive as a stack list. That is the wrong starting point in 2026, because the calendar is doing more to your codebase than your roadmap is. The PHP project runs a fixed lifecycle: two years of active support from initial stable release, then two more years of critical security fixes only, then nothing.

Source: php.net supported versions, read 18 August 2026.

Two of those rows expire in the same week. PHP 8.2 loses its last safety net on 31 December 2026, and PHP 8.4 drops out of active support on the same day, which means a team that "upgrades to 8.4" in November is buying four weeks of active support and then living on security-only patches for two years. That is a defensible choice if the target is stability. It is a poor choice if the reason for the upgrade was to stay current.

The PHP branches already past the line are on the unsupported branches list: 8.1 ended 31 December 2025 with 8.1.34, 8.0 ended 26 November 2023, and 7.4 ended 28 November 2022, nearly four years ago. Any candidate who tells you a PHP 7.4 application is "fine because it works" is describing uptime, not support.

What the security-only window actually changes

A branch in security-only support still receives critical patches, but the PHP project is explicit that those releases are made on an as-needed basis, and that there may be multiple point releases or none at all in a given period. Routine bug fixes stop. So do the compatibility improvements that keep a codebase upgradeable.

Perforce's Zend team, which sells extended support for exactly this situation, sets out the second-order effects in its PHP end-of-life guide: Linux distributions stop packaging the old runtime, container base images stop publishing patched builds, and Composer dependencies begin requiring a newer PHP. The application keeps running until the next server move or OS refresh, and then it does not.

The engineering judgement worth carrying into a hiring conversation is this: the expensive part is almost never the language upgrade. It is the dependency graph that upgraded around you while nobody was looking. A one-version move from 8.2 to 8.3 is a fortnight of work on a healthy codebase. A 7.4 to 8.5 move on an application with 40 abandoned Composer packages is a modernisation project with a different budget and a different team shape, and pretending otherwise at the hiring stage is how PHP contracts overrun.

The framework floors move faster than PHP does

PHP's own calendar is generous. The frameworks sitting on top of it are not, and they are usually what forces the timeline.

Laravel's own support policy gives every release 18 months of bug fixes and 24 months of security fixes. Laravel 12 shipped on 24 February 2025, so its bug-fix window closed six days before this article was written. Laravel 13 raises the floor to PHP 8.3, which quietly rules out PHP 8.2 for any team planning to be on the current major release within the year.

Symfony 7.4 is the more forgiving path. It is the current long-term support release, requires PHP 8.2.0 or higher, and carries bug fixes to November 2028 and security fixes to November 2029. For a regulated or slow-moving application, that is four more years of runway than Laravel 12 has left.

Drupal is the strictest. Its PHP requirements page, updated 4 August 2026, shows Drupal 11.1 and 11.2 rejecting PHP 8.2 outright, and Drupal 12.0 supporting PHP 8.5 alone. Drupal 12 also expects PHP compiled with argon2 for password hashing. That is a hosting requirement, not a code requirement, and it is the kind of detail that turns a two-week upgrade into a six-week one when the platform team finds out late.

WordPress went the other way. On 22 May 2026 the core team retired the "beta" label it had applied to every PHP 8.x version, documenting WordPress 6.9 and 7.0 as fully supporting PHP 8.5. John Blackbourn, WordPress core committer, wrote in the announcement: "it's become apparent that the 'beta' label has made some end users and web hosts reluctant to update to newer versions of PHP, and caused some developers of plugins and themes to delay testing and supporting newer versions of PHP." The minimum recommended version is now 8.3; the minimum supported version is still 7.4, which is why so much of the WordPress estate is stranded.

What is actually new in the language

PHP 8.5, released 20 November 2025, is worth naming in a hiring conversation because it changes what a senior candidate should be able to argue about. Its headline additions, per the release announcement, are a built-in URI extension backed by uriparser and Lexbor that parses URLs to RFC 3986 and WHATWG rules, the |> pipe operator for chaining callables left to right, clone() with an associative array so readonly classes can support the with-er pattern, the #[\NoDiscard] attribute that warns when a return value is dropped, persistent cURL share handles via curl_share_init_persistent(), and array_first() and array_last().

The deprecations matter more for planning. The backtick operator as an alias for shell_exec() is deprecated, non-canonical casts such as (integer) and (boolean) are deprecated, __sleep() and __wakeup() are soft-deprecated in favour of __serialize() and __unserialize(), and using null as an array offset now raises a deprecation. None of those break a build on their own. Together, in a ten-year-old codebase, they produce the deprecation-notice flood that makes teams abandon an upgrade halfway. The 8.4 to 8.5 migration guide is the document your prospective team should have read, and it is a fair interview question.

What we build with PHP teams

eCorpIT staffs and runs PHP engagements across four shapes of work, and the shape decides the team, not the other way round.

Version and framework cutovers. Moving an application off PHP 8.2 before 31 December 2026, or off 7.4 where the security debt is already years deep. This is dependency archaeology first, code second: a Composer audit, a platform-requirements check, a static-analysis baseline, then the runtime change.

Laravel and Symfony application development. New APIs, admin systems, customer portals and internal tools, built on Symfony 7.4 LTS where longevity matters and Laravel 13 where speed of delivery matters.

CMS engineering. WordPress and Drupal builds and rescues, including the plugin and module compatibility work that a PHP version change forces. Our WordPress development and PHP development practices share the same engineers, which is the point.

Legacy consolidation. Applications that grew across three framework generations and now need to be one thing. Usually the honest answer is a staged move rather than a rewrite, and we will say so before you sign anything.

How the engagement runs

1. Inventory, week one. Every environment, PHP version, framework version, Composer dependency and hosting constraint in one sheet, with an owner and a criticality rating against each. composer check-platform-reqs and composer audit do most of the first pass. Nothing is scoped before this exists.

1. Risk ordering. Public-facing and revenue-carrying applications first, then anything handling regulated data, then anything already past end of life. Internal tools on a dead branch are a real risk, but they are not the first risk.

1. Baseline and gate. Static analysis and a test baseline before any runtime change, so the team can tell a genuine regression from a pre-existing bug. Where coverage is thin, we write characterisation tests for the paths that carry money.

1. Staged cutover. One version at a time, behind a feature-flagged or blue-green deploy, with the old runtime kept available for rollback until the new one has held through a full billing or reporting cycle.

1. Handover. Runbook, upgrade calendar keyed to the php.net dates, and a named engineer through the first post-cutover cycle. The calendar is the deliverable that stops this recurring in 2028.

The stack we standardise on

PHP 8.3 or 8.4 as the runtime target depending on how much active support the client wants; Symfony 7.4 LTS or Laravel 13 as the framework; PHP-FPM behind Nginx; MySQL 8.0 or MariaDB 10.11 and above; Composer with composer audit wired into CI; PHPStan or Psalm for static analysis; Pest or PHPUnit for tests; Docker images pinned to a supported PHP tag rather than latest; and OpenTelemetry traces out of the application rather than log-scraping after the fact. Where a client's platform team has already standardised, we work inside their choices rather than importing ours.

What a PHP team costs, and what moves the number

We do not publish a rate card, because the honest answer depends on whether you are buying a cutover or a build. What we can point at is the independent market data. Team Management Services' 2026 India IT contract staffing rate card, published 12 August 2026, puts a mid-level (four to seven year) IT contractor in a pan-India gross band of ₹80,000 to ₹1,60,000 per month, and states that loaded cost to the buyer, once statutory contributions, agency markup and 18% GST are added, typically runs 22% to 35% above that gross. Their figures are explicitly illustrative market averages rather than a quote.

Three things move a PHP engagement's cost more than the day rate does:

Our own engagement models are a dedicated squad on a monthly retainer, a fixed-scope cutover priced against the inventory in step one, or staff augmentation into an existing team. We will quote against the inventory, not against a job description, because a job description cannot tell you how many Composer packages are abandoned.

India-specific considerations

Two things are different if the application serves Indian users or the team is hired in India.

The first is data protection. Any PHP application holding personal data of Indian users sits under the Digital Personal Data Protection Act 2023, and the security-safeguards obligation is where an unsupported runtime becomes a governance problem rather than an engineering preference. We design and build applications aligned with DPDP requirements, and we hold ISO 27001:2022, CMMI Level 5 and MSME certification. We do not certify your application, and any vendor who says they can should be asked to put it in writing.

The second is timing. Zend's guidance is that remediation for anything already past end of life should be treated as high-priority maintenance rather than roadmap work. In the Indian market, senior contractors commonly serve 30 to 60 day notice periods on the TMS benchmarks, and a fixed-term hire against a 31 December deadline therefore needs to start recruiting now, not in October. Delivery city also moves the rate: the same TMS data puts Bangalore at a 1.10x to 1.20x multiplier over the pan-India band and NCR at 1.05x to 1.15x.

Why eCorpIT

We are a Gurugram-based engineering organisation, founded in 2021, working as senior-led multi-disciplinary teams rather than a bench you pick names from. We hold CMMI Level 5, ISO 27001:2022 and MSME certification, and we are partners of AWS, Microsoft, Google, Shopify, Kaspersky and Desktime. On PHP work specifically, the same engineers cover Laravel development, CMS engineering and the DevOps side of a runtime cutover, so a version change does not need three vendors and a coordination meeting. Where the work turns out to be broader than PHP, our custom software development practice picks it up without a new contract.

FAQ

How eCorpIT can help

If you are staffing against the 31 December 2026 date, the first deliverable is an inventory, not a job posting: every environment, PHP version, framework version and Composer dependency, ordered by risk. We run that inventory as a scoped first engagement and quote the cutover against what it finds, rather than against a headcount guess. Teams are senior-led and can be a dedicated squad, a fixed-scope cutover, or augmentation into your existing engineering group. Tell us the application and the deadline at /contact-us/ and we will come back with the inventory plan.

References

1. PHP: Supported Versions - php.net, read 18 August 2026.

1. PHP: Unsupported Branches - php.net, read 18 August 2026.

1. PHP 8.5 Release Announcement - php.net, released 20 November 2025.

1. Migrating from PHP 8.4.x to PHP 8.5.x - PHP Manual.

1. Laravel Release Notes and Support Policy - laravel.com.

1. Symfony 7.4 Release - symfony.com.

1. Usage Statistics and Market Share of PHP for Websites - W3Techs, 17 August 2026.

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

1. PHP requirements - Drupal.org, updated 4 August 2026.

1. EOL PHP: Guide to Navigating PHP End of Life in Critical Web Apps - Perforce Zend.

1. IT Contract Staffing Cost in India 2026 - Team Management Services, 12 August 2026.

Last updated: 19 August 2026.