Introduction 

CentOS Linux 7 reached its end-of-life (EOL) on June 30, 2024. This means no further security updates or bug fixes will be released for CentOS 7, posing increasing risk to production systems over time. To maintain a secure and supported environment, organizations should migrate CentOS 7 servers to a supported enterprise Linux OS. Rocky Linux and AlmaLinux have emerged as the leading community-driven successors to CentOS, providing binary-compatible replacements for Red Hat Enterprise Linux (RHEL) without licensing costs. This guide outlines a comprehensive strategy to migrate production CentOS 7 servers to Rocky Linux or AlmaLinux with minimal downtime and risk, including a comparison of Rocky vs. Alma for production use, pre-migration best practices, in-place upgrade steps using the ELevate tool, and post-migration validation for long-term stability.

Rocky Linux vs. AlmaLinux for Production

Both Rocky Linux and AlmaLinux were founded to fill the void left by CentOS’s change in direction, and they are largely similar in terms of features and compatibility. Below is a comparison of key factors for production use:

• Community & Governance: Rocky Linux is managed by the Rocky Enterprise Software Foundation (RESF), a public benefit corporation led by CentOS co-founder Gregory Kurtzer to ensure community control of the project. AlmaLinux is stewarded by the AlmaLinux OS Foundation, a 501(c)(6) non-profit backed initially by CloudLinux (which pledged \$1M annually). Both projects have multiple sponsors and an open governance model, preventing any single entity from taking over (Rocky has ~12 sponsors and partners, AlmaLinux lists 20+ backers as of late 2023). This strong community support means that both distros are developed in the open with input from users and industry stakeholders.

  
  

• Enterprise Readiness & Support: Both Rocky and AlmaLinux are considered enterprise-ready distributions. They provide the necessary components for production: a rich package repository, frequent security patching, regular (minor) updates, and thorough documentation. Each has commercial support options either through their founding organizations or third parties. For example, AlmaLinux’s founding company CloudLinux offers support, and Rocky Linux’s partner CIQ provides professional services; third-party vendors (like OpenLogic) also offer 24/7 enterprise support for both distros. In practice, enterprises have successfully deployed both OSes in mission-critical environments – either choice can be viable for long-term stability.

  
  

• Release Cycle & Updates: Rocky Linux and AlmaLinux aim to track RHEL’s release cycle closely. Historically, AlmaLinux was very quick to release new versions (it was first to release a RHEL 8 clone in 2021), and often had a slightly shorter lag for updates. For example, AlmaLinux generally shipped RHEL 8.x point releases within days (e.g. AlmaLinux 8.7 came ~4 days after RHEL, Rocky 8.7 ~9 days after). Rocky Linux 9.0 was an outlier with a longer delay (~57 days) due to Rocky overhauling its build system (introducing the Peridot build infrastructure). Since then, both distros have kept release lags to a minimum – recent minor releases and patch updates for Rocky and Alma are typically available within a day or two of Red Hat’s updates. This means you can expect timely security patches and version updates on both, which is crucial for production servers.

  
  

• Compatibility: Both AlmaLinux and Rocky Linux were created to be binary-compatible drop-in replacements for CentOS/RHEL. In practice, software and services that ran on CentOS 7 (or RHEL) will run on Rocky or AlmaLinux 8/9 with no or minimal changes. A notable difference arose in mid-2023 when Red Hat limited access to RHEL source code. Rocky Linux remained committed to bug-for-bug compatibility with RHEL, continuing to use RHEL sources (via various means) to ensure packages are identical to upstream. AlmaLinux adjusted its approach slightly – it no longer guarantees to be an exact clone, but promises binary compatibility (i.e. applications built for RHEL will run on AlmaLinux). In practice, this distinction has not resulted in significant divergence in behavior; both OSes are close substitutes for RHEL. Both Rocky and Alma use the same versions of libraries and software as RHEL, and even share many of the same patches. They also have robust mirror networks (hundreds of worldwide mirrors for each, so updates are reliably accessible).

  
  

