CentOS 7 to Rocky Linux Migration: Practical In-Place Upgrade Workflow

Enterprise fleets running CentOS 7 are approaching a hard wall: end-of-life landed on June 30, 2024. No new CVEs will be patched. Given compliance enforcement and dependency chain drift, the operational cost of staying put is unsustainable.

Many teams are looking to Rocky Linux as a direct, drop-in replacement. Here’s how to execute an in-place migration efficiently—minimal risk, actual downtime measured in seconds (or none), and clarity at every step.

Environmental Audit & Baseline Creation

First, no production change without a complete situational snapshot. Many migration failures result from overlooked edge-case dependencies.

Inventory services and software versions:

rpm -qa --last > centos7-installed-packages-$(hostname).txt
systemctl list-units --type=service --state=running > centos7-running-services.txt
uname -r > centos7-kernel.txt
cat /etc/centos-release

Include custom kernel modules, local user scripts, and vendor agents—these often cause surprises post-upgrade.

Critical tip: Document custom repo files in /etc/yum.repos.d/ and any hand-edited content in /etc (diff the dir versus a clean install if practical).

Backup & Rollback Readiness

Even with best practice, surgery at the OS layer is always high-risk. The only reliable backstop: snapshot or image-based backup.

• Filesystem snapshot (LVM or SAN tools recommended for speed)
• Hypervisor snapshot for VMs (verify quiesce, particularly on ESXi/XCP-ng)
• Tarball backup of /etc, web application roots, and database exports:

  tar czf /root/pre-migration-etc.tar.gz /etc
  mysqldump --all-databases > /root/pre-migration-mysqldump.sql
  

Corruption between RPM database and package files is recoverable—provided rollback exists.

Choosing the Right Path: In-Place or Migratory Cutover

Some workloads (legacy Oracle DB, heavily customized Python stacks) react poorly to in-place churn. If those are present, containerizing and redeploying on Rocky Linux might be safer. For the majority, Rocky provides migrate2rocky, engineered for straightforward RHEL/CentOS migration.

This workflow executes a direct, in-place migration.

1. Prepare: Install and Inspect migrate2rocky

Rocky Linux maintainers package a clean migration utility. Do not run this on a critical host without prior staging validation—false positives do appear.

yum clean all
yum -y install epel-release
yum -y install migrate2rocky

Explore dry-run capabilities:

migrate2rocky --precheck

Sample output regarding conflicting packages:

[ERROR] Package 'centos-release' conflicts with 'rocky-release'
[WARN ] Detected EOL: kernel 3.10.0-1160.95.1.el7.x86_64 may not be fully supported post-migration

Address blockers—custom and third-party RPMs should be tested or rebuilt as Rocky-compatible. Pay attention to python2-only scripts; consider parallel install of python3.

2. Minimize Service Footprint Before Transition

Downtime can be limited to one fast reboot, but filesystem integrity isn't negotiable. Briefly pause stateful or write-heavy workloads.

systemctl stop httpd
systemctl stop mariadb
systemctl stop postfix

Gotcha: For clustered services, quiesce the node and drain load balancers before taking it out of rotation.

Notify teams via status page or incident comm, even for maintenance under five minutes.

3. Run the Migration Engine

All clear? Start the migration. Run as root, never via automated systems without interactive supervision.

migrate2rocky -r

-r triggers repo backup and transition. Review /var/log/migrate2rocky.log continuously for exceptions or halts.

Example failure line:

[FAIL] Unresolved dependency: libxyz.so.2 needed by custom-app-1.3-1.x86_64

Resolve or remove incompatible RPMs before retrying. Efficiency sometimes means uninstalling rarely-used packages now and reinstalling them post-migration.

4. System Reboot & Immediate Health Check

On completion, force a reboot to load all new libraries, kernels, and daemon binaries.

reboot

Post-reboot checks (serial console better than SSH for immediate troubleshooting):

• OS release/version:

  cat /etc/os-release
  

  Should return:

  Rocky Linux release 8.9 (Green Obsidian)
  

• Critical service status:

  systemctl status network sshd httpd mariadb
  

  Watch for failures similar to:

  httpd.service: Failed to start The Apache HTTP Server.
  

  Examine /var/log/messages and journalctl -xb for context.

Check custom agents—monitoring (Zabbix/Datadog), backup daemons, SNMP listeners. Some agent binaries have strict OS checks and may fail silently.

5. Post-Migration Validation & System Hygiene

Cache and metadata clean-up:

dnf clean all
rm -rf /var/cache/dnf/*

Rebuild initramfs to avoid future boot anomalies:

dracut --force

Regression test applications:
Automated smoke tests help; otherwise, check with:

curl -I http://localhost
mysqladmin ping

Network reachability:
Monitor with tools like ping, nc, or functional monitor agents.

Review failure domains:
Periodic log review is advised over coming days:

journalctl -p err -b

6. Optimize and Monitor

Don’t trust a green reboot. Observe system-level metrics (CPU wait, IO latency) and application logs for subtle misalignments in SELinux policies or runtime library behavior.

Update configuration in CM tools (Ansible, Puppet, Chef):
Inventory labels and repositories must reflect the OS swap.

Note: For HA environments, rolling migrations allow for incremental cutover—begin with secondary nodes to validate real-world behavior.

Quick Reference: Migration Flow

+----------------+        +-------------------+        +---------------+
|  Backup/Verify | -----> |  Pre-migration    | -----> |  Migrate OS   |
|  (Snapshot)    |        |  Checks           |        |  (Scripted)   |
+----------------+        +-------------------+        +---------------+
        |                          |                           |
        V                          V                           V
+----------------+        +-------------------+        +--------------+
|  Reboot/Smoke  | -----> |  Post-migration   | -----> |  Optimize/   |
|  Test          |        |  Application Test |        |  Observe     |
+----------------+        +-------------------+        +--------------+

Practical Observations

• migrate2rocky won’t resolve third-party repositories or unsigned RPMs. Manual verification is mandatory.
• If you use custom startup scripts in /etc/rc.d, some RHEL8-based systems now require systemd units. Prepare updates.
• If your kernel is hand-patched or built for particular hardware, expect driver rework needs.

Final Notes

CentOS 7 to Rocky Linux in-place migration, done properly, is fast and largely automated. The edge cases—custom packages, kernel modules, legacy tools—demand planning and test repetition. Never skip the dry run or the staging clone.

For high-availability workloads: sequence node migrations with traffic draining and readiness health checks. Accept a staged cutover if workloads are business-critical.

Other approaches (containerization, new VM deployment) remain viable for complex or layered systems; this document emphasizes the fastest path for standard fleet upgrades.

Document every action. Save logs. Share migration postmortems with your team. Practical resilience is built on lessons learned, not vendor promises.