Migrating in place or rebuilding: which is safer?

This picks up from a server you can already reach over SSH.

Build a new server and migrate. It is safer and easier to roll back. In place upgrades across major versions of CentOS often go wrong because kernel, networking, firewall, SELinux and language runtime changes stack up, then one failure leaves you with an unbootable or inconsistent system.

An in place upgrade can be reasonable if you have a full image backup, console access, a planned outage window, and you are ready to fix everything the tooling flags. If that is not you, rebuild and move across.

Before you start

• CentOS Linux 7 reached end of life on 30 June 2024. There are no security updates. Your plan must end with a supported operating system such as AlmaLinux 9 or Ubuntu 24.04.
• Direct CentOS 7 to 9 upgrades are not supported. The supported path is stepwise: 7 to 8, then 8 to 9. AlmaLinux’s ELevate uses leapp to perform this, and you must split it into those steps.
• If you run cPanel and uptime matters or you only have per account backups, cPanel’s own advice is to migrate to a new server using WHM’s Transfer Tool instead of upgrading in place.
• Always take a full backup before you touch a production system. Prefer an image-level backup off the server. Back up your databases too. Plan where you would restore them if you had to.
• Have console access ready in case the network does not come back after a reboot. With a Hostworld VPS you can use the VNC console in Virtualizor from the client area.
• Disable automated health checks and watchdogs during an in place upgrade. Red Hat warns that interruptions during an upgrade can cause system loss.
• Expect blockers. Known upgrade inhibitors include full disk or partition encryption, software RAID, and NIC or driver issues. The leapp preupgrade report will list them and you must fix them first.
• Expect behaviour changes. Firewalld moved to an nftables backend in Enterprise Linux 8, so legacy iptables scripts often stop working. Python 2 and the unversioned /usr/bin/python are gone, so scripts that rely on them will break. SELinux is set to permissive during leapp upgrades and you must return it to enforcing afterwards.
• For Ubuntu LTS upgrades, the supported path is do-release-upgrade. Third party repositories and PPAs are disabled during a release upgrade and are a common cause of failures if left enabled. LTS to LTS upgrades are usually enabled after the .1 release, and you can force earlier upgrades with -d if you accept the risk.
• If you choose a rebuild, take care during installation. Options such as Erase disk and install on Ubuntu or deleting partitions in a RHEL-family installer will destroy data on that disk. Double check targets and keep backups off the host before you start.

Step 1: Decide your path

Choose one of these and plan to the end of it.

• Rebuild and migrate. Choose this by default. It gives you a clean state on AlmaLinux 9 or Ubuntu 24.04, lets you test before you cut over, and makes rollback clear. If you use cPanel, this aligns with cPanel’s recommendation to use the WHM Transfer Tool when uptime is important or your backups are only per account.
• In place upgrade. Choose this only if all of these are true: you can accept an outage window, you have recent full image backups, you can reach a console, you are ready to fix every leapp inhibitor reported, and you have validated that your applications, runtimes and databases are compatible with AlmaLinux 8 and 9 or Ubuntu 24.04.

Step 2: Back up and plan your recovery

Backups are your way out if anything fails.

• Make a full system backup that you can restore to a known-good state. Store it off the server.
• Back up your databases. The MariaDB project advises full backups before a major version jump. You will run mariadb-upgrade after the OS upgrade to update system tables and compatibility metadata.
• Note the services and ports you expect to be open and list the firewall rules that allow them. If you have custom iptables scripts, expect to adapt them for the nftables backend in Enterprise Linux 8 and later.
• Plan your testing. Decide how you will verify that your websites, applications, cron jobs, email and control panels all work after the move.

Step 3: Rebuild route: Provision the new server

You are creating the new home for your workloads.

• For a Hostworld VPS, log in to the client area and use Virtualizor to create a new VPS with AlmaLinux 9 or Ubuntu 24.04. You can also mount a custom ISO from Virtualizor if you bring your own image. If you need a server, see our Linux VPS page.
• If you use an installer ISO, read each storage prompt carefully. Options that erase disks or delete partitions will destroy data on the selected drive.
• Harden the base installation to match your standards. Install only the software you need. Configure SSH access and a firewall policy that you can explain.

Step 4: Rebuild route: Migrate services and data

Move your workloads across in a way you can roll back.

• For cPanel servers, use WHM’s Transfer Tool to move accounts to the new system. cPanel recommends new server migration when uptime is critical or backups are per account.
• Restore databases, files and configuration. Run application migrations and database upgrades as required by your software.
• Cut over your traffic in a controlled way. If you are moving websites into Hostworld cPanel, change your domain’s nameservers at your registrar to point at Hostworld. Use these exactly: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk, ns4.serverworld.uk.
• Keep the old server powered on but quiescent until you are sure the new one is running as expected.

Step 5: In place route on CentOS 7: upgrade to AlmaLinux 9 with ELevate

This is the stepwise route from CentOS 7 to AlmaLinux 8 then AlmaLinux 9. It is supported as a two stage process. Read the leapp report carefully at each stage and do not continue until blockers are cleared. Expect to use your Virtualizor VNC console if networking does not return after a reboot.

5.1 Move CentOS 7 to AlmaLinux 8

Swap to the CentOS 7 vault mirror for updates. This points yum at the archived CentOS 7 repositories so you can complete final updates.

AlmaLinux

sudo curl -o /etc/yum.repos.d/CentOS-Base.repo https://el7.repo.almalinux.org/centos/CentOS-Base.repo

