PHP Version Support Timeline: When to Upgrade

In the Serengeti, elephant herds remember water sources across hundreds of miles—knowledge passed from matriarch to younger members over generations. When drought comes, this accumulated memory means survival: the herd knows which distant waterholes remain when others dry up, and they navigate these long-standing routes with certainty born of experience.

Similarly, keeping your PHP applications on supported versions requires accumulated knowledge about which upgrade paths remain viable and which lead to dead ends. The PHP project follows a predictable release cycle—but only if you understand the landscape. This article serves as that accumulated memory, showing you the reliable paths forward and warning of the dry stretches ahead.

One may wonder: with PHP releasing a new version each year, how do we keep up without constant emergency upgrades? Your primary challenge is clear: each PHP version receives two years of active support followed by two years of security-only updates. The practical question we face is: which version should we be using, and when exactly do we need to upgrade?

This post will break down the official PHP support timeline, explain what the different support phases mean, and provide clear, actionable advice on when you should plan your next upgrade. We’ll ground this in the actual dates for current versions and walk through the specific steps you can take to stay current.

Strictly speaking, PHP’s current time-based release cycle—with predictable two-year active support followed by two-year security-only support—was formalized in the PHP 7 era. This represented a shift from the more irregular releases of earlier PHP versions. The stability of this cycle is a significant advantage: we can now plan upgrades with confidence, knowing exactly when each version will reach its end of life.

📜 Historical Perspective: PHP’s Evolution Toward Predictability

To understand why this matters, consider PHP’s earlier years: PHP 4.x (2000-2007) saw releases roughly every 1-2 years but without a fixed schedule; PHP 5.x (2004-2019) stretched across 15 years with irregular point releases and extended support for some versions—PHP 5.6, for instance, received security fixes for over 4 years due to its popularity. PHP 6 was announced but never released, creating confusion about version numbering. Then PHP 7.0 arrived in 2015 with a clear promise: a predictable, time-based cycle. That commitment has held firm—PHP 7.1 through 8.4 have all followed the two-year active, two-year security pattern with remarkable consistency. This predictability is what allows us to plan multi-year upgrade strategies with confidence.

Understanding the PHP Release Cycle: Active vs. Security Support

Each PHP version follows a predictable, four-year lifecycle divided into two distinct phases. The PHP project formalized this time-based release cycle to give us, as developers, a clear horizon for planning. Before we get into that, though, let’s examine what each phase actually means in practice.

You can check which version is currently running on your system with a simple command:

$ php -v
PHP 8.4.0 (cli) (built: Nov 28 2025 12:00:00) ...

Once you know your version, you can determine where it lies in its lifecycle:

• Active Support (2 Years): For the first two years after its initial release, a PHP version receives active support. During this time, the project releases regular updates that include bug fixes, performance improvements, and security patches. This is the ideal phase for your production application to be in.
• Security Support (2 Years): After active support ends, the version transitions to “security fixes only” for another two years. During this period, the PHP project will only release patches for critical security vulnerabilities. No other bugs or issues are addressed—not even performance regressions. While better than nothing, this phase is a clear signal that you should be actively planning your upgrade.
• End of Life (EOL): Once a version stops receiving security support, it is considered “End of Life” (EOL). Running an EOL version is a significant security risk, as your application is exposed to known vulnerabilities that will never be fixed. Of course, some legacy systems remain on EOL versions for various reasons—though we’ll discuss the risks in detail later.

Of course, the boundaries between these phases aren’t always abrupt; security fixes may occasionally include minor bug fixes when they’re closely related. However, for planning purposes, it’s best to treat the phases as distinct.

The Current PHP Support Timeline (as of March 2026)

To make this tangible, let’s look at the current support schedule for all recent and upcoming PHP versions. These dates are determined by the PHP project’s release process: each version is supported for two years of active development, followed by two years of security fixes only. The timeline is remarkably stable—delays are rare, which makes our planning more reliable.

Version	Active Support Until	Security Support Until	Current Status (March 2026)
8.2	Dec 31, 2024	Dec 31, 2026	Security Fixes Only
8.3	Dec 31, 2025	Dec 31, 2027	Security Fixes Only
8.4	Dec 31, 2026	Dec 31, 2028	✅ Active Support
8.5	Dec 31, 2027	Dec 31, 2029	Upcoming Release