Summary: From a production standpoint, Rocky Linux and AlmaLinux are more alike than different. Both are stable, well-supported by community and vendors, and suitable for enterprise use. Your choice may come down to organizational preference or specific support partnerships – e.g. if you value Rocky’s founding team’s philosophy or AlmaLinux’s backing by CloudLinux. Importantly, both will allow you to continue with a RHEL-like environment and seamless updates beyond CentOS 7’s lifespan.

Pre-Migration Best Practices and Planning

Migrating a production server requires careful preparation to minimize downtime and avoid surprises. Before attempting an in-place upgrade from CentOS 7, complete the following steps:

• Comprehensive Backups: Create a full backup or snapshot of your server before migrating. This includes system state, application data, and configurations. Ideally, perform a bare-metal backup that could restore the entire server if needed. If using VMs or cloud instances, take a snapshot of the instance. Also back up critical databases and application data separately (e.g. dump your MySQL/PostgreSQL databases). Verify your backups’ integrity. In case the upgrade fails or something goes wrong, you must have a way to restore service quickly.

  
  

• Testing in a Sandbox: It is highly recommended to perform a trial run on a non-production copy of the server (such as a cloned VM or staging environment) before upgrading the production system. This allows you to catch any application-specific issues or conflicts in a safe environment. Test the entire migration process in the sandbox, and ensure your applications come up correctly on Rocky/AlmaLinux. This practice can reveal issues that documentation might not cover, especially if your server has uncommon software or configurations.

  
  

• Update and Health-Check the CentOS 7 System: On the CentOS 7 server, apply all pending updates (yum update -y) so that it’s running the latest packages available for EL7. This ensures a smoother upgrade path with all recent bug fixes in place. If CentOS 7’s official mirrors are already offline (after EOL), switch your YUM repos to the CentOS Vault or a trusted mirror (e.g. AlmaLinux provides a CentOS 7 mirror repo). After updating, reboot the server to ensure it boots cleanly on the latest kernel and to clear any memory fragmentation – a fresh reboot also ensures no stale services will interfere with the migration. Confirm there is sufficient disk space (especially in /var and /usr where packages/temp files may be stored during upgrade) – at least a few GB of free space is recommended for the leapp data and new packages.

  
  

• Inventory Applications and Services: Take note of what software is installed and running on the server. Ensure that those packages are available or have equivalents in Rocky/AlmaLinux 8 or 9. Most CentOS 7 packages have direct analogues in EL8/EL9, but some older or deprecated packages might not exist on the newer OS (for example, Python 2 is not installed by default on EL8+). If you have any 32-bit packages or very old software, research their compatibility with EL8/9. It may be necessary to update certain applications (for instance, migrating from PHP 5 to PHP 7+ or from an older database version to a newer one) as part of the OS upgrade plan. Identify these ahead of time so you can plan accordingly.

  
  

• Third-Party Repositories and Custom Packages: Review any external YUM/DNF repositories configured on CentOS 7 (for example, EPEL, REMI, PostgreSQL PGDG, Docker, etc.). Temporarily disable or remove third-party repos that are not needed for the OS migration to prevent the upgrade tool from getting confused by packages it cannot update. For instance, if you have the PostgreSQL PGDG repo enabled, consider disabling it and stopping the PostgreSQL service before upgrading, since the upgrade might not handle those non-standard packages gracefully. You can later install the EL8/EL9 version of those packages or use the appropriate repo for the new OS. The ELevate project does support some popular third-party repos (EPEL, MariaDB, PostgreSQL, etc.) by including their data in the process, but it’s safest to consult ELevate’s documentation to see what is supported and plan to handle others manually. Remove any packages you know won’t be compatible or needed on EL8/9 to streamline the upgrade.

  
  

