Step-by-Step: Upgrading PHP 7.0 to 7.4 Safely

In the African savanna, a herd of elephants moves across the landscape in a pattern passed down through generations. The matriarch leads them to water sources she knows from decades of experience—some reliable, some seasonal. When drought strikes, the difference between knowing which waterholes remain and guessing can mean survival for the entire herd.

Similarly, when upgrading from PHP 7.0 to 7.4, we need accumulated knowledge about which patterns remain viable and which have “dried up”—deprecated functions, changed behaviors, breaking syntax. This guide serves as that accumulated memory, showing you which paths lead to successful migration and which lead to unexpected runtime errors. We’ll walk through a methodical process that respects the complexity of real-world applications while providing clear, actionable steps.

We begin by acknowledging that running a web application on PHP 7.0 does carry security considerations. PHP 7.0 reached its end-of-life in late 2018, meaning it no longer receives security patches or bug fixes from the PHP project itself. Upgrading to a supported version like PHP 7.4 addresses this concern—though it’s worth noting that PHP 7.4 itself will reach end-of-life in late 2023, so this upgrade may be part of a longer-term migration strategy toward PHP 8.x.

Before You Begin: The Safety Checklist

We strongly recommend against performing an upgrade directly on a production server—doing so risks extended downtime and data loss if issues arise. A methodical approach with proper safeguards gives us the confidence to proceed and the ability to recover if something goes wrong.

Here’s what we need before starting:

1. Create a Complete Backup: Before making any changes, back up all your application files and your database. Ensure you have a tested restoration procedure. We’ve found it’s worth verifying your backups actually work by performing a test restoration before proceeding.
2. Set Up a Staging Environment: Clone your production environment to a staging server. This is where we will perform and test the entire upgrade process. The more closely this staging environment matches production—same PHP extensions, same database version, same configuration—the more reliable our test results will be.
3. Establish a Testing Plan: Document the critical functionalities of your application. Your plan should include automated tests (if you have them) and a manual testing checklist to verify everything works as expected after the upgrade. We recommend focusing on areas most likely to be affected by PHP version changes: database interactions, string handling, and any use of deprecated functions.

Step 1: Audit Your Code for Compatibility

The first step is to identify deprecated or removed features from PHP 7.0 that your code might be using. Static analysis tools can automate this process and save us hours of manual review. While there are several tools available—PHP_CodeSniffer with PHPCompatibility, PHPStan, or Psalm—we’ll focus on Rector here because it can not only find issues but also automatically refactor your code to be compatible with newer PHP versions.

We should note that automatic refactoring isn’t always perfect. Rector’s changes require careful review, as it may not understand the full context of your application’s business logic. That said, for well-structured code, it can dramatically reduce the manual effort required.

First, install Rector via Composer:

$ composer require rector/rector --dev
Using version ^0.18 for rector/rector
./composer.json has been updated
Running Composer install rector/rector [--no-dev] [...]

Then, create a rector.php configuration file in your project root:

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\LevelSetList;

return static function (RectorConfig $rectorConfig): void {
    // Define paths to analyze - adjust these to match your project structure
    $rectorConfig->paths([
        __DIR__ . '/src',
        __DIR__ . '/tests',
    ]);

    // Define sets of rules - UP_TO_PHP_74 covers changes through PHP 7.4
    $rectorConfig->sets([
        LevelSetList::UP_TO_PHP_74,
    ]);
};

Now, run a dry run to see what changes Rector would make:

$ vendor/bin/rector process --dry-run
...
[+] Processed 124 files with 47 changes
[+] 32 file(s) changed in total
...

If you see output like the above, Rector has identified potential issues. One may wonder: how do we know what it changed? We can examine the specific changes by running with the --verbose flag or by checking the diff with --dry-run --output-format=diff. The exact output will vary depending on your codebase.

Once we’re comfortable with the suggested changes—having reviewed them in version control—we can run Rector to apply them automatically:

$ vendor/bin/rector process
...
[+] Processed 124 files with 47 changes
[+] 32 file(s) changed in total
...

Of course, we should commit these changes to version control before proceeding. That way, if Rector made any modifications we didn’t anticipate, we can always revert and make manual corrections.

Step 2: Update Your Dependencies with Composer

Your project’s dependencies must also be compatible with PHP 7.4. While updating the PHP requirement in composer.json is straightforward, we need to consider that some of your dependencies may have their own PHP version constraints that conflict with PHP 7.4. This is where Composer’s dependency resolution comes into play.