Data sourced from the official php.net supported versions page. You can also check this information directly using tools like php -i | grep "PHP API" to determine your current API level, though for support timelines you’ll need to cross-reference with the official page.

A few observations: though the dates follow a regular pattern, the exact timing of releases can shift slightly. PHP 8.4, for instance, was likely released in late 2025 to establish the December 31st active support boundary. The key takeaway for us is that versions move from active to security-only support on December 31st of even-numbered years—a pattern worth remembering for your planning.

Key Takeaways: When Should You Upgrade?

Based on the timeline above, here is the essential advice for keeping your applications safe and modern. Though we’ll explore specific strategies later, let’s establish the core principles first.

If You Are on PHP 8.3 or Lower: Start Planning Now

As of March 2026, both PHP 8.2 and 8.3 are no longer in their active support phase. This means they are not receiving fixes for bugs or non-critical security issues. If your application is on one of these versions, you should be actively planning your migration to PHP 8.4 to continue receiving full support. Of course, the exact timeline depends on your specific version—we’ll examine those cases below.

⚠️ Warning: EOL Versions Pose Critical Risks

If you’re running any version below PHP 8.2—you’re on End-of-Life software. This isn’t just a theoretical concern; in the wilderness, a herd that loses knowledge of water sources faces existential threat. Similarly, an EOL PHP version exposes your application to known vulnerabilities with no remedy. The risks compound daily as new security issues are discovered and remain unfixed.

Before we go further, though, it’s worth noting that many environments have multiple PHP versions installed. The version you see when running php -v from the command line might differ from what your web server or PHP-FPM uses. Typically, you can check your web-facing PHP version by creating a simple info.php file with <?php phpinfo(); and accessing it through your browser. Be sure to remove this file after checking, as it exposes sensitive configuration information.

💡 Tip: Verify All Environment Variants

Don’t assume your CLI version matches your web server’s version. We’ve seen cases where developers upgraded their command-line PHP but left PHP-FPM on an older version—creating a dangerous mismatch. Check every PHP variant your application might encounter: CLI, FPM, Apache module, and even cron jobs that might use a different binary.

The Goal: Always Target a Version with Active Support

Your primary goal should always be to run your production applications on a PHP version that is in its active support phase. This ensures you benefit from the latest performance enhancements and that all known bugs and security issues are being addressed. Right now, that version is PHP 8.4. Though it might be tempting to lag behind slightly—many organizations run one version back for stability—we generally recommend staying within the active support window.

The Dangers of EOL Versions

If you are running any version below PHP 8.2, you are running on End-of-Life software. This exposes you to significant risks—risks that compound daily as new vulnerabilities are discovered and remain unpatched.

Think of it like this: in the Serengeti, when seasonal rivers dry up completely—not just shrinking, but disappearing entirely—the herd faces catastrophe. The accumulated knowledge of where water once flowed becomes not just useless, but deadly, leading travelers to dry riverbeds where they find only dust. Similarly, an EOL PHP version leaves your application exposed to known vulnerabilities with no remedy—the security patches exist but will never reach you.

Let’s break down the specific risks:

⚠️ Critical Warning: EOL Means No Future Patches

Once PHP reaches End of Life, the project stops all development—no bug fixes, no security updates, nothing. You are responsible for your own security forever. This is not a sustainable position for any production application.

• Unpatched Security Holes: Your application is vulnerable to a wide range of security threats that have been discovered and fixed in newer versions—often dozens of CVEs per year. The severity depends on your application’s exposure; a public-facing web application faces more risk than an internal CLI tool, but both are affected. In 2025 alone, PHP addressed over 40 security vulnerabilities across supported versions—none of those fixes will ever reach an EOL installation.
• Poor Performance: You are missing out on years of significant performance improvements. Upgrades from PHP 7.4 to 8.4, for example, typically result in 30-50% performance improvements for many workloads—actual gains depend heavily on your code patterns, with JIT improvements benefiting compute-heavy applications most. Of course, the exact percentage you’ll see varies based on your specific application architecture.
• Library Incompatibility: Modern frameworks and libraries increasingly require supported PHP versions. This creates a cascading problem: you can’t update dependencies, which means you miss security fixes in those libraries as well. Composer, for instance, began enforcing minimum PHP version requirements more strictly in recent years—a package that requires PHP ^8.1 will refuse to install on PHP 7.4, even if it would technically work.

