Migrate from CentOS to Rocky Linux

August 12, 2026 Khimananda Oli 8 min read Virtualization

By Khimananda Oli | Last reviewed: August 2026

If you are still running CentOS 7 or CentOS Stream 8 in production, you need a validated path to migrate from CentOS to Rocky Linux before support gaps expose your infrastructure to security risks. The ELevate project provides an in-place upgrade mechanism that preserves users, services, and configurations while swapping the underlying RPM base to a supported RHEL-compatible release. This guide walks through the exact preparation, execution, and verification steps I use when converting legacy fleets, ensuring you avoid common pitfalls like broken repositories or orphaned packages during the transition.

Quick answer: To migrate from CentOS to Rocky Linux, back up your system, install the ELevate repository and leapp utility, run pre-upgrade checks to resolve blockers, execute the in-place upgrade, reboot into Rocky Linux, and validate services. Always test in staging first.

Four-phase workflow to migrate from CentOS to Rocky Linux safely in production environments

How do you prepare a server before you migrate from CentOS to Rocky Linux?

Preparation determines whether your migration succeeds cleanly or leaves you debugging a half-converted system at 2 AM. Before you attempt to migrate from CentOS to Rocky Linux, treat the server as if it might fail mid-process. A proper safety net lets you roll back instantly rather than rebuilding from scratch. For teams managing critical workloads, reviewing our server backup strategies guide reinforces principles that apply equally well to RHEL-family systems.

Create a verified full-system backup

Do not rely solely on application-level dumps. You need a block-level snapshot or complete filesystem archive that you can restore without reinstalling the OS. If you run on VMware, Proxmox, or AWS EC2, take a VM snapshot or EBS snapshot immediately before starting. For bare metal or VPS instances without snapshot APIs, use fsarchiver or dd to image the disk, or at minimum run a full rsync -aAXvHx to external storage preserving ACLs, xattrs, and hard links.

# Example: Full filesystem backup with fsarchiver (run from rescue/live media)
fsarchiver savefs /backup/centos-pre-migrate.fsa /dev/sda1 -v