• Kernel Modules and Drivers: If you use any proprietary or extra kernel modules (e.g. drivers for specific hardware or third-party kernel modules), check their compatibility with the new kernel version in EL8/EL9. For example, CentOS 7’s kernel is 3.10-based, while EL8 uses 4.18 and EL9 uses 5.14 kernels. Most standard devices will be fine, but if you have something like third-party RAID card drivers, ensure you can get a version for the new OS or that the new kernel supports it out-of-the-box. It’s wise to remove any obsolete or unused kernel modules prior to upgrade (the leapp tool often flags certain modules like pata_acpi to be removed).

  
  

• Maintenance Window & Access: Schedule a maintenance window for the migration that accounts for potential setbacks. An in-place upgrade from 7→8→9 can take some time (possibly 30 minutes to a couple of hours, including reboots and package installation). Plan for a window with ample cushion. During the upgrade, the server will reboot multiple times and be offline while the upgrade runs, so users should be notified of the expected downtime. Ensure you have console access (e.g. VMware console, IPMI/iDRAC, or a physical console) in case networking doesn’t come up or SSH fails during the process – you don’t want to be locked out mid-upgrade. Also, if the server is critical and cannot tolerate long downtime, consider a blue-green deployment (setting up a new Rocky/Alma server in parallel and migrating applications over) as an alternative approach. However, this guide focuses on in-place upgrades to reduce reconfiguration work.

  
  

• Fallback Plan: Despite best efforts, in-place major-version upgrades carry some risk. Prepare a rollback plan. This could mean having a full image backup to restore the server to CentOS 7 if needed, or the ability to quickly redeploy a CentOS 7 VM from template and restore data. At minimum, keep the backups handy and ensure someone is available to assist if things go wrong. In high-availability setups, you might remove the node from a cluster or load balancer, perform the upgrade, and if it fails, rebuild the node separately while others handle the load. Knowing that you can recover will make the process much less stressful.

  
  

By thoroughly planning and following these steps, you set the stage for a smoother migration. Now, onto performing the in-place upgrade with minimal disruption.

In-Place Upgrade Process with AlmaLinux ELevate (CentOS 7 → Rocky/AlmaLinux)

The recommended method to transition from CentOS 7 to Rocky Linux or AlmaLinux is to use the ELevate tool, which leverages Red Hat’s Leapp framework for in-place upgrades across major versions. ELevate (provided by AlmaLinux) extends Leapp’s capabilities to allow switching to a different RHEL-based distro during the upgrade. Essentially, you will upgrade CentOS 7 to an interim Rocky/AlmaLinux 8, and optionally then to 9. Below are the steps to perform this migration:

1. Prepare Repositories and Update CentOS 7: Ensure your CentOS 7 system is fully updated on the latest packages. If the standard CentOS 7 repos are unavailable due to EOL, point your system to a CentOS Vault mirror or the AlmaLinux provided mirror for CentOS 7. For example, AlmaLinux offers a replacement CentOS-Base.repo that can be installed via:

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

After configuring a working repo, run sudo yum upgrade -y to get all the latest CentOS 7 updates, then reboot the server (sudo reboot). Having the system updated ensures compatibility with the upgrade tooling.

2. Install ELevate (Leapp) Packages: Add the ELevate project repository and install the required upgrade tools. AlmaLinux provides a convenient RPM to set up the ELevate repo and GPG key:

   sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm

This single command installs the elevate-release package which configures the necessary YUM repo for ELevate. Next, install the Leapp upgrade utility and the migration data package for your target distribution (Rocky or AlmaLinux):

   # For migrating to Rocky Linux 8:
   sudo yum install -y leapp-upgrade leapp-data-rocky  
   # For migrating to AlmaLinux 8 (if that’s your choice):
   sudo yum install -y leapp-upgrade leapp-data-almalinux

These packages include the Leapp framework and metadata specific to the target OS, telling the upgrader how to perform the transition. (Note: Other leapp-data-<distro> options exist as well, such as centos, oraclelinux, eurolinux, etc., but here we focus on Rocky/AlmaLinux.)