The cost of running EOL versions extends beyond theoretical concerns—it’s a concrete operational risk we see frequently in production environments. The longer you wait, the more technical debt accumulates and the harder the eventual upgrade becomes.

How to Approach Your Next Upgrade

Upgrading PHP doesn’t have to be a painful process, though it does require careful planning. A methodical approach can make it safe and efficient. The strategies we outline here have worked for teams upgrading from PHP 5.6 to modern versions—so whatever your starting point, there’s a path forward.

Let’s walk through a typical upgrade workflow. Though your specific circumstances may vary, these steps provide a solid foundation:

1. Audit Your Current Environment

Before making any changes, we need a clear picture of what we’re working with. Let’s walk through a concrete example—suppose you’re maintaining a typical Laravel application on a Ubuntu server. Here’s how you’d systematically audit your setup:

Step 1: Check your CLI PHP version:

$ php -v
PHP 8.3.12 (cli) (built: Jan 15 2026 14:30:00)
Copyright (c) The PHP Group
Zend Engine v4.3.12, Copyright (c) Zend Technologies
    with Xdebug v3.2.2, Copyright (c) 2002-2025, by Derick Rethans

That 8.3.12 tells us you’re on PHP 8.3—still within its security support period until December 2027, but already out of active support. Good to know, but not ideal.

Step 2: Check all installed extensions:

$ php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
 Reflection
session
simplexml
sockets
SPL
sqlite3
standard
tidy
tokenizer
xml
xmlreader
xmlwriter
xsl
zip
zlib

$ php --ri gd | grep "GD Support"
GD Support => enabled

Take note of any missing extensions you’ll need—gd, intl, pdo_mysql are common in production apps. You’ll want to ensure these have compatible versions for your target PHP version before upgrading.

Step 3: Examine your Composer dependencies:

$ composer show --platform | grep php
php 8.3.12

$ composer show --direct | head -15
name     : laravel/framework
descrip. : The Laravel Framework.
versions : * 10.18.0
...

But we need deeper insight. Let’s check which dependencies might conflict with PHP 8.4:

$ composer why-not php 8.4
php 8.4.0 requires ...
...
laravel/framework 10.18.0 requires php ^8.2 -> your php version (8.3.12) does not satisfy that requirement

That output tells us Laravel 10.x already supports PHP 8.4—that’s good news. If you saw conflicts, you’d know to plan dependency upgrades alongside PHP itself.

Step 4: Document your findings:

Create a simple audit file you can reference throughout the process:

$ cat > upgrade-audit.md << 'EOF'
# PHP Upgrade Audit - March 2026

## Current Environment
- CLI PHP: 8.3.12
- PHP-FPM: 8.3.10 (checked via php-fpm8.3 -v)
- Web server: nginx/1.22.0
- OS: Ubuntu 22.04 LTS

## Extensions Required
- ✅ mysqli (loaded)
- ✅ pdo_mysql (loaded)
- ✅ gd (loaded, v2.3.0)
- ⚠️ intl (loaded, v1.2.1)
- ❌ redis (NOT loaded—needs installation)

## Composer Dependencies
- laravel/framework: 10.18.0 (compatible with 8.4)
- symfony/console: 6.4.3 (compatible)
- phpunit/phpunit: 9.6.10 (needs update for 8.4)
  
## Blockers Identified
- redis extension not installed for target version
- phpunit needs update to ^10.0 for full 8.4 compatibility
EOF

That audit becomes your roadmap—you now know exactly what needs attention before you can upgrade safely.

2. Review Migration Guides and Deprecations

The PHP project maintains detailed migration guides for each version. These are essential reading. For example, if you’re targeting PHP 8.4, the official migration guide documents all backward-incompatible changes, deprecated features, and new functionality that might affect your code.

We recommend skimming the guide first to understand the scope of changes, then diving deeper into sections relevant to your codebase. Of course, not every deprecation will affect you—the goal is to identify the ones that do.

3. Use Static Analysis Tools

Static analysis tools can automatically identify compatibility issues before you even run your code. Several options exist, each with different strengths:

PHPStan is a popular choice. You can run it at different levels (0-9, with higher levels being stricter). For PHP version compatibility, PHPStan can be configured with a phpVersion setting:

# Install PHPStan
$ composer require --dev phpstan/phpstan

# Run analysis (baseline)
$ vendor/bin/phpstan analyse src/

# Configure for specific PHP version in phpstan.neon
parameters:
    phpVersion: 80400  # PHP 8.4

Rector goes beyond analysis—it can automatically fix many compatibility issues. For instance, Rector can upgrade deprecated syntax, replace removed functions, and modernize code patterns. A typical workflow:

$ composer require --dev rector/rector

# Dry run to see what would change
$ vendor/bin/rector process src --dry-run

# Apply changes
$ vendor/bin/rector process src

Though these tools are powerful, they’re not infallible. They may miss issues in dynamically-written code or in parts of your application that rely heavily on runtime evaluation. We still need manual review and testing.

4. Test Thoroughly in a Staging Environment

Once you’ve addressed the obvious issues, it’s time for comprehensive testing. This is where we discover the problems that automated tools can’t anticipate.

• Run your full test suite in an environment that mirrors your production setup as closely as possible. This includes PHP version, extensions, configuration (php.ini settings), and operating system.
• If you don’t have a test suite, start by manually testing critical paths. At minimum: authentication flows, database operations, external API integrations, and any complex business logic.
• Test with production-like data when possible. Real-world edge cases often surface only with actual data volumes and diversity.

Tip: Use continuous integration (CI) to automate this testing. Most CI platforms allow you to specify the PHP version easily. For example, in GitHub Actions:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['8.4']
    steps:
      - uses: actions/checkout@v3
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
          extensions: mbstring, pdo_mysql, gd

5. Plan Your Upgrade Path: Direct vs. Incremental

If you’re on an older PHP version (say, PHP 7.4 or earlier), you need to decide whether to:

• Upgrade directly to your target version (e.g., 7.4 → 8.4)
• Upgrade incrementally, moving through each major version (7.4 → 8.0 → 8.1 → 8.2 → 8.3 → 8.4)

Both approaches have merit—and in the wilderness, we see similar patterns. Some animals migrate directly across continents in a single journey; others make gradual stopovers, replenishing at each way station. Neither approach is inherently superior—it depends on the terrain, the season, and the traveler’s condition.

Let’s examine each approach in detail:

---

Direct Upgrade: The Non-Stop Journey

What it is: You upgrade straight from your current version to your target version (e.g., 7.4 → 8.4) in one step.

How it works: You prepare your codebase for the target version, test against it, and switch production directly—no intermediate stops.

💡 My Preference: Incremental for PHP 7.x, Direct for PHP 8.x+

Personally, I lean toward direct upgrades when starting from PHP 8.0 or later—the breaking changes between 8.0 and 8.4 are manageable with good tooling. For PHP 7.x codebases, though, I typically recommend incremental upgrades unless the codebase is exceptionally clean and thoroughly tested. The cumulative breaking changes across 7.4 → 8.0 → 8.1 → 8.2 → 8.3 → 8.4 can be substantial.

Advantages:

• Fewer deployment cycles (just one upgrade event)
• Less cumulative downtime risk (single maintenance window)
• Simplified rollback (just revert to pre-upgrade state)
• Tools like Rector can automate much of the heavy lifting

Disadvantages:

• You encounter all breaking changes simultaneously—potentially overwhelming
• Debugging issues is harder; you must determine which version’s changes caused a problem
• Requires more upfront preparation since you can’t test intermediate steps

When it makes sense:

• You’re on PHP 8.0 or later (fewer breaking changes overall)
• Your codebase is relatively simple and well-tested
• You have comprehensive automated test coverage
• You want to minimize deployment complexity
• Your team is comfortable handling multiple change vectors at once

---

Incremental Upgrade: The Gradual Migration

What it is: You upgrade through each major version sequentially: 7.4 → 8.0 → 8.1 → 8.2 → 8.3 → 8.4.

How it works: After completing an upgrade to an intermediate version (say 8.0), you stabilize there—fixing issues, updating dependencies, ensuring everything works—before moving to the next version.

Advantages:

• Each step has a smaller, more focused set of changes—easier to diagnose problems
• You can validate the codebase at each stage; if 7.4 → 8.0 succeeds, you know any later problem is from that transition
• Often feels psychologically more manageable (smaller bites)
• Allows time for dependency ecosystems to catch up between steps

Disadvantages:

• More deployment cycles (potentially 5-6 separate upgrades)
• Extended upgrade timeline (could span months)
• Increased cumulative risk across multiple deployments
• More opportunities for things to go wrong during transitions

When it makes sense:

• Starting from PHP 7.4 or earlier (cumulative changes are significant)
• Complex codebases with many edge cases
• Limited test coverage—you need to validate at each step
• Teams that prefer methodical, incremental progress
• Environments where production changes must be carefully paced

---

Decision Matrix: Which Approach Fits Your Situation?

Your Starting Point	Test Coverage	Codebase Complexity	Recommended Approach	Why
PHP 7.4 or earlier	Comprehensive (>80%)	Simple to moderate	Direct	Modern tooling can bridge the gap; fewer deployments reduces risk
PHP 7.4 or earlier	Minimal (<50%)	Complex	Incremental	Validation at each step catches issues early
PHP 8.0 - 8.2	Any	Any	Direct	Few breaking changes; simpler to jump to 8.4
PHP 8.3	Any	Any	Direct	You’re already on a version within active support; just move to 8.4

One may wonder: what if my dependencies don’t support intermediate versions? For instance, if a critical library only supports PHP 7.4 and 8.4 but not 8.0-8.3? In that case, you’re forced into a direct upgrade—or you must find alternative dependencies. This constraint can override other considerations.

6. Address Extension Compatibility

Think of PHP extensions like specialized tools carried by nomadic tribes—each one serves a specific purpose, but not all tools are available or function the same in new territories. PHP extensions—both built-in and PECL—can be a major upgrade obstacle if you assume they’ll work identically across versions.

Before upgrading PHP itself, verify that:

• All your required extensions have versions compatible with your target PHP version.
• Third-party extensions (like Xdebug, Imagick, Redis) have stable releases for your target.
• Your application doesn’t rely on behavior that changed between versions (e.g., ext/mysql was removed in PHP 7.0).

⚠️ Warning: PECL Extensions Often Lag Behind

In our experience, PECL extensions are the most common source of upgrade delays. While core extensions like pdo_mysql and gd are typically ready on day one, niche PECL extensions can take months—or years—to catch up. We’ve seen teams stuck on PHP 7.4 for over a year because a critical PECL extension had no PHP 8.x support. Check extension compatibility before committing to an upgrade timeline.

You can check extension compatibility by searching the PECL website or consulting extension documentation. For common extensions like Xdebug, the upgrade path is usually straightforward—Xdebug 3.2.x supports PHP 8.4, for instance. For niche extensions, you may need to contact maintainers directly or consider alternatives.

💡 Tip: Validate Extension Compatibility Early

Don’t wait until you’re ready to upgrade to check extensions. Early in your audit (Step 1), create a simple matrix: list every extension you use, note its current version, and check the PECL or project site for PHP 8.4 compatibility. This matrix becomes your blocker list—anything without a clear upgrade path needs attention before you proceed.

7. Upgrade in Production-Like Environment First

Once you’ve addressed the above, upgrade your staging environment. Start by installing the target PHP version alongside your current version (most systems can run multiple PHP versions in parallel). Then:

• Switch your web server or PHP-FPM to use the new version.
• Run your full test suite.
• Perform manual exploratory testing of critical features.
• Monitor logs for warnings, deprecation notices, or errors.

Pay particular attention to:

• Database connections (SSL/TLS requirements may have changed)
• Session handling (serialization format changes)
• Any code that uses ext/soap, ext/ldap, or other extensions with known compatibility quirks

8. Prepare for Rollback

In the wilderness, a herd never travels without knowing its retreat routes—when drought intensifies or predators threaten, they fall back to known safe areas with certainty. This isn’t pessimism; it’s prudent risk management. Similarly, before upgrading production, you must have a tested rollback plan ready—because even with the best preparation, surprises can happen.

⚠️ Critical: Rollback is Not Optional

We’ve seen well-prepared upgrades fail due to unforeseen edge cases—a database driver incompatibility that only manifests with production data volumes, a caching behavior change that triggers a cascade of errors, or a dependency that behaves differently under real load. Having a rollback plan isn’t admitting defeat; it’s ensuring you can recover quickly if needed.

Before upgrading production:

• Ensure you have full backups of your codebase, database, and configuration—test that you can actually restore from them.
• Document the exact rollback procedure—who does it, how long it takes, what commands to run—and practice it at least once in staging.
• Consider using a maintenance mode or blue-green deployment strategy to minimize downtime if rollback is needed.
• Keep the old PHP version installed temporarily so you can switch back quickly if needed—don’t uninstall it immediately after upgrade.
• Prepare a rollback checklist with specific commands (e.g., systemctl restart php8.3-fpm, database restore commands, cache rebuild steps).

9. Upgrade Production and Monitor

When you’re ready:

• Schedule the upgrade during a low-traffic period if possible.
• Execute during a maintenance window with your team ready to respond.
• Monitor error logs, application metrics, and user reports closely for the first 24-48 hours.
• Be prepared to roll back if critical issues emerge.

Though this may sound like many steps, the process becomes routine with practice. Many organizations now automate these upgrades as part of their regular maintenance cycles, upgrading to each new PHP version within months of release.

Tooling Landscape: What We Haven’t Covered

We’ve focused on core strategies here, but the PHP ecosystem offers additional tools worth mentioning:

• DePHP (https://github.com/sensiolabs-de/deptrac) can analyze your codebase’s dependencies on specific PHP versions or extensions.
• PHPCompatibility standards for PHP_CodeSniffer check code against specific PHP version requirements.
• Laravel Pint or other formatters can help modernize code style alongside version upgrades (though we recommend separating formatting changes from functional upgrades for clarity).

We could discuss these tools in more depth, but the principles above apply regardless of your specific toolchain.

Platform-Specific Upgrade Notes

When you’re ready to actually install a new PHP version, the exact process depends on your operating system and how PHP was originally installed. Let’s cover the most common scenarios:

Ubuntu/Debian with apt

If you originally installed PHP via the system package manager (apt), you’ll want to use a PPA (Personal Package Archive) that provides newer PHP versions. The most reliable is Ondřej Surý’s PPA:

# Add the PPA (you'll need sudo)
$ sudo add-apt-repository ppa:ondrej/php
$ sudo apt update

# Install PHP 8.4 with common extensions
$ sudo apt install php8.4 php8.4-cli php8.4-fpm php8.4-mysql php8.4-curl php8.4-gd php8.4-mbstring

# Verify installation
$ php8.4 -v

Though this process is straightforward, note that switching the default php command may require additional configuration (alternatives system). Many developers keep multiple versions installed and use explicit versioned commands (php8.3, php8.4) to avoid disruption.

macOS with Homebrew

Homebrew typically installs the latest stable PHP version:

# Install PHP 8.4 (if available)
$ brew install php@8.4

# If you already have PHP installed, upgrade:
$ brew upgrade php

# Link the version you want as active
$ brew link --overwrite php@8.4

# Verify
$ php -v

Homebrew maintains multiple versions as “formulae” (e.g., php@8.3, php@8.2). If you need to switch between versions frequently, consider using a version manager like phpenv (similar to rbenv for Ruby) or simply adjust your PATH.

CentOS/RHEL/Fedora with dnf/yum

On these systems, you’ll typically need to enablethird-party repositories:

# For RHEL/CentOS 8/9, Remi's repository is the standard source
$ sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
$ sudo dnf module reset php
$ sudo dnf module enable php:remi-8.4
$ sudo dnf install php php-cli php-fpm php-mysqlnd php-curl php-gd php-mbstring

# Verify
$ php -v

The “Remi” repository (maintained by Remi Collet) is the de facto standard for newer PHP versions on these platforms. Configuration can be complex if you have specific extension needs, so test thoroughly.

Windows

On Windows, PHP is typically installed either manually (downloading from php.net) or via a package manager like Chocolatey:

# Using Chocolatey
$ choco install php --version=8.4.0

# Manual installation requires downloading the ZIP package,
# extracting to C:\php, and updating system PATH

Windows upgrades often require updating the web server configuration (IIS or Apache) separately. Be sure to restart your web server after upgrading.

Docker

If your application runs in Docker containers, upgrading PHP typically means updating your base image:

# Before
FROM php:8.3-apache

# After
FROM php:8.4-apache

Then rebuild your images. Docker isolates changes, making it a safe environment for testing upgrades before applying them to development or staging servers.

---

Common Questions and Concerns

One may wonder: how much downtime should we expect during an upgrade? The answer depends significantly on your setup. For a well-prepared upgrade on a typical LAMP/LEMP stack, the actual switchover can take seconds to a few minutes (config reloads, FPM pool restarts). However, you should plan for a maintenance window of 30-60 minutes to allow for testing and rollback if needed.

What if we find breaking changes after upgrading? This is where your rollback plan comes into play. If you’ve kept the old PHP version installed alongside the new one, rolling back is often as simple as switching your web server configuration to point back to the previous PHP-FPM socket or binary, then restarting services. Having this procedure documented and tested beforehand reduces stress considerably.

Another common concern: what if our hosting provider doesn’t offer the PHP version we need? Of course, shared hosting environments can be limiting. In such cases, you have a few options:

• Contact your provider and request an upgrade; many will accommodate if enough customers ask.
• Migrate to a VPS or cloud provider where you control the PHP version (often a good long-term move anyway).
• Use a container-based hosting solution (like Heroku, Railway, or similar) where you specify the PHP version in configuration.

One may also ask: are there industries or compliance regimes that mandate specific PHP versions? Regulations like PCI-DSS often require running software that is still receiving security updates. For most organizations, adhering to the active support window satisfies these requirements. However, if you operate in a regulated environment, consult your compliance officers—some may require immediate upgrades to patch specific CVEs, regardless of the support phase.

Finally, you might wonder: how do we know when to start planning for the next upgrade after we’ve moved to PHP 8.4? A good rule of thumb: start planning when your current version enters its security-only phase. For PHP 8.4, that means beginning to consider PHP 9.0 (or whatever the next major version is) around late 2026. The planning horizon is typically 3-6 months before the actual upgrade.

Conclusion

Staying current with your PHP version is not a “nice-to-have” — it’s a core part of professional web development. By understanding the official support timeline and adopting a methodical upgrade process, we can move from a reactive firefighting approach to a proactive maintenance strategy.

We’ve covered the fundamentals: the two-year active, two-year security support cycle; the current timeline as of March 2026; and a comprehensive workflow that includes auditing, static analysis, thorough testing, and careful execution. We’ve also examined platform-specific installation considerations and addressed common questions that arise during upgrade projects.

Of course, the PHP ecosystem continues to evolve beyond just the language itself. As you plan your upgrade, remember that keeping your Composer dependencies updated is equally important. An up-to-date PHP version paired with current dependencies creates a foundation for secure, performant, and maintainable applications.

Take a moment now to check the PHP version in your development, staging, and production environments. If you’re not on PHP 8.4, the timeline is clear: you have until December 2026 to take advantage of active support, and the security-only phase begins immediately if you’re on 8.2 or 8.3. If you’re on an older version still, the need is even more urgent.

We encourage you to start with a small audit—run php -v, check composer show, and review your extension dependencies. That simple first step often reveals whether you’re positioned for a smooth upgrade or if you need to start planning more carefully. Either way, the time to act is before a security incident forces an emergency upgrade under pressure.

Your application’s security, performance, and long-term maintainability depend on staying current. The tools and processes are mature; the upgrade path is well-understood. The question is not whether to upgrade, but when—and with the timeline clearly laid out, the answer is: sooner rather than later.