CentOS End of Life: How to Migrate Your VPS to AlmaLinux

If your VPS still shows "CentOS Linux 7" or "CentOS Linux 8" when you run cat /etc/os-release, you're on a distro that no longer gets security patches. That's not a theoretical risk - it's an open door, and it's the single most common reason we see a server get compromised on an otherwise well-configured box. Here's what happened, why it matters now, and how to move to AlmaLinux or Rocky Linux without a mess.

Why This Isn't Just a Version Number

CentOS 8 stopped receiving updates on December 31, 2021 - Red Hat cut it short by eight years to push everyone toward CentOS Stream. CentOS 7 ran longer on borrowed time but hit its final end-of-life date on June 30, 2024. If you provisioned a VPS any time before late 2020 and never rebuilt it, there's a real chance it's still running one of these.

An unpatched OS doesn't announce itself. The server keeps serving your site, cPanel keeps logging you in, WordPress keeps publishing posts - right up until a known, published CVE in OpenSSL, sudo, or the kernel gets used against you. Security scanners and some hosting providers have also started flagging EOL distros directly, which is often how people find out.

Symptom: How to Tell If You're Affected

Run this on your VPS over SSH:

cat /etc/os-release

If the output says CentOS Linux 7 or CentOS Linux 8, you're on an EOL release. A quick second check - try updating packages:

yum update

On a dead CentOS mirror this either hangs, times out, or throws Could not resolve host: mirror.centos.org. That error alone confirms the official repos are gone; you're not getting patches through the normal path anymore, even if someone swapped in the vault mirrors to keep yum limping along.

Cause: Why This Happened

Red Hat restructured CentOS in December 2020, turning CentOS Stream into the upstream development branch and cutting the stable, downstream CentOS Linux short. The community response was AlmaLinux (backed by CloudLinux, the same company behind CageFS and LVE limits many cPanel servers already run) and Rocky Linux (started by one of the original CentOS founders). Both are 1:1 binary-compatible rebuilds of Red Hat Enterprise Linux, same as CentOS used to be - so the migration path exists, it's just a manual one-time job nobody gets around to.

AlmaLinux or Rocky Linux? Picking a Target

For a cPanel box specifically, AlmaLinux has the edge simply because CloudLinux (AlmaLinux's backer) also makes CloudLinux OS and the LVE/CageFS tooling most shared cPanel servers run on - support and documentation line up more cleanly. For a plain app server with no control panel, either works fine; pick whichever your team already has runbooks for.

The Fix: Two Ways to Migrate

Option A - In-Place Conversion (Faster, Riskier)

Tools like almalinux-deploy or migrate2rocky swap the underlying OS without reinstalling, keeping your files, users, and installed packages in place. It works, but any conversion script touching a live production kernel carries a non-zero chance of leaving the box unbootable. Only do this if you have a recent snapshot and can tolerate rollback time.

# AlmaLinux example - run as root, on CentOS 7/8
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
bash almalinux-deploy.sh

Take a full VPS snapshot immediately before running this - on Getwebup that's VPS → Manage → Snapshots → Take Snapshot. If the conversion breaks something, restoring the snapshot is faster than rebuilding from scratch.

Option B - Fresh Server, Migrate Data Over (Slower, Safer)

This is what we recommend for anything running real traffic, and it's the path most experienced admins take:

1. Audit what's running. List installed services, cron jobs, cPanel accounts, and any custom configs in /etc you'd otherwise forget. On a cPanel box, check WHM → List Accounts for everything that needs to move.
2. Provision a new VPS on AlmaLinux or Rocky. Match the vCPU/RAM/disk of the old server, or size up if you've outgrown it.
3. Move cPanel accounts with the WHM Transfer Tool (WHM → Transfers → Transfer Tool) if both servers run cPanel - it copies accounts, email, and databases in one pass and is far less error-prone than doing it file by file.
4. For a non-cPanel stack, rsync your web root and dump your databases separately:

   rsync -avz -e ssh /var/www/ user@new-server:/var/www/
   mysqldump -u root -p --all-databases > all_dbs.sql
   scp all_dbs.sql user@new-server:/root/

5. Test on the new server before cutting over. Edit your local /etc/hosts file to point your domain at the new server's IP temporarily, and confirm the site loads, logs in, and sends mail correctly.
6. Lower your DNS TTL to 300 seconds a day ahead of the cutover, then update your A record once the new server checks out. Keep the old server running for 24-48 hours as a fallback until DNS fully propagates.

Prevention: Don't Let This Happen Again

• Set a calendar reminder for your OS's published EOL date - Red Hat, AlmaLinux, and Rocky all publish these years in advance.
• Prefer distros with long, published support windows (AlmaLinux and Rocky both commit to 10 years per major version) over anything mid-lifecycle-only.
• Run dnf update or yum update on a schedule so you're not discovering broken repos the day you actually need a patch.
• If uptime matters to your business, budget for a server rebuild every OS major version cycle rather than stretching one install for a decade.

If you'd rather not run this migration yourself, Getwebup's support team can provision the new AlmaLinux server and handle the cutover for you - just open a ticket with your current server's hostname and we'll scope it.