There are a few approaches we can take here:

Option 1: Update All Dependencies Update your composer.json to require PHP 7.4, then run composer update to fetch the latest compatible versions of everything:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev) [...]
Package operations: 15 installs, 20 updates, 5 removals
Writing lock file
Generating optimized autoload files

Option 2: Conservative Update with —with-all-dependencies If we want to be more conservative and only update dependencies that are actually incompatible with PHP 7.4, we can use:

$ composer update --with-all-dependencies

This tells Composer to update not just our direct dependencies but also their dependencies to find compatible versions. It’s often safer for larger projects.

Option 3: Update Individual Packages Alternatively, we can update specific packages that we know have PHP 7.4 support:

$ composer update symfony/console laravel/framework

This approach gives us more control but requires us to know which packages need updates.

Regardless of the method we choose, we should review the output carefully for any package conflicts that may require manual intervention. Composer will typically tell us if it can’t resolve dependencies. One may wonder: what if a critical dependency doesn’t support PHP 7.4? In that case, we’ll need to either find an alternative package, modify our application to work around the limitation, or in some cases, fork and update the dependency ourselves—though that introduces maintenance burden we’ll need to manage long-term.

Also note: if we’re using a CI/CD pipeline, we may need to adjust our composer install flags. The --no-dev flag is commonly used in production, but make sure our CI script still runs tests with dev dependencies before deployment.

Step 3: Key Breaking Changes from 7.0 to 7.4

This is the most critical part of the upgrade. PHP’s development team makes breaking changes carefully—usually after a period of deprecation—to improve language consistency, security, or performance. Understanding what changed between 7.0 and 7.4 helps us anticipate what might break in our code.

We should note that not all of these changes will affect every application. Whether a particular breaking change impacts us depends on which PHP features we actually use. The tools we ran in Step 1 (Rector, PHPCompatibility) should have flagged many of these issues already. Still, it’s worth reviewing the most significant changes manually, as static analysis tools can miss context-dependent problems.

Let’s walk through the major changes version by version, focusing on what changed, why it changed, and how to adapt.

From PHP 7.0 to 7.1

mcrypt Extension Removed

What changed: The mcrypt extension, which had been deprecated in PHP 7.1, was removed entirely. The extension provided encryption functions but had design flaws and wasn’t maintained.

Why: The PHP team removed mcrypt to encourage migration to the more modern and secure OpenSSL extension, which provides better cryptographic practices.

Impact: If your application uses functions like mcrypt_encrypt(), mcrypt_decrypt(), mcrypt_create_iv(), or related functions, these will now cause fatal errors.

Before:

<?php
$encrypted = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $data, MCRYPT_MODE_CBC, $iv);

After:

<?php
$encrypted = openssl_encrypt($data, 'AES-128-CBC', $key, OPENSSL_RAW_DATA, $iv);

Trade-offs: OpenSSL is more flexible but also more complex—you need to choose appropriate cipher methods and handle initialization vectors carefully. There isn’t a one-to-one mapping between mcrypt and openssl functions, so migration requires understanding both APIs.

Reserved Words as Class/Method Names

What changed: PHP 7.1 introduced several new reserved words including void, iterable, object, and callable (though callable was already a type hint). Using these as class, interface, trait, or method names now causes a fatal error.

Why: These keywords support new type system features. The language needs them reserved to maintain syntactic consistency.

Impact: Code like this will break:

<?php
// Fatal error in PHP 7.1+
class object {}  // 'object' is now a reserved word
function void() {}  // 'void' is a reserved return type

Fix: Rename these classes and methods. This is typically straightforward but can be tedious if you have many such names, especially in legacy code where these identifiers might appear throughout the codebase.

From PHP 7.1 to 7.2

count() on Non-Countable Types

What changed: In PHP 7.2, calling count() on a variable that is neither an array nor an object implementing Countable now triggers a TypeError (in PHP 7.3+ it became a TypeError; in 7.2 it was a Warning). Previously, count(null) returned 0.

Why: The PHP team argued that returning 0 for count(null) masked bugs—if you’re trying to count something and get 0, you might not realize your variable is null when you expected an array. This change encourages more explicit error handling.

Impact: Code that does this will now produce warnings or errors:

<?php
$items = null;
$total = count($items);  // Warning/TypeError: count(): Parameter must be an array or Countable

After:

<?php
$items = null;
$total = is_countable($items) ? count($items) : 0;

Alternative approaches: We could also normalize the value first:

<?php
$items = $items ?? [];
$total = count($items);

Of course, if we’re certain our variable should always be an array, this error might actually help us catch a bug where it became null unexpectedly.

create_function() Deprecated

What changed: The create_function() function, which creates anonymous functions from strings, is deprecated.

Why: create_function() essentially wraps eval(), which has significant security and performance implications. Modern PHP has better ways to create anonymous functions.

Impact: Code like this will trigger deprecation warnings:

<?php
$newfunc = create_function('$a,$b', 'return $a + $b;');

After:

<?php
$newfunc = function($a, $b) { return $a + $b; };

Complexity note: While the simple case is straightforward, create_function() was sometimes used to create dynamic functions with variable parameter lists. Migrating those cases requires more thought about how to structure the anonymous function.

From PHP 7.2 to 7.3

Flexible Heredoc and Nowdoc Syntax

What changed: The closing identifier for Heredoc and Nowdoc strings no longer needs to be on a line by itself. This sounds like a relaxation, but it can actually break existing code if your heredoc content accidentally matches the closing identifier.

Example of what could go wrong:

<?php
$str = <<<EOD
This is a heredoc with the word EOD somewhere in it.
EOD;  // This closes the heredoc - but what if "EOD" appeared earlier in the text?

In PHP 7.3+, if the string contains the closing identifier before the actual end, the parser may close the heredoc early. This is rare but worth checking if you have heredocs with content that might contain the identifier.

Why: This change was made to allow more flexible formatting—for instance, indenting the closing identifier.

Impact: Most code will not be affected. We should review any heredoc/nowdoc usage to ensure the closing identifier appears only where intended.

array_key_first() and array_key_last() Added

What changed: These two functions were added to get the first or last key of an array without iterating.

Impact: If we had defined our own functions with these exact names, they will now conflict with the built-in implementations, causing a fatal error about function redefinition. This is uncommon but worth checking if we defined custom functions like:

<?php
function array_key_first($array) { /* custom implementation */ }  // Fatal error in PHP 7.3+

Fix: Rename our custom function to something else like my_array_first_key().

From PHP 7.3 to 7.4

Curly Brace Syntax for Array Access Deprecated

What changed: Accessing array elements and string offsets using curly braces {} is deprecated. Use square brackets [] instead.

Why: The curly brace syntax was inherited from Perl and was kept for compatibility when PHP added array syntax. However, it’s ambiguous—it looks like string offsets might use the same syntax as complex curly brace variable parsing. The PHP team deprecated it to simplify the language.

Impact: Code like this will produce deprecation notices:

<?php
$array = ['key' => 'value'];
echo $array{'key'};  // Deprecated: using {} for array access

After:

<?php
$array = ['key' => 'value'];
echo $array['key'];  // Preferred

Similarly for string offsets:

<?php
$str = "hello";
echo $str{0};  // Deprecated
echo $str[0];  // Preferred

Migration scope: This is a straightforward find-and-replace in most cases, though we should be careful with complex expressions inside the braces.

allow_url_include Deprecated

What changed: The allow_url_include php.ini directive, which allows include and require to fetch remote files via URLs (like include 'http://example.com/file.php';), is deprecated.

Why: This feature poses a significant security risk—it’s essentially a remote file inclusion vulnerability waiting to happen. Even when not used directly, having it enabled increases the attack surface.

Impact: If our application uses URL includes, they will stop working when this directive is disabled (the default in PHP 7.4). We should audit our codebase for any include, require, include_once, or require_once statements that use URLs rather than local paths.

Better alternatives: For including remote code, consider if you actually need to do this at all. If you need to fetch data from a remote source, use cURL or file_get_contents with appropriate validation. If you’re using this to share code across servers, consider using a package manager like Composer, or deploy the shared code as part of your application.

Additional 7.4 Changes Worth Knowing

Beyond the deprecations we’ve covered, PHP 7.4 introduced several new features that, while not breaking changes, may interact with existing code in unexpected ways:

Typed Properties

PHP 7.4 added support for typed class properties:

<?php
class User {
    public int $id;
    public string $name;
}

