I manage a virtual server hosting several websites. I'm comfortable with basic IT work but I'm not an expert. The server currently runs AlmaLinux 8 with PHP 7.3, and the sites use different but broadly similar PHP codebases.
My original plan was to upgrade each site from PHP 7.3 to PHP 8.0, using Rector and testing each site individually. After everything worked, I would upgrade AlmaLinux 8 to AlmaLinux 9 with ELevate, then eventually move the sites from PHP 8.0 to PHP 8.4 or 8.5.
I've since 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 one PHP migration. However, I'm concerned about compatibility between third-party PHP packages on AlmaLinux 8 and the PHP packages available on AlmaLinux 9. I'm also unsure whether moving directly from PHP 7.3 to PHP 8.4 is too large a jump.
Which approach would be safest, and is there another migration strategy I should consider?
3 Answers
Consider separating the applications from the host by running each site in its own container with the PHP version it needs. You could upgrade the AlmaLinux host independently, then migrate or upgrade the containers one site at a time. This is especially useful if any of the applications contain old or proprietary code that may not handle PHP 8 changes cleanly.
The original staged plan is probably the lower-risk option. Rector and application testing are more manageable when you move through supported PHP versions instead of making one large leap. Whichever route you choose, first create a staging copy or snapshot, test every application and dependency, and verify backups and rollback procedures before upgrading the production server. You can also use containers or separate test environments to avoid depending on the exact PHP packages installed on the host.
Try not to combine two major changes. Upgrade PHP and test every site thoroughly before changing the operating system. A direct jump from PHP 7.3 to 8.4 may work, but it can reveal several compatibility problems at once, making failures harder to diagnose. The incremental 7.3 → 8.0 → newer PHP route is slower but easier to troubleshoot.
A practical transition would be to containerize the applications gradually. Keep the existing web server as a reverse proxy, move one site into a container, test it, and repeat until the host is no longer serving the applications directly.