3. Run Pre-Upgrade Checks: Before actually upgrading, perform a dry run to identify any issues. Execute:

   sudo leapp preupgrade

This will run numerous checks and produce a report of potential problems without making changes to the system. The output and logs (found under /var/log/leapp/) will include:

• leapp-report.txt – a summary of detected problems and recommended solutions.

  
  

• answerfile – a file containing questions (with True/False answers) that the tool needs resolved to proceed.

  
  

• preupgrade logs – detailed log of the check. Review these outputs thoroughly. Common issues on CentOS 7 that inhibit the upgrade (and how to fix them) include:

  
  

• Kernel module conflicts: For instance, the old IDE driver pata_acpi is often flagged as incompatible. Remove it with sudo rmmod pata_acpi before proceeding.

  
  

• SSH configuration: The upgrader might warn if root login is disallowed (since it may need root access during the process). Ensure SSH permits root login (at least temporarily) by adding PermitRootLogin yes to /etc/ssh/sshd_config. You can do this quickly with:

  
  

   echo "PermitRootLogin yes" | sudo tee -a /etc/ssh/sshd_config
  

  
  

  (After migration, you can revert this setting if it was intentionally disabled for security.)

  
  

• Obsolete PAM modules: CentOS 7’s PAM stack might include modules like pam_pkcs11 that are removed in EL8. The leapp answerfile may have a question about removing the PAM PKCS#11 module. You can pre-answer it by running:

  
  

   sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True
  

  
  

  This records that you agree to remove that module during the upgrade.

  
  

• Third-party software: As noted earlier, some services should be turned off or configs adjusted. For example, if a PostgreSQL service from PGDG is running, stop it (sudo systemctl stop postgresql) and disable its YUM repo (you can manually edit the repo file or use sed as shown in ELevate guides). The preupgrade might flag such services if it detects them. Also, if using Docker, ensure Docker CE is a version that’s supported on EL8 or plan to reinstall after upgrade (ELevate can handle Docker CE in many cases).

  
  

  Apply all suggested fixes from the report. The AlmaLinux wiki highlights that the above three fixes (removing pata_acpi, enabling root SSH, confirming PAM change) are among the most common for CentOS 7, but do review the entire leapp-report.txt for any other issues specific to your system. After making changes, run leapp preupgrade again. Repeat this process until the pre-upgrade check completes without any “Upgrade Inhibited” errors (i.e. no blocking issues remain). Only proceed once you have a clean bill of health from the pre-check.

  
  

1. Run the Upgrade: When the system is prepared and all inhibitors are cleared, initiate the full upgrade:

   sudo leapp upgrade

This command will download and install all packages for the new OS (Rocky/Alma 8) while making necessary adjustments. It can take some time to complete. Monitor the console output and be patient. If the process encounters an error and stops, do not reboot immediately. First, read the error or check /var/log/leapp/leapp-upgrade.log. Common issues might include specific packages that couldn’t be processed. For example, the PhoenixNAP guide notes that on rare occasions, certain packages like make-devel or rocky-logos (if migrating to Rocky) could cause conflicts and need to be removed before retrying. Remove any problematic package as directed (using dnf remove <package>), then run leapp upgrade again.

Once leapp upgrade finishes successfully, you will be prompted (or may simply need) to reboot the system. Reboot the server to initiate the final stage of the upgrade. During boot, the GRUB menu will have a special entry called ELevate-Upgrade-Initramfs. By default, it will auto-select this entry (you can also manually select it if you have console access) and boot into the upgrade environment. At this point, the system is essentially running a minimal RAM-disk OS that completes the package swap and migration. You’ll see the console messaging as it upgrades packages and applies changes. The system will automatically reboot one or more times as it transitions to the new OS kernel and completes configuration.