Update all packages, then reboot into the updated CentOS 7 kernel and userspace.

AlmaLinux

sudo yum upgrade -y && sudo reboot

Add the ELevate testing repository and import its GPG key. This gives you the leapp packages and metadata needed for the transition to AlmaLinux 8.

AlmaLinux

sudo curl https://repo.almalinux.org/elevate/testing/elevate-testing.repo -o /etc/yum.repos.d/elevate-testing.repo
sudo rpm --import https://repo.almalinux.org/elevate/RPM-GPG-KEY-ELevate

Install the leapp tooling and AlmaLinux data files, then perform a preupgrade. The preupgrade analyses your system and writes a report of blockers and risks to /var/log/leapp/leapp-report.txt. Fix every inhibitor it lists.

AlmaLinux

sudo yum install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade

Run the upgrade when the report is clear, then reboot. You will see an ELevate-Upgrade-Initramfs entry in GRUB during the process.

AlmaLinux

sudo leapp upgrade && sudo reboot

5.2 Move AlmaLinux 8 to AlmaLinux 9

Add the ELevate testing repository and key again on AlmaLinux 8. This gives you the leapp metadata for the 8 to 9 transition.

AlmaLinux

sudo curl https://repo.almalinux.org/elevate/testing/elevate-testing.repo -o /etc/yum.repos.d/elevate-testing.repo
sudo rpm --import https://repo.almalinux.org/elevate/RPM-GPG-KEY-ELevate

Install the leapp packages for this stage, then run a preupgrade. Common inhibitors include the removal of legacy network-scripts in RHEL 9 and AlmaLinux 9, and the need to set AllowZoneDrifting to no. Follow the report and migrate to NetworkManager if you still rely on the old scripts.

AlmaLinux

sudo yum install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade

Run the upgrade and reboot when you have cleared the inhibitors.

AlmaLinux

sudo leapp upgrade && sudo reboot

During leapp upgrades SELinux is set to permissive. After the system boots on AlmaLinux 9, return SELinux to enforcing mode, check for denials, and relabel if required, as per the Red Hat guidance.

If leapp fails due to overlay storage exhaustion, ELevate sets LEAPP_OVL_SIZE to 3000 by default. You can adjust this according to the ELevate documentation if you see that error in the logs.

Step 6: In place route on Ubuntu: upgrade to 24.04 LTS

Use Ubuntu’s supported release upgrade tool. It runs checks, disables third party repositories during the upgrade, and prompts when it needs your decision. LTS to LTS upgrades are usually offered after the .1 point release. You can force an earlier upgrade with -d if you accept the risk.

Check for and start a standard LTS upgrade. This invokes the non interactive upgrader that will lead you through prompts in your terminal.

Ubuntu

sudo do-release-upgrade

If you intend to upgrade before the .1 point release and you understand the risk, run the upgrader with the development switch.

Ubuntu

sudo do-release-upgrade -d

Third party repositories and PPAs are disabled during an Ubuntu release upgrade. Review them after the upgrade and re enable only those that are compatible with 24.04.

Step 7: Post upgrade checks that catch the common failures

These are the areas that most often break in in place upgrades across major versions. Build time invested here avoids the late night debugging session.

• Firewall. Firewalld now uses the nftables backend on Enterprise Linux 8 and later. Legacy iptables rules and helper scripts often do not map cleanly. Review your policy and test that the correct ports are open. Be ready to rewrite old scripts.
• SELinux. Leapp sets SELinux to permissive during the upgrade. You must return it to enforcing afterwards, then check audit logs for denials and adjust contexts or booleans as needed per the Red Hat guides.
• Python. The unversioned /usr/bin/python is not present by default in Enterprise Linux 8 and later, and Python 2 has been removed. Audit your scripts and daemons for hard coded calls to python and update them to the correct interpreter.
• Networking. The legacy network-scripts package is not supported on RHEL 9 and AlmaLinux 9. Migrate to NetworkManager and confirm that interface names match what your services expect. NIC names are usually preserved but can change. If they do, reconfigure your network accordingly using your console, not SSH.
• Databases. After a major OS and engine upgrade, run the database upgrade utility so engine metadata matches the new binaries. This is required for MariaDB after a major jump. Always take backups first.

AlmaLinux

Run the MariaDB upgrade utility to update system tables and compatibility metadata after the OS upgrade.

sudo mariadb-upgrade

Ubuntu

Run the MariaDB upgrade utility to update system tables and compatibility metadata after the OS upgrade.

sudo mariadb-upgrade

Check the leapp report at /var/log/leapp/leapp-report.txt for any remaining warnings or recommendations and address them before you consider the upgrade complete.

Step 8: Validate and put traffic back

Test everything before you declare victory.

• Confirm you can reach the server over the network and via the Virtualizor VNC console in case of issues.
• Verify websites, control panels, mail, cron jobs and API endpoints behave as expected. Compare against the checklist you wrote before starting.
• If you rebuilt, switch DNS or change your upstream configuration so traffic goes to the new server. If you host websites on Hostworld cPanel, ensure your domain’s nameservers point to ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk.
• Keep the old server or snapshot long enough to be confident you do not need it, then decommission securely.

What next

If you are ready to build or resize capacity, see our Linux VPS range. If you want to understand more about running and recovering a VPS at Hostworld, browse our VPS guides.

If you need a hand at any point, open a support ticket and we will help you plan the next action. If you are continuing the playbook, the next step is to migrate application data and cut DNS over to the new host.