Impact: If we try to assign a value of the wrong type, we’ll get a TypeError. This is generally a good thing—it catches bugs early—but it means we need to ensure our code initializes these properties correctly or allows null with nullable types (?int $id).

Arrow Functions

PHP 7.4 introduced short arrow functions:

<?php
$square = fn($x) => $x * $x;

Impact: This is additive—it won’t break existing code—but we should be aware that fn is now a reserved keyword? Actually, fn is not a reserved word in the traditional sense; it’s a token used specifically for arrow functions. It won’t conflict with function names, but we should avoid using fn as a class or interface name in PHP 8.0+ where it becomes reserved.

Numeric String handling

PHP 7.4 tightened numeric string handling. Strings like "123" that look like numbers are handled more strictly in arithmetic contexts. This can affect code that relies on loose type juggling.

unpack() with string keys

In PHP 7.4, unpack() with a format that produces string keys now preserves those keys more consistently.

These changes generally improve language consistency. We won’t see them as explicit errors during our upgrade if our code follows good practices, but they’re worth understanding for debugging subtle issues.

Step 4: Switch the PHP Version & Test

Once our code and dependencies are updated, it’s time to switch the PHP version in your staging environment. We’ll cover the most common hosting scenarios.

Switching PHP Versions

Command Line (Ubuntu/Debian):

On Ubuntu or Debian systems with multiple PHP versions installed, we typically use update-alternatives:

$ sudo update-alternatives --config php
There are 2 choices for the alternative php (providing /usr/bin/php).

  Selection    Path              Priority   Status
------------------------------------------------------------
* 0            /usr/bin/php7.2   72        auto mode
  1            /usr/bin/php7.0   70        manual mode
  2            /usr/bin/php7.2   72        manual mode
  3            /usr/bin/php7.4   74        manual mode

Press <enter> to keep the current choice[*], or type selection number: 3

After selecting PHP 7.4, we should also configure the web server (Apache or Nginx with PHP-FPM) to use PHP 7.4. For Ubuntu with Apache and libapache2-mod-php:

$ sudo a2dismod php7.2
$ sudo a2enmod php7.4
$ sudo systemctl restart apache2

For PHP-FPM setups:

$ sudo systemctl disable php7.2-fpm
$ sudo systemctl enable php7.4-fpm
$ sudo systemctl restart php7.4-fpm

Then restart your web server.

Docker:

Update your Dockerfile to use a PHP 7.4 base image. For example:

FROM php:7.4-fpm

# ... rest of your Dockerfile

Rebuild and restart your containers:

$ docker-compose build php
$ docker-compose up -d php

Hosting Panels (cPanel/Plesk):

Most hosting panels provide a UI to switch PHP versions per domain. In cPanel, we’d use the “MultiPHP Manager” or “Select PHP Version” interface. In Plesk, look for “PHP Settings” on the domain. Typically, we select PHP 7.4 from a dropdown and apply the change.

Verification Before Testing

After switching the PHP version, we should verify the change actually took effect:

$ php -v
PHP 7.4.33 (cli) (built: Mar 15 2023 12:00:00) ...

And for web requests, create a simple phpinfo.php file in our document root:

<?php phpinfo();

Visiting that page should show PHP 7.4 in the browser.

Testing Protocol

Now we begin the systematic testing process. We recommend the following sequence:

1. Enable Full Error Reporting

In our staging environment’s php.ini or application bootstrap, we should ensure all errors are visible:

error_reporting = E_ALL
display_errors = On
log_errors = On

Or in code (temporarily, for debugging):

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');

2. Check PHP and Web Server Logs

Monitor the logs while we exercise the application:

$ tail -f /var/log/php7.4-fpm.log
$ tail -f /var/log/nginx/error.log  # or apache2/error.log

Look for Deprecated notices, Warning messages, or Fatal error entries.

3. Execute Your Test Plan

Now we systematically go through our testing plan from the Safety Checklist:

• Run automated tests (PHPUnit, Codeception, etc.):

  $ ./vendor/bin/phpunit

  Watch for test failures. A failing test often points to a specific breaking change we need to address.

• Perform manual testing of critical paths: login, form submissions, database operations, file uploads, email sending, payment processing—anything that interacts with the core functionality.

4. Pay Special Attention to:

• Areas using mcrypt (if we didn’t catch it earlier)
• Code that calls count() on variables that might be null or strings
• Any legacy code using create_function()
• Array access with curly braces {}
• Heredoc/Nowdoc syntax that might have ambiguous closing identifiers
• Database abstraction layers—sometimes subtle behavior changes in PDO or mysqli surface here
• Date/time handling—PHP 7.2+ has improved DateTime behavior with timezones
• JSON operations—json_decode() error handling changed slightly in 7.3

5. Verify Performance and Resource Usage

Upgrading PHP versions can change performance characteristics. We should monitor:

• Request response times
• Memory usage per request
• Database query performance

PHP 7.4 is generally faster than 7.0, but poorly written code might expose new bottlenecks or trigger new warning messages that affect performance.

Common Testing Pitfalls

One might wonder: what if our tests pass but we still have issues? Automated tests only cover what we’ve explicitly tested. We should also:

• Exercise rarely-used admin functions
• Test with various user roles and permissions
• Try edge cases in data entry (very long strings, special characters, etc.)
• Test third-party integrations (payment gateways, APIs) to ensure they still work

Also, staging environments sometimes differ from production in subtle ways—different data volumes, different configurations, different PHP extensions enabled. We should aim to mirror production as closely as possible.

When Things Go Wrong

If we encounter errors during testing, we should:

1. Identify the specific breaking change causing the error—the error message or stack trace usually points to it.
2. Apply the appropriate fix from the patterns we discussed in Step 3.
3. Re-run the tests.
4. Document the issue and resolution for future reference.

If we encounter issues we can’t immediately resolve, we should consider whether we need more time for the upgrade, whether we need to address technical debt first, or whether we need to engage additional expertise. It’s better to delay the upgrade than to push broken code to production.

Of course, if we’ve done thorough auditing with Rector and reviewed our dependencies, major issues should be minimal at this point. The goal of this stage is to catch anything we missed and verify that the upgrade is production-ready.

Rollback Plan

Even with careful preparation, we might encounter issues that require us to revert to PHP 7.0. Having a rollback plan before going live is essential—we shouldn’t discover we need one during an emergency.

For staging: Keep the staging environment at PHP 7.0 until production upgrade is confirmed successful. That staging environment serves as our rollback reference.

For production:

1. If using package managers (apt, yum, etc.), we can switch back to the PHP 7.0 packages:

   $ sudo update-alternatives --set php /usr/bin/php7.0
   $ sudo systemctl restart apache2  # or php-fpm

2. If using Docker, revert the Dockerfile change and redeploy the old containers. Since we kept our old image tags (say, php:7.0-fpm), we can simply roll back:

   $ git revert HEAD  # or reset to previous commit
   $ docker-compose build php
   $ docker-compose up -d

3. If using hosting panels, switch the PHP version back through the UI.

4. Database rollback: If we made any database migrations as part of the upgrade (unlikely for a PHP version change alone, but possible if we also updated schema), we should have database backups ready to restore.

5. Code rollback: Using version control, we can revert any code changes:

   $ git revert <commit-hash>
   $ git push origin main

Important: Our backups from the Safety Checklist should still be intact. If we need to roll back, we should do so calmly, following a documented procedure rather than making decisions under pressure.

One may wonder: how long should we keep PHP 7.0 available as a fallback? We recommend keeping it installable for at least one week after production upgrade, though ideally we would remove it only after confirming stability in monitoring for a full release cycle (say, 2-4 weeks).

PHP Extensions and Configuration

When upgrading PHP versions, we need to ensure our required extensions are available and properly configured for PHP 7.4.

Checking Extensions

First, let’s see what extensions we currently have enabled in PHP 7.0:

$ php -m
[Core]
[date]
[libxml]
...
[pdo_mysql]
[gd]
[curl]
...

Now check which of these are available for PHP 7.4:

$ php7.4 -m  # if php7.4 command exists

Or create a phpinfo.php as we did earlier and compare the two pages side by side.

Common extensions that may need attention:

• mcrypt: Removed entirely. We need to ensure we’ve migrated all encryption code to OpenSSL. This was covered in Step 3.

• mysql (the old ext/mysql): This extension was removed in PHP 7.0. If we’re still on PHP 7.0, we should already be using mysqli or PDO. If not, that’s a major issue we need to address before upgrading further.

• ereg: Removed in PHP 7.0. Again, if we still use ereg functions, we have larger problems.

• APCu or OPcache: These caching extensions are commonly used. They need to be reinstalled for PHP 7.4, possibly from different package names. For example, on Ubuntu:

  $ sudo apt install php7.4-apcu php7.4-opcache

• imagick or gd: Image processing extensions. Make sure the PHP 7.4 versions are installed and any required libraries (like ImageMagick) are compatible.

• intl: Internationalization extension. Usually straightforward, but check ICU library versions.

• soap: If we use SOAP web services, verify the extension works with PHP 7.4.

• xdebug: For development and debugging, we’ll want Xdebug for PHP 7.4. Note that Xdebug’s configuration might need adjustment—the settings changed in newer versions.

Configuration Differences

PHP 7.4 may have different default values for certain php.ini settings. We should review our production php.ini and compare it with the PHP 7.4 defaults.

Common settings to verify:

• memory_limit - PHP 7.4 may handle memory differently
• max_execution_time - Same, but check our long-running scripts
• error_reporting - Should match our development/staging/production needs
• display_errors - Should be Off in production regardless
• log_errors - Should be On
• upload_max_filesize and post_max_size - If we handle file uploads, ensure these match our requirements
• session.save_handler and session.save_path - Session settings may need adjustment

We recommend generating a new default php.ini for PHP 7.4 and comparing it side-by-side with our current configuration:

$ cp /etc/php/7.4/apache2/php.ini-production /etc/php/7.4/apache2/php.ini

Then make our custom changes on top of that baseline rather than copying the old php.ini wholesale. This helps avoid inheriting deprecated or unnecessary settings.

Composer Platform Config

If our composer.json includes a config.platform.php setting (to lock dependencies to a specific PHP version for reproducible builds), we’ll need to update that:

{
    "config": {
        "platform": {
            "php": "7.4.0"
        }
    }
}

Then run:

$ composer update --lock

This ensures our composer.lock reflects the PHP 7.4 environment.

Environment-Specific Considerations

CLI vs Web SAPI: PHP CLI (command line) and PHP-FPM/Apache module may use different php.ini files. Make sure both are configured appropriately.

Docker containers: If we use Docker, we need to ensure our Dockerfile installs and enables the necessary extensions. For example:

FROM php:7.4-fpm
RUN docker-php-ext-install pdo_mysql gd opcache
RUN pecl install apcu && docker-php-ext-enable apcu

Of course, the specific extensions we need depend entirely on our application. The key is to inventory what we use in production, ensure those extensions are available in PHP 7.4, and verify they’re enabled and properly configured before we declare the upgrade complete.

Conclusion

We’ve walked through a methodical process for upgrading from PHP 7.0 to 7.4: establishing safety protocols, auditing code with static analysis tools, updating dependencies, understanding breaking changes, switching versions, and testing thoroughly. Like the elephant matriarch who knows which water sources remain reliable through drought, we now have accumulated knowledge about the upgrade path.

To summarize the key principles we’ve covered:

1. Never upgrade directly on production—always use a staged approach with proper backups.
2. Use automated tools wisely—Rector can help, but review its changes.
3. Understand what changed—not all breaking changes affect every application, but knowing what to look for helps us interpret errors.
4. Test systematically—automated tests plus manual verification of critical paths.
5. Have a rollback plan—be prepared to revert if issues arise.

With PHP 7.4 running successfully, we’ve achieved an important milestone. Our application now receives security updates and benefits from performance improvements. Strictly speaking, though, PHP 7.4 itself will reach end-of-life in November 2023. This upgrade is part of a longer journey—we’re now positioned to plan the next step toward PHP 8.x, which brings even more substantial improvements: the JIT compiler, union types, attributes, constructor property promotion, and much more.

The patterns we’ve learned here—audit before upgrade, use tooling, understand breaking changes, test thoroughly—apply equally to future upgrades. In fact, upgrading from PHP 7.4 to PHP 8.0 will follow a similar process, though with different specific breaking changes to address.

Of course, if we encounter issues we can’t resolve, that’s a sign our application may have accumulated technical debt that needs attention. Sometimes an upgrade reveals hidden problems that were masked by older PHP versions. Addressing these issues—whether they’re design flaws, inadequate tests, or problematic dependencies—ultimately makes our application more maintainable.

One final thought: upgrading PHP versions isn’t just about chasing the latest release. It’s about maintaining a secure, performant, and sustainable application. By approaching upgrades methodically, we reduce risk and build confidence in our deployment process. That’s valuable regardless of which PHP version we’re running.