I run several websites on a virtual server. They use different applications, but the PHP codebases are fairly similar. The server currently runs AlmaLinux 8 with PHP 7.3, and I want to upgrade both the operating system and PHP.
My original plan was to upgrade each site from PHP 7.3 to PHP 8.0 using Rector, test everything, upgrade AlmaLinux 8 to AlmaLinux 9 with ELevate, and then move the sites from PHP 8.0 to PHP 8.4 or 8.5.
However, I discovered that a third-party repository can provide PHP 8.4 on AlmaLinux 8. That would let me upgrade the applications directly to PHP 8.4, perform the operating-system upgrade, and avoid a separate PHP upgrade afterward. I'm unsure whether using a third-party PHP package on AlmaLinux 8 could cause conflicts with the PHP packages available on AlmaLinux 9, or whether moving directly from PHP 7.3 to PHP 8.4 is too large a compatibility jump.
Would the staged upgrade be safer, or is the third-party PHP 8.4 approach reasonable? Is there another migration strategy worth considering?
4 Answers
I’d avoid combining two major changes. Upgrade PHP in stages, test every website thoroughly, and only then upgrade the operating system. A direct jump from PHP 7.3 to 8.4 may work, but it can expose compatibility problems that are easier to identify when you move through the versions incrementally.
The third-party packages aren’t automatically a problem, but switching repositories and package sources during an OS upgrade adds another variable. The original three-step plan is more conservative, especially for older or proprietary applications. Make sure Rector’s changes are tested on a staging copy before touching production.
Consider separating the applications from the host OS with containers. You could run each site with its required PHP version, upgrade AlmaLinux independently, and migrate the applications one at a time. Docker Compose or a similar setup can also make the PHP versions and application dependencies easier to document and reproduce.
Containerizing the applications is probably the cleanest long-term solution if maintaining several different sites is manageable. It lets you focus on the underlying server upgrade separately, while each application can later be tested against newer PHP versions without changing the whole machine at once.
A gradual container migration works well here: move one virtual host at a time, point its web-server configuration at the container, and leave the remaining sites running normally until they’re ready.