Note: It’s normal for the system to reboot a couple of times during this phase – do not intervene unless it fails to come back after an extended period. If you’re watching via console, wait until you eventually see the GRUB menu show an entry for Rocky Linux or AlmaLinux.

After the final reboot, GRUB should now default to booting into Rocky Linux 8 or AlmaLinux 8 (depending on your target). Log in as root (same password as before) or another admin user. Congratulations – at this stage, your CentOS 7 has been migrated in-place to the new distribution!

5. (Optional) Upgrade to Version 9: If you wish to move to Rocky Linux 9 or AlmaLinux 9 for a longer support lifecycle, you’ll need to perform a second in-place upgrade (from EL8 to EL9). The ELevate tool can handle this as well, but note that Leapp does one major version at a time (you can’t jump directly 7→9, which is why we first went to 8). Before upgrading to 9, it’s wise to do some cleanup on the 8 system: remove any leftover CentOS 7 packages (as detailed in post-migration steps below) and ensure the system is fully updated on the 8.x release. Also, Leapp might have added an exclude= line in your YUM/DNF config to prevent certain packages from updating during the process (like leapp itself). You should clear any excludes now. For example, run:

   sudo yum config-manager --save --setopt exclude=''

to remove any exclude settings from yum/dnf (alternatively, manually edit /etc/yum.conf and /etc/dnf/dnf.conf to remove excludes). Then install the ELevate repo (if not already present on the new OS) and the Leapp data for the next OS. On your Rocky/AlmaLinux 8 system:

   sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
   sudo yum install -y leapp-upgrade leapp-data-rocky   # or leapp-data-almalinux for AlmaLinux 9

The process is essentially the same as before, now targeting the 9.x release. Run leapp preupgrade on the Rocky/Alma 8 system, fix any issues (fewer are usually encountered going 8→9, but do check, e.g. firewalld or network scripts changes), then run leapp upgrade and reboot. The system will again boot through the ELevate initramfs and emerge as Rocky Linux 9/AlmaLinux 9. Ensure the upgrade was successful by checking the new OS version after final reboot. At this point, your server is on a supported RHEL9-era distribution, which will receive updates for many years.

Post-Migration Validation and Cleanup

After a successful migration, it’s crucial to verify the system’s integrity and perform cleanup to ensure long-term stability:

• Verify OS Release: Confirm the system is now running the target OS. For example:

  cat /etc/redhat-release

This should show the new distribution and version (e.g., Rocky Linux release 8.8 or AlmaLinux 8.8). You can also check hostnamectl or cat /etc/os-release for more details. Verifying the OS ensures the upgrade indeed completed. Additionally, check the kernel version (uname -r) to see that you’re on the expected EL8/EL9 kernel.

• Validate Critical Services: Inspect the status of key services and applications. Services that were enabled on CentOS 7 should have been preserved through the upgrade (Leapp tries to keep systemd unit enablement the same). Run systemctl list-units --state=failed to see if any services failed to start. Common things to check:

  
  

• Web servers (Apache/Nginx), application servers, etc. – ensure websites or apps are running normally.

  
  

• Databases – verify MySQL/MariaDB or PostgreSQL is running and data is intact. You may need to run any required mysql_upgrade or equivalent if the DB major version changed.

  
  

• Language runtimes – if you rely on Python, Ruby, Java, etc., confirm the expected version is present and your apps are okay with it. (For example, CentOS 7’s default Python was 2.7, AlmaLinux 8’s default is Python 3.6+; if you had scripts relying on python2, you might need to install python2 package on EL8 or adjust to Python 3.)

  
  

• Network and Firewall: Verify network connectivity. Check that your IP configuration (especially if you had custom network scripts in /etc/sysconfig) carried over. RHEL8+ uses NetworkManager by default (as did CentOS 7, but the config format changed to nmcli and keyfile if using new style). If the upgrade found an old ifcfg for an unsupported device type, it might have disabled it. Ensure all network interfaces came up properly. Also, check the firewall (firewalld) status: CentOS 7 firewalld “AllowZoneDrifting” setting is obsolete; the upgrade might have turned it off. Make sure your firewall rules are as expected for the new version.

  
  