# Alternative: rsync with all metadata preserved
rsync -aAXvHx --delete / /mnt/backup/ --exclude={/proc/*,/sys/*,/dev/*,/run/*,/tmp/*,/mnt/*,/media/*,/lost+found}

Audit third-party repositories and custom packages

ELevate handles official CentOS and EPEL repositories automatically, but third-party repos (RPM Fusion, Remi, IUS, custom internal mirrors) often lack migration metadata. List all enabled repos and identify non-standard ones:

yum repolist all | grep enabled
rpm -qa --qf '%{VENDOR} %{NAME}\n' | grep -v 'CentOS\|Red Hat\|EPEL' | sort -u

Disable or remove incompatible third-party repos before migration. Packages from these sources may need manual reinstallation after the base OS converts. Document every custom package so you can verify functionality post-migration.

Verify disk space and kernel compatibility

The upgrade process downloads several gigabytes of packages and creates temporary initramfs images. Ensure at least 5 GB free in /var/cache and /boot. Old kernels accumulate over time; clean them to prevent /boot exhaustion:

# Keep only current and one previous kernel
package-cleanup --oldkernels --count=2 -y

# Verify /boot has sufficient space
df -h /boot /var/cache/yum

What tools automate the CentOS to Rocky Linux migration process?

The ELevate project is the standard toolchain for in-place migrations across RHEL derivatives. It wraps Red Hat’s Leapp framework with distribution-specific metadata, enabling cross-distro upgrades that Red Hat does not officially support. When you migrate from CentOS to Rocky Linux, ELevate handles repository mapping, package replacement, and configuration adjustments automatically.

ELevate maps CentOS repositories and packages to Rocky Linux equivalents during in-place migration

Install the correct ELevate release package

Select the ELevate package matching your source OS version. Using the wrong package causes metadata mismatches and failed pre-upgrade checks:

# For CentOS 7 → Rocky Linux 9
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm

# For CentOS Stream 8 → Rocky Linux 9
dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el8.noarch.rpm

# Install leapp with Rocky-specific data
yum install -y leapp-upgrade leapp-data-rocky   # EL7
dnf install -y leapp-upgrade leapp-data-rocky    # EL8

Understand what ELevate actually modifies

ELevate does not reinstall the OS. It performs a transactional package swap: removing CentOS-branded packages, installing Rocky Linux equivalents, updating GRUB, and regenerating initramfs. User data in /home, /var, and /opt remains untouched. Configuration files receive .rpmnew suffixes when upstream defaults change; your originals stay intact but may need manual merging.

How do you execute the in-place upgrade safely?

Execution follows a strict two-phase pattern: pre-upgrade assessment, then actual upgrade. Never skip the pre-upgrade phase. It identifies blockers without modifying the system, giving you a chance to fix issues while rollback is trivial.

Run pre-upgrade and resolve all inhibitors

The pre-upgrade generates a detailed report listing errors (must-fix), warnings (review recommended), and informational messages:

leapp preupgrade --target 9.4 --channel ga

# Review the report
cat /var/log/leapp/leapp-report.txt
less /var/log/leapp/answerfile

Common inhibitors include:

Incompatible kernel modules: Remove proprietary drivers lacking EL9 builds, or switch to open-source alternatives.
Deprecated PAM configurations: Update /etc/pam.d/ files per Leapp remediation instructions.
Python 2 dependencies: Migrate scripts to Python 3 before upgrading; EL9 drops Python 2 entirely.
Conflicting third-party packages: Remove or replace packages from disabled repos that have no EL9 equivalent.

After resolving each inhibitor, re-run leapp preupgrade until zero errors remain. Warnings are acceptable if you understand their impact; document accepted warnings in your change log.

Execute the upgrade with controlled reboot

Once pre-upgrade passes cleanly, schedule a maintenance window. The upgrade itself takes 30–90 minutes depending on package count and disk speed:

# Start the upgrade (system will reboot automatically)
leapp upgrade --target 9.4 --channel ga

# Monitor progress via serial console or IPMI if SSH drops
# After reboot, check migration status
cat /var/log/leapp/leapp-upgrade.log
journalctl -u leapp-resume.service

During reboot, the system boots into a special Leapp initramfs that performs the actual package transaction. Do not interrupt this phase. If power loss occurs, restore from your pre-migration backup rather than attempting recovery.

What post-migration validation ensures Rocky Linux works correctly?

A successful boot does not mean a successful migration. Post-upgrade validation confirms that services function, security policies enforce correctly, and no orphaned artifacts remain. Teams running databases should cross-reference our PostgreSQL administration essentials to verify database integrity after OS-level changes.

Verify OS identity and repository state

Confirm the system identifies as Rocky Linux and pulls updates from correct repositories:

# Confirm OS release
cat /etc/os-release
hostnamectl

# Verify Rocky repos are active and CentOS repos removed
dnf repolist all | grep -E 'rocky|baseos|appstream'
ls /etc/yum.repos.d/ | grep -i centos   # Should return nothing

# Test update path works
dnf check-update

Validate critical services and SELinux context

SELinux relabeling occurs during upgrade, but mislabeled files cause silent denials. Force a complete relabel if services behave unexpectedly:

# Trigger full SELinux relabel on next boot
touch /.autorelabel
reboot

# After relabel completes, check for denials
ausearch -m avc --recent | audit2why
sestatus   # Must show "enforcing"

Test every production service: web servers, databases, cron jobs, monitoring agents, and backup routines. Compare behavior against pre-migration baselines. Pay special attention to systemd unit files; some legacy units require syntax updates for EL9 systemd.

Clean up migration artifacts

Remove Leapp packages and temporary files once validation completes. These serve no purpose on a stable Rocky system and consume disk space:

# Remove migration tooling
dnf remove -y leapp leapp-upgrade leapp-data-rocky elevate-release

# Clean cached packages and old kernels
dnf clean all
dnf autoremove -y
package-cleanup --oldkernels --count=2 -y

# Archive migration logs for audit trail
tar czf /root/centos-to-rocky-migration-$(date +%F).tar.gz /var/log/leapp/

CentOS 7 versus Rocky Linux 9 comparison highlighting why teams migrate from CentOS to Rocky Linux in 2026

Criteria	CentOS 7	Rocky Linux 9
Vendor Support	Ended June 2024	Active until May 2032
Kernel Version	3.10.x (frozen)	5.14.x (backported fixes)
Default Python	2.7 (EOL)	3.9+ (maintained)
OpenSSL	1.0.2 (insecure)	3.0.x (FIPS-capable)
Container Runtime	Docker 1.x only	Podman 4.x, CRI-O, Buildah
Compliance Readiness	Fails modern audits	SOC 2 / ISO 27001 aligned
In-Place Migration Path	N/A (source only)	ELevate supported

Migrate from CentOS to Rocky Linux with confidence

When you migrate from CentOS to Rocky Linux using ELevate, you preserve operational continuity while gaining a decade of security support and modern tooling. The key is disciplined preparation: verified backups, thorough pre-upgrade remediation, and systematic post-migration validation. Skipping any phase invites preventable outages. For teams needing hands-on assistance with fleet conversions or compliance-aligned infrastructure transitions, reach out directly to discuss your specific environment. Proper planning today prevents emergency rebuilds tomorrow.

Frequently Asked Questions

Yes, the migration tools and Rocky Linux operating system are completely free and open source. You only pay for underlying cloud infrastructure or professional support contracts if your organization requires enterprise-grade service level agreements for production environments.

Use elevate.sh for CentOS 7 or rocky-tools for CentOS Stream conversions in 2026. These official scripts handle repository swaps, package replacements, and bootloader updates automatically while preserving existing configurations and user data during the in-place migration process.

No, direct jumps across major versions are unsupported. Migrate from CentOS 7 to Rocky Linux 8 first using elevate.sh, verify stability, then perform a second in-place upgrade to Rocky Linux 9 using leapp utility with proper pre-upgrade assessments.

In-place migrations typically require thirty minutes to two hours depending on package count and disk speed. Always schedule maintenance windows of at least four hours to accommodate unexpected issues, verification testing, and potential rollback procedures if critical services fail post-conversion.

Custom RPMs often break due to changed dependencies or library versions. Audit all non-standard packages before migration, rebuild them against Rocky Linux repositories, and test in staging environments to ensure compatibility with updated system libraries and security policies.

No, in-place migration preserves installed applications and configurations. However, verify application functionality post-migration as some services may require restarts, configuration adjustments, or dependency updates to work correctly with Rocky Linux package versions and systemd unit changes.

Run cat /etc/rocky-release to confirm version, check dnf repolist for correct repositories, validate critical services with systemctl status, and compare package counts before and after migration. Test application endpoints and review journalctl logs for errors within twenty-four hours.

Common failures include third-party repository conflicts, kernel module incompatibilities, SELinux policy denials, and broken symlinks. Pre-migration audits using rocky-tools check commands identify most issues. Always maintain verified backups and snapshot capabilities before starting any production conversion process.

Yes, Rocky Linux fully supports EPEL repositories with identical package availability. Enable epel-release package post-migration and run dnf makecache to refresh metadata. Verify specific package versions match your requirements as EPEL maintains separate streams for Rocky Linux 8 and 9.

Rocky Linux provides identical security posture to CentOS Linux with matching CVE patching timelines and binary compatibility. Security advisories publish simultaneously through the same Red Hat upstream sources, ensuring equivalent vulnerability management and compliance certification validity for regulated production environments.

Yes, if you created LVM snapshots or filesystem backups before migration. Restore from backup media and reboot into previous state. In-place migrations without snapshots cannot be reversed, making pre-migration backups absolutely mandatory for all production systems.

Yes, firewalld and iptables configurations persist through migration. Verify active zones and rules with firewall-cmd --list-all post-conversion. Test network connectivity thoroughly as some legacy iptables modules may require reloading or replacement with nftables equivalents in Rocky Linux 9 environments.

Both offer equivalent CentOS compatibility and community support. Choose Rocky Linux if you prefer CIQ commercial backing or AlmaLinux for CloudLinux ecosystem integration. Technical differences are negligible; base decisions on existing vendor relationships, support contract requirements, or specific third-party software certifications.

Cron jobs persist but verify timing syntax and script paths remain valid. Check crontab -l output matches expectations and test scheduled tasks manually. Some legacy cron implementations may require migration to systemd timers for better logging and dependency management in modern Rocky Linux deployments.

Rocky Linux 9 uses kernel 5.14 series with backported security patches and hardware enablement updates. Verify compatibility with proprietary drivers and custom kernel modules before migration, as newer kernels may deprecate legacy interfaces requiring code updates or alternative driver installations.