Migrate a cPanel server from CentOS 7 to AlmaLinux 8

CentOS 7 went end-of-life on 30 June 2024. As of 2026, any cPanel server still running it is unpatched at the kernel and glibc level, won't pass a PCI scan, and is months overdue for a move. cPanel itself dropped CentOS 7 support several versions ago — /scripts/upcp warnings on these boxes haven't been gentle for a while.

This guide covers the two realistic migration paths: an in-place ELevate upgrade to AlmaLinux 8, and a fresh install plus WHM transfer. They have very different risk profiles, and the right choice depends on how many accounts are on the box and how much downtime you can absorb.

Which path to pick

Short version: use fresh install plus transfer for production. ELevate works but its failure modes leave a half-converted server that's painful to recover from. For a low-traffic internal box where you can take a 90-minute window and have a hypervisor snapshot, ELevate is fine.

Path A — Fresh install plus WHM transfer

This is the boring, reliable path. The old server keeps serving traffic until DNS cuts over.

Step 1 — Prepare the new server

Spin up a new VPS or dedicated host with AlmaLinux 8 or 9, then install cPanel from scratch. Use the same cPanel tier you currently run — your existing licence will activate on the new IP after you release it from the old one. The cPanel licence rebind flow covers the IP move.

Match the partition layout. If /home is its own filesystem on the source, it should be on the target — otherwise pkgacct restores write into /home on the root partition and run you out of space mid-transfer.

Step 2 — Export account packages and feature lists

Before transferring, export the WHM configuration that's easy to miss:

# On the old server
whmapi1 listpkgs > /root/pkgs.txt
whmapi1 list_features > /root/features.txt
ls /var/cpanel/packages/ > /root/pkgnames.txt
tar -czf /root/cpanel-config.tar.gz /var/cpanel/packages/ /var/cpanel/features/ /etc/wwwacct.conf

Copy that tarball to the new server and unpack into the same paths. Then re-run the EasyApache 4 profile export:

ea_install_profile --install /etc/cpanel/ea4/profiles/custom/your-profile.json

Step 3 — Transfer the accounts

WHM has a built-in transfer tool that handles this end-to-end:

WHM → Transfers → Transfer Tool → enter the source server's IP, root password (or SSH key), and pick All accounts. The tool runs pkgacct on the source, transfers the archive, restores on the destination, and reports per-account success/failure.

For a fleet move where you're scripting this, the CLI equivalent is:

/scripts/cpanel-pre-transfer --source-host=OLD.IP.HERE \
  --source-user=root --transfer-account-data=yes \
  --transfer-config-data=yes

Transfer rate on a 1 Gbps link is roughly 5-8 accounts per minute for typical WordPress sites. A 200-account box moves in 30-45 minutes of wall-clock time.

Step 4 — Cut over DNS

Lower the TTL on your authoritative DNS to 300 seconds 48 hours before the cutover. At cutover, repoint A and AAAA records to the new IP. Mail flows correctly the moment the new server's MX is reachable — cPanel transfers move the mail spool, so users don't lose mail.

Leave the old server running for 7 days as a fallback. Watch the new box's access logs to confirm traffic is hitting it before tearing the old one down.

Path B — In-place ELevate

ELevate is AlmaLinux's fork of Red Hat's Leapp tool, adapted for CentOS-to-AlmaLinux upgrades. On a cPanel box you run it after putting the cPanel agent into a "ready to upgrade" state.

Step 1 — Snapshot the entire VM

Non-negotiable. The kernel, glibc, systemd, and several thousand RPMs are replaced during the upgrade. If anything wedges mid-run, you need a one-click rollback. Take a full hypervisor snapshot, not just a /backup tarball.

Step 2 — Update cPanel to the latest release

cPanel must be on the current stable tier before ELevate. Run:

/scripts/upcp --force

This brings cPanel to the latest version and ensures the included MySQL / MariaDB / PHP packages are compatible with the AlmaLinux 8 repos that ELevate will switch to.

Step 3 — Run the ELevate pre-upgrade check

curl https://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm -o elevate-release.rpm
yum install -y elevate-release.rpm
yum install -y leapp-upgrade leapp-data-almalinux

leapp preupgrade

The preupgrade step generates /var/log/leapp/leapp-report.txt. Read it. It lists every blocker that will stop the upgrade — usually third-party repos, deprecated PHP modules, or custom kernels. Resolve each one before continuing. The most common cPanel-specific blockers:

• EPEL packages. Move anything you actually use to EPEL 8 equivalents; remove the rest.
• MariaDB from MariaDB.org repos. Switch to cPanel's bundled MariaDB before upgrading.
• Custom kernels. Remove them — ELevate boots into the AlmaLinux 8 stock kernel.

Step 4 — Run the upgrade

leapp upgrade
reboot

The upgrade phase takes 30-60 minutes during which the box is offline. On reboot, the machine comes up in a temporary "upgrade environment" kernel, finalises the package swap, then reboots again into AlmaLinux 8. Total wall-clock from leapp upgrade to a healthy WHM login is typically 60-90 minutes.

Step 5 — Post-upgrade verification

# Confirm OS version
cat /etc/redhat-release   # should report AlmaLinux 8.x

# Re-run the cPanel updater
/scripts/upcp --force

# Verify Apache / LiteSpeed restarts cleanly
systemctl restart httpd     # or systemctl restart lsws

# Re-run AutoSSL across all accounts
/scripts/autossl_check --all

ImunifyAV / Imunify360, CloudLinux, and JetBackup all need their post-upgrade reconnect scripts run. Each vendor publishes the exact command — check their KBs before assuming they survived intact.

After the migration

A few things to do within the first week on the new OS:

• Audit yum repolist and remove any disabled CentOS 7 repos that snuck through.
• Check journalctl --list-boots for kernel panics during the cutover boot. If there's anything there, dig in before traffic gets heavier.
• Re-test backups. Restore a single account from your backup target to confirm the restore path still works on the new OS — backup tools sometimes have OS-version-specific paths that break silently.
• Plan the AlmaLinux 9 jump. AlmaLinux 8 is good until 2029, but cPanel's roadmap is pushing toward 9-and-newer. Don't go through a CentOS-7-to-8 migration only to be doing another one in 18 months — schedule the 8-to-9 move on the same calendar.

For volume migrations across a fleet of servers, contact sales — we have a migration support tier that includes paid AlmaLinux engineering hours.

Next steps

• Now on AlmaLinux? Layer CloudLinux OS on top for the per-user resource isolation cPanel doesn't provide natively.
• Moving to a different control panel altogether? See the cPanel-to-Plesk migration playbook for the cross-panel path.
• If post-migration SSL renewals start failing, work through the WHM AutoSSL failures decision tree — it's the most common post-migration ticket.