• Remove Orphaned Packages: The upgrade may leave behind some CentOS 7 packages that do not have a direct equivalent in the new OS. These “orphaned” packages usually have el7 in their version string. It’s good practice to remove them to clean the system. You can list any lingering EL7 packages with:

  
  

  rpm -qa | grep -E 'el7[.-]'

Review the list. For any that are not needed or meant to be replaced, remove them. A one-liner to remove all at once (use with caution, and perhaps take a backup of rpm database first) is:

  rpm -qa | grep -E 'el7[.-]' | xargs sudo rpm -e

This will erase all packages marked as EL7. Ensure you do not remove anything critical inadvertently – most EL7 leftovers might be -devel packages, old kernels, or centos-specific branding packages. Removing them prevents potential conflicts and frees space.

• Repository Clean-up: Check your repository files under /etc/yum.repos.d/. The migration process should have added the appropriate Rocky or AlmaLinux repository definitions (e.g., files like Rocky-Base.repo or almalinux.repo etc.). Remove or move any old CentOS 7 .repo files to a backup location so they don’t interfere. If you disabled third-party repos earlier, now is the time to install/enable the EL8/EL9 versions of those. For EPEL on AlmaLinux/ Rocky, you’d install the new epel-release rpm. For any application-specific repos (like a monitoring agent or database), get the EL8/9 repo file from the vendor. Verifying repos now ensures that future dnf update commands pull from the correct sources. Also, if any exclude= lines were added in yum.conf or dnf.conf (as mentioned in the upgrade steps), ensure those are cleared so updates aren’t accidentally blocked.

  
  

• System Configuration Changes: Be aware of some config differences between CentOS7 and EL8/9:

  
  

• Chrony vs NTP: If you were using ntpd for time sync on CentOS 7, note that RHEL8/9 uses chronyd by default. The upgrade may have replaced ntpd with chrony. Ensure your time sync is working (chronyc sources). If needed, configure chrony similarly to your old NTP config.

  
  

• Logging: RHEL8 uses rsyslog (same as 7) and also journald – mostly similar, but check that any custom rsyslog rules were preserved.

  
  

• Networking: If you had custom network-scripts, verify they still apply or convert them to NetworkManager configurations. The old ifcfg- scripts are still supported in RHEL8, but if a device type was deprecated (e.g. old VLAN or bonding syntax), you might need to update it.

  
  

• SELinux: Should remain enabled/enforcing (matching previous state). If you had custom SELinux modules or booleans, verify they are in place. Relabel the filesystem (touch /.autorelabel && reboot) if there were many changes, to be safe.

  
  

• Crontabs / systemd timers: Ensure scheduled tasks (cron jobs or systemd timers) are still present and active.

  
  

• Read the Upgrade Report: The leapp tool’s final report /var/log/leapp/leapp-report.txt on the new system will often contain notes about manual actions you may need to take post-upgrade. For example, it might mention that certain packages were removed and need reinstalling, or config files that couldn’t be migrated. Review this report for any such advice and address each item. This is an important step to catch any subtle issues.

  
  

• Test Applications and Validate Data: Perform a full regression test of your applications in the production environment if possible. This means opening your websites, running your APIs, checking that background jobs or scripts are functioning, and that data looks consistent. If you have a monitoring system, watch it closely after the migration for any unusual spikes in resource usage, errors, or alerts.

  
  

• Performance Tuning: The new OS might have different default kernel parameters or tuned profiles. Evaluate if you need to re-apply any performance tuning (for instance, if you had custom sysctl settings in CentOS7, ensure they’re in place on the new OS).

  
  

• Cleanup and Final Backup: Once you’re satisfied that the system is stable on Rocky/AlmaLinux, remove any residual temporary files from the upgrade. ELevate/Leapp might have cached RPMs or left logs in /var/cache/leapp/ – you can clean those to free space. Now is a good time to take a fresh full backup or snapshot of the system in its new state. This will be your rollback point in case any latent issues appear later.

  
  

Ensuring Long-Term Stability in Production

Migrating to Rocky Linux or AlmaLinux is not just a one-time task – ongoing maintenance is key to keeping your production server secure and reliable. Here are some best practices for the long run:

• Regular Updates: Continue to apply updates on a routine schedule (e.g. weekly or monthly). Both Rocky and AlmaLinux will provide security patches and bug fixes in a timely manner (often simultaneously or shortly after Red Hat releases them). Use dnf update (or yum) to keep the system updated. In production, you might want to stage updates in a test environment first, or use automation with tools like Ansible or even scheduling with dnf-automatic. Treat your new OS with the same rigor for patch management as you did (or should have) with CentOS.

  
  

• Monitoring and Alerting: Implement or update monitoring on the server. Ensure that your monitoring recognizes the new OS (for instance, if you have scripts checking /etc/redhat-release or distro name, update them accordingly). Keep an eye on system logs, and set up alerts for any critical errors. Early detection of issues (like an application crash or an OS error) can save downtime. Community forums and mailing lists for Rocky/Alma can also be good places to watch for any widespread issues after major updates.

  
  

• Leverage Enterprise Support if Needed: If this server is critical for business and you require guaranteed support, consider purchasing support for your chosen distro. AlmaLinux has support options via third parties like TuxCare (CloudLinux’s sister company) or others, and Rocky Linux has support options via CIQ and partners. There are also vendor-neutral support providers (e.g., OpenLogic) covering both. Having a support contract can provide quicker resolution if you run into an obscure issue in production.

  
  

• Community Resources: Both distributions have active communities. Rocky Linux has forums and Mattermost/Slack channels under the RESF, and AlmaLinux has forums, a Matrix/Slack chat, etc. If you encounter issues, you can often find help from community members who have done similar migrations. Documentation is continuously updated – check the AlmaLinux Wiki and Rocky Linux docs for any new tips or tools (for example, improvements to ELevate or migrate2rocky scripts).

  
  

• Plan for the Future: While Rocky and AlmaLinux will give you a long support runway (approximately until 2029 for EL8, and 2032 for EL9), it’s wise to keep lifecycle dates in mind. Align your IT roadmap to perform the next major upgrade (likely to EL10 or whatever is next) well before the EOL. Both projects will likely offer in-place upgrade paths or tools when the time comes. Staying proactive about lifecycle management will prevent another scramble at EOL. For additional safety, you could explore extended support options (for example, TuxCare offers extended security patches for CentOS 7, and Red Hat offers TLA for RHEL) if you ever face a gap between EOL and your migration.

  
  

• Minimize Downtime in Future Migrations: For future major upgrades, consider architectures that allow zero-downtime transitions. This might involve containerization of applications, using orchestration (Kubernetes, etc.), or setting up active-passive clusters. While an in-place upgrade is feasible (as we’ve done), many organizations eventually shift toward redeploying new instances and migrating workloads to avoid in-place complexities. Using configuration management (Ansible, Chef, etc.) can help you re-provision servers on a new OS reliably, if you choose that path next time. In any case, now that you’re on Rocky/AlmaLinux, you can follow their development and plan accordingly for any changes.

  
  

In summary, migrating from CentOS 7 to Rocky Linux or AlmaLinux can be accomplished with careful planning and the robust ELevate in-place upgrade tool. Both Rocky and AlmaLinux are production-ready replacements that will keep your infrastructure on a secure, stable footing. By comparing their merits, preparing diligently, and following through with post-migration checks, you can achieve a smooth transition with minimal downtime. Your server will continue to run the same workloads, but now on a supported platform with updates for years to come – all while remaining free and community-supported, just like CentOS was.