Why CentOS 7 is a problem now
CentOS 7 reached end of life on 30 June 2024 and no longer receives security updates. Running it exposes you to unpatched vulnerabilities and PCI DSS non-compliance. This guide explains the real risks and walks you through migration to AlmaLinux 9 or Ubuntu 24.04 LTS.
Why CentOS 7 is a problem now
CentOS 7 is out of support. There are no more security fixes, and the public repositories were moved to an archive. The next serious vulnerability will not be patched for CentOS 7, and if you handle card data you will fail PCI DSS on patch timeliness and EOL remediation. The way out is either a fresh server on a supported OS, which is what we recommend, or a careful two-step in-place upgrade.
This guide assumes you have a CentOS 7 server you can already reach over SSH and that you are deciding how to get off it. You do not need to be a Hostworld customer to follow it.
Before you start
- CentOS 7 reached end of life on 30 June 2024. The CentOS project says this directly. After that date there are no more updates. Its mirrors were removed from mirror.centos.org and archived on vault.centos.org. Those vault repos exist for reference. They do not receive fixes.
- Real-world impact: the OpenSSH "regreSSHion" bug (CVE-2024-6387) was disclosed on 1 July 2024. Red Hat shipped fixes for supported RHEL on 3 July 2024. CentOS 7, being EOL, received no official update. This is what EOL looks like in practice.
- Compliance impact: PCI DSS v4.0 requires critical patches within one month (Requirement 6.3.3). It also requires that you document vendor EOL and have an approved remediation plan for outdated tech (Requirement 12.3.4). That plan became a mandatory control on 31 March 2025. You cannot meet 6.3.3 without vendor patches, and running CentOS 7 without a documented and executed remediation plan conflicts with 12.3.4.
- There is no paid "ELS" for CentOS 7. Red Hat offered an Extended Life Cycle Support add-on for RHEL 7.9 customers through 30 June 2028. That applies to RHEL 7.9 only. It does not cover CentOS 7.
- How long you realistically have: if the system is internet-facing, you are on borrowed time. The next pre-auth remote flaw can hand over root. If you are in PCI scope, the answer is "you are already late". Treat migration as work to schedule now.
- Hostworld context: if you run your VPS with us, you manage it in Virtualizor from our client area. You can deploy a new AlmaLinux 9 or Ubuntu 24.04 VPS alongside the one you have, and use the VNC console if you need out-of-band access. A rebuild in Virtualizor is destructive. Rebuilding installs a fresh operating system over the existing disk and everything on that VPS is gone: files, databases, configuration, users. Never rebuild the CentOS 7 server you are migrating from. If you need help at any point, open a support ticket and we will look at your VPS with you.
Step 1: Decide where you are moving to
Your two stable target platforms on our London VPS line are AlmaLinux 9 and Ubuntu 24.04 LTS. Pick the one your applications support best and that your team is comfortable with.
- AlmaLinux 9 has security maintenance through May 2032, according to the AlmaLinux project.
- Ubuntu 24.04 LTS has standard maintenance to May 2029. Extended Security Maintenance runs to May 2034, and a Legacy add-on runs to May 2039.
If you want the closest continuity from a RHEL-like environment, AlmaLinux 9 is a straightforward choice. If your tooling expects Ubuntu, 24.04 LTS gives a long runway.
Step 2: Choose migration approach
You have two routes. Fresh build and migrate services and data. Or in-place major upgrade.
- Fresh build is the cleanest. Deploy a second VPS on AlmaLinux 9 or Ubuntu 24.04, bring services up there, test, then cut over. The CentOS 7 machine stays untouched and running the whole time, which is your rollback. This avoids years of drift and lets you retire CentOS 7 with confidence.
- In-place upgrade is possible from CentOS 7 to AlmaLinux 9, but it is a two-step path using the AlmaLinux ELevate tooling: CentOS 7 to AlmaLinux 8, then AlmaLinux 8 to AlmaLinux 9. A direct multi-major jump is not supported. Skipping the CentOS 7 repo switch to a vault mirror stalls the process. Expect to handle third-party and EPEL packages, and to remove leftover el7 packages before the 8 to 9 step.
Red Hat's Leapp guidance, which ELevate builds on, is clear: run a pre-upgrade analysis, expect "inhibitors" that intentionally stop unsafe upgrades, and have a full, restorable backup. Common blockers include active NFS mounts during upgrade, LUKS-encrypted devices, and insufficient GRUB embedding space on BIOS-boot systems. Problems created by an in-place major upgrade may require a clean reinstall to fix. Plan with that in mind.
If you can, prefer a fresh build. If you must upgrade in place, slow down, back up, and test the upgrade path on a clone.
Step 3: Build a new VPS on a supported OS
Deploy a new VPS in Virtualizor with AlmaLinux 9 or Ubuntu 24.04 on it, and leave the CentOS 7 server running while you prepare and test. Do not use the rebuild function on the CentOS 7 VPS to do this: a rebuild wipes that disk, and you would destroy the server you are migrating from before you have copied anything off it. Rebuild is only sensible on a VPS you have already finished with, or one that is empty.
This section summarises the method. For the click-by-click version of the panel work, start from our VPS guides, and open a support ticket if a screen does not match what you expect.
Update the new server fully
Start from the latest patched state before you put anything on the machine. On AlmaLinux 9 that is a full package upgrade with sudo dnf upgrade, which refreshes repository metadata and upgrades everything installed. On Ubuntu 24.04 it is sudo apt update to refresh the package index, then sudo apt full-upgrade to upgrade the packages, kernel included. Reboot afterwards if a new kernel was installed.
Check what OS you are on
Confirm the new server is running what you think it is before you migrate onto it. On both AlmaLinux and Ubuntu, cat /etc/os-release prints the operating system name and version from the standard release file. It is worth ten seconds to avoid discovering the wrong base image an hour later.
Prepare to copy data
Plan what to migrate: application files, configuration, logs you must retain, and databases. For files, rsync over SSH is the reliable choice, because it preserves permissions and copies only the differences, so you can run it more than once and the final pass at cutover is short. For databases, use your database's native export and import process for your stack, then validate the data on the new server rather than assuming the import worked.
Recreate services and test
Recreate your services on the new server and test them while traffic still points to the old one. Confirm that logging, backups and monitoring work on the new OS. When you are happy, plan your cutover window. Update DNS or your load balancer to direct users to the new server.
If you host with us and want a second VPS for the migration window, you can order one here: London VPS. You manage the VPS lifecycle in Virtualizor from our client area.
Step 4: If you must upgrade CentOS 7 in place
If a fresh build is not possible, follow the two-step path documented by the AlmaLinux project. Do not attempt a direct 7 to 9 jump. Read the ELevate documentation alongside these points rather than working from this summary alone.
- Back up in a way you can restore. Take a full, restorable backup and verify it. Plan how you will roll back if the upgrade leaves the system unbootable. Red Hat's own guidance notes that some issues created by a major in-place upgrade require a clean reinstall to resolve.
- Switch CentOS 7 YUM to a vault mirror. Because the normal CentOS 7 repos are offline, the ELevate guide instructs switching YUM to use an archived vault repo first. They provide an
el7.repofile for this. Skipping this step stalls the upgrade because required packages will not resolve. - Run the ELevate pre-upgrade checks and fix inhibitors. Expect the process to stop you if it detects unsafe conditions. Common examples include active NFS mounts, LUKS-encrypted devices, or insufficient GRUB embedding space on BIOS-boot systems. Clear these before proceeding.
- Perform the 7 to 8 transition. Follow the ELevate documentation for the CentOS 7 to AlmaLinux 8 step. Reboot when prompted and validate that the system comes back, services start, and the package set is consistent.
- Clean up el7 leftovers and third-party repos. ELevate calls out handling of EPEL and removing leftover el7 packages before the 8 to 9 step. Resolve these so the next transition is not blocked.
- Perform the 8 to 9 transition. Use the documented AlmaLinux 8 to 9 ELevate path. Reboot and retest thoroughly.
- Update fully on the new OS. Once you land on AlmaLinux 9, bring the system current with
sudo dnf upgradeand check your services again.
If anything blocks you during planning or testing, open a support ticket. Tell us what you have tried and where it failed. We will review options for your VPS and help you choose a safe path.
Step 5: Re-check security posture and compliance
Once you are on a supported OS, patch cadence is back in your control. Bring the host up to date and put regular updates on a schedule: sudo dnf upgrade on AlmaLinux 9, or sudo apt update followed by sudo apt full-upgrade on Ubuntu 24.04.
Document the move in your PCI materials if you are in scope. Requirement 6.3.3 is met when you install critical patches within one month of release, which you can now do because vendor fixes exist. Requirement 12.3.4 expects you to review technology at least annually, document vendor EOL, and have an approved plan to remediate. Your migration is that remediation. Keep the record.
Why this matters, in plain terms
- No fixes after EOL. CentOS 7 has had no security updates since 30 June 2024. The OpenSSH regreSSHion bug on 1 July 2024 was a pre-auth RCE. Supported platforms received coordinated patches within days. CentOS 7 did not. That pattern will repeat.
- Archived repos are a dead end. The move from mirror.centos.org to vault.centos.org preserves history. It does not provide fixes. You cannot patch your way out of EOL on CentOS 7.
- Compliance deadlines are real. PCI DSS v4.0's one-month patch window and the EOL remediation control are both active. CentOS 7 is now a compliance problem, not a theoretical one.
- There is no CentOS 7 ELS. Buying time is not an option on CentOS. Red Hat's ELS only covered RHEL 7.9.
What next
If you want a clean start, deploy a new VPS on AlmaLinux 9 or Ubuntu 24.04 and migrate on your schedule: London VPS. You manage power, rebuilds, VNC console and ISO mounting in Virtualizor from the Hostworld client area, and rebuild stays destructive, so keep it away from anything you still need.
For broader context and related tasks, see our VPS guides. If you hit a blocker at any point, open a support ticket so we can review your VPS and advise on a safe path.
The next step in this playbook is to plan your cutover and rehearse it. Write down the order you will stop services, copy the last changes, and update DNS or the load balancer. Then test it on a quiet window.
Common questions
Can I keep running CentOS 7 if the server is behind a firewall?
A firewall helps reduce exposure. It does not remove it. After EOL, there are no vendor fixes. Public bugs like CVE‑2024‑6387 show what happens next: supported OSes patch, EOL systems do not. If an exposed service is reachable, you remain at risk. Move to a supported OS.
Can I buy extended support for CentOS 7?
No. Red Hat offered Extended Life Cycle Support for RHEL 7.9 customers from 1 July 2024 to 30 June 2028. It does not apply to CentOS 7.
What happens to yum updates after EOL?
When a CentOS release reaches EOL, its repos are removed from mirror.centos.org and archived to vault.centos.org. Those vault repos do not receive updates. If you are still on CentOS 7, there are no new security fixes to install.
Is a direct 7 to 9 in‑place upgrade supported?
No. The documented path is two steps using AlmaLinux ELevate: CentOS 7 to AlmaLinux 8, then AlmaLinux 8 to AlmaLinux 9. Skipping steps risks an inconsistent or unbootable system. The tooling intentionally stops you when unsafe conditions are detected.
How long can I postpone this if I am not in PCI scope?
You still run without vendor patches. That is a security risk regardless of compliance. The pragmatic answer is to schedule the move now while you can plan it, rather than during an incident.
Was this guide helpful?
0 people found this helpful