A PHP upgrade needs a clear route back if a plugin or background task fails under the new runtime. I test a separate PHP-FPM service before moving web requests to it, keeping the previous runtime and its configuration available during verification.
The switch point should be easy to identify: which pool receives web requests, which executable runs scheduled work and which settings each one loads. That makes both the upgrade and a possible rollback easier to check.
Inventory the runtime before choosing the switch
I record the extensions the application actually uses, its loaded configuration, pool settings, file access and scheduled commands. Matching the PHP version number is only part of it. A replacement without the required image or Redis extension can pass a basic page test and fail later in a different workflow.
The shell and the website need separate checks. PHP can load configuration according to its runtime interface, as the PHP configuration manual explains. I do not take php -v in an administrator’s shell as proof of what serves a web request or runs a scheduled task.
Give the new pool a clear boundary
A separate FPM pool needs its own listening address, suitable permissions and deliberate resource limits. The web server then has one identifiable destination for PHP requests. PHP’s FPM configuration reference covers the pool’s listener, process user and worker limits.
I check the new pool against a staging copy before switching normal traffic. The test includes an uncached page, an authenticated admin task, a REST request and the media operations the site uses. I test as the account which normally performs the work; my own shell may have access which the application does not.
Include the jobs visitors never see
Changing the web server’s FPM connection does not rewrite a crontab. A scheduled command with an explicit old PHP path will keep using that runtime. Conversely, a command which relies on the shell’s default can change without the website changing.
I list those commands and decide their runtime deliberately. If web and CLI share cached values, I test that they can both read them. My earlier note on PHP and shared cache formats explains why different extension or serialisation choices matter here.
Describe exactly what rolling back restores
For this kind of move, the immediate route back is the old web-server connection and its known configuration. I keep those details with the change, along with the checks that would trigger a rollback.
That restores the runtime route. It does not undo a database migration, an uploaded file or an order created since the switch. I keep runtime changes separate from unrelated data changes where possible, and make the recovery plan explicit where that is not possible.
The old runtime is a temporary recovery option, with an agreed retirement point after verification. I do not leave two poorly understood stacks running indefinitely. Nor do I describe a version upgrade as a measured speed improvement without comparable timings: compatibility, maintainability and an understandable rollback are useful outcomes on their own.