EOL PHP: Guide to Navigating PHP End of Life in Critical Web Apps

What Does PHP EOL Mean for Your Organization? 

PHP end of life means the official PHP project no longer provides updates for that version. New bugs will remain unresolved. New PHP vulnerabilities may remain unpatched. Libraries, frameworks, CMS platforms, and hosting providers will also stop testing against that version. All of this together results in:

• Security Exposure — Security vulnerabilities in outdated PHP can remain open after the official support window closes. Newly discovered vulnerabilities may remain unaddressed, increasing the risk of PHP exploitation.
• Compliance Gaps — Many compliance standards require supported software, active patching, and documented vulnerability management. EOL PHP makes passing audits harder, especially for applications that handle payments (PCI DSS), healthcare data (HIPAA), or private data (GDPR).
• Hosting Limitations — Platform and hosting providers often remove older runtimes after support ends. Your web app may keep running until the next server move or OS refresh, then fail because the required PHP version is no longer available.
• Dependency Conflicts — PHP dependency management relies on regular updates. Composer packages, plugins, frameworks and more drop support for older PHP versions, locking your web app into old dependencies that also stop receiving security fixes.
• Higher Future Upgrade Cost — Failure to update PHP almost always increases cost. When a one-version upgrade (moving from PHP 8.2 to 8.3) becomes a multi-version upgrade (migrating from PHP 7.4 to 8.X), you must account for framework upgrades, plugin replacements, database updates, refactoring, and more.
   

How EOL PHP Impacts Your Application Stack 

As PHP rarely runs alone, let’s take a closer look at the effect EOL PHP can have on your entire application, including your PHP stack. 

Application stacks are built on many technologies, which may include: 

• Apache or NGINX 
• PHP-FPM 
• MySQL, MariaDB, PostgreSQL, or another database 
• Composer packages 
• Native PHP extensions 
• Linux distribution packages 
• Containers or orchestration platforms 
• CI/CD pipelines 
• Monitoring and security tools 

When a PHP version reaches EOL, the rest of the stack begins moving away from it. New Linux distributions may not package the old runtime. Newer extensions may not compile. Updated Composer dependencies may require a newer PHP version. Container base images may stop publishing patched builds for older versions. 

That is why PHP EOL planning should look beyond the runtime. You need to understand every connection between PHP, the operating environment, application code, dependencies, and deployment process. 

Impact on Major PHP Technologies

EOL PHP also impacts applications built on major CMS and frameworks. Here are a few popular technologies and how EOL PHP impacts their effectiveness: 

• WordPress — Plugins and themes may require newer PHP versions. Older PHP may limit WordPress core updates or create plugin conflicts. Learn more about WordPress PHP requirements. 
• Drupal — Drupal sites often have strict PHP version requirements tied to core and contributed module versions. A PHP upgrade may also require a Drupal core upgrade. Learn more about Drupal PHP requirements.
• Laravel — Laravel versions have their own PHP requirements, with older Laravel applications needing a staged upgrade before they can run on a modern PHP release. Learn more about Laravel PHP requirements.
• Symfony — Symfony components are widely used across PHP applications. As component versions evolve, older PHP versions can block dependency updates. Learn more about Symfony PHP requirements.
• CodeIgniter —  Older CodeIgniter applications may require code updates, library replacements, or framework upgrades before they can run reliably on newer PHP versions. Learn more about CodeIgniter PHP requirements.

Regardless of CMS or framework, always make sure to complete an inventory of your current stack before beginning an upgrade, including checking your technology’s PHP compatibility needs. 

How to View the PHP Version in Your Web Application

Are you deploying EOL PHP?

If you’ve inherited a new application, received one during an acquisition, or are building new documentation, you may not be certain. On top of that, many organizations use multiple PHP versions (for example, one version in production, another in staging, and several more in developer workstations or CI/CD pipelines). 

Use these methods to view the PHP version in your web application. 

Command Line 

If you have shell access, run: 

php -v

This returns the PHP CLI version. Keep in mind that the command-line PHP version may differ from the version used by the web server. You can also check loaded modules: 

php -m

And configuration details: 

php –ini

PHP Info Page

Create a temporary PHP file: 

<?php
phpinfo();

Load it in a browser to see the version, configuration, extensions, and environment details used by the web server. Remove this file immediately after use, as a public phpinfo() page can expose sensitive configuration details. 

Application Admin Panels

Some CMSs and frameworks show PHP version details in admin dashboards. WordPress, Drupal, Magento, and many hosting control panels provide environment or site health screens. This can be the fastest option for non-developers. 

Composer

For Composer-based applications, run: 

composer check-platform-reqs

This helps identify whether the current environment meets package requirements. You can also inspect composer.json for PHP version constraints. 

Additionally, consider running to identify packages with known security vulnerabilities: 

composer audit

Composer releases include enhanced security protections that can prevent the installation of dependency versions with known vulnerabilities. This will help you to identify and address risks earlier in the upgrade process. 

Hosting Control Panel

In cPanel, Plesk, managed WordPress hosting, and many cloud panels, the PHP version is often listed under site settings, runtime settings, or PHP selector tools. As with application admin panels, this can often be a fast option for checking PHP versions and verifying if you are deploying EOL PHP. 

Containers and CI/CD

If your PHP application is containerized, you can check for your PHP version using: 

• Dockerfile 
• docker-compose.yml 
• Kubernetes manifests 
• Helm charts 
• CI/CD pipeline files 
• Base image references 

For example, in dockerfile, this will look like: 

FROM php:8.2-fpm

If the base image uses an EOL version, the application may continue building but inherit an unsupported runtime.
 

Common Strategies for Upgrading EOL PHP

• Option 1: Upgrade PHP in Place — Upgrading PHP in place works best when your application is healthy, dependencies support newer PHP versions, and your team is available to test thoroughly.
• Option 2: Migrate or Modernize — If your application is tied to old frameworks, unsupported CMS versions, abandoned dependencies, or brittle custom code, then PHP migration may be your best option. This could include moving to a newer framework version, replacing legacy modules, or rebuilding parts of the web app.
• Option 3: Use Third-Party PHP LTS — PHP LTS is your best choice when immediate migration is not possible. For instance, PHP LTS from Zend provides security patches for older PHP versions beyond the official community EOL window. This is incredibly useful for critical systems that need more time to plan a safe migration.

Planning Ahead for PHP EOL Events 

Of course, the best PHP end of life website maintenance starts well before the EOL date. The goal is to make PHP upgrades routine rather than emergency projects.  

If you are not currently deploying EOL PHP versions, here are a few steps you can take today to ensure your critical applications stay up to date. 

Step One: Build a PHP EOL Inventory

Maintain a list of every application and environment that uses PHP. When the time comes to update, this simple inventory will help your team prioritize the most important work. Include: 

• Application owner 
• Business criticality 
• PHP version 
• Framework or CMS 
• Hosting platform 
• Public exposure 
• Data sensitivity 
• Upgrade target 
• EOL date 
• Remediation status 

Step Two: Prioritize Applications by Risk

Not all applications carry the same risk level. When prioritizing which applications should be updated first (and preferably before PHP EOL arrives), begin with web apps which are: 

• Public-facing 
• Revenue-generating 
• Handling sensitive data 
• Subject to compliance requirements 
• Running PHP versions already past EOL 
• Difficult to restore if they fail 
• Built on unsupported frameworks or CMS versions 

Step Three: Budget Before the PHP EOL Deadline

How much does it cost to update PHP versions? The answer depends on application complexity. A simple web app may only need a hosting change, plugin updates, and testing. A large custom application may require dependency upgrades, refactoring, test creation, framework migration, and deployment work. 

Cost drivers include:

• Number of PHP versions being skipped
• Age and quality of the codebase
• Framework or CMS status
• Test coverage 
• Number of integrations 
• Custom plugins or extensions 
• Database changes 
• Hosting or infrastructure changes 
• Compliance and validation requirements 
• Internal team availability 

One way to classify the budgetary needs of your PHP upgrade is to group projects into rough effort bands: 

• Low effort: Minor version update with compatible dependencies 
• Medium effort: Some dependency updates, plugin replacements, and code fixes 
• High effort: Framework upgrade, major refactoring, old CMS migration, or unsupported custom code 
• Critical effort: Business-critical application with no tests, outdated hosting, and many integrations 
   

Should I Upgrade EOL PHP Myself or Hire a Developer? 

When looking to address EOL PHP within your critical applications, one of the biggest decisions is whether to perform the work internally or bring in outside expertise. Like most development projects, the answer isn’t always straightforward, and your best choice will depend on application complexity, business impact, available technical skills, and tolerance for risk. 

For simpler websites with current software and reliable backups, an in-house upgrade may be a practical and cost-effective option. However, if the application directly supports customers, revenue-generating activities, regulated data, or critical business processes, professional assistance can help reduce risk and accelerate the path to a supported PHP version.  

Use this table as a quick reference:

Working With Third-Party Experts to Address EOL PHP 

If your organization is facing an upcoming PHP EOL event, struggling with legacy code, or planning a complex migration, working with experienced PHP specialists can help reduce risk and accelerate the path to a supported platform.  

Zend has decades of experience helping organizations maintain, modernize, and upgrade mission-critical PHP applications, including custom applications, MySQL, WordPress, Drupal, Laravel, Symfony, CodeIgniter, and other PHP-based systems. 

Whether you need guidance on PHP end of life website maintenance, assistance determining how to upgrade PHP from an end of life version, long-term support for an application that cannot be upgraded immediately, or a full modernization strategy, Zend can help you evaluate your options and build a plan that aligns with your technical and business requirements — all while allowing your team to focus on ongoing initiatives that grow your business.