September 11, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
CentOS Linux reached end of life in June 2024, and servers still running it carry real risk. If you need to migrate from CentOS to Rocky Linux, you want a path that keeps IP addresses, cron jobs, and application configs intact. Rocky Linux is a practical RHEL-compatible replacement backed by the community. This guide walks through preparation, the in-place upgrade, validation, and rollback—based on patterns I use on production Ubuntu and RHEL-family servers for Linux system administration clients.
Quick answer: To migrate from CentOS to Rocky Linux, back up the server, run pre-flight checks on packages and custom repos, execute the official migrate2rocky script on CentOS 8 or a supported minor release, reboot into Rocky, then validate services, cron, and firewall rules before cutting over traffic.
Why should you migrate from CentOS to Rocky Linux in 2026?
CentOS 7 and CentOS Stream changed the contract many teams relied on. CentOS Linux was a free, binary-compatible rebuild of Red Hat Enterprise Linux. When that model shifted, production teams needed a stable downstream fork.
Rocky Linux fills that gap. It tracks RHEL closely, ships security updates on a predictable cadence, and supports the same package manager, systemd units, and SELinux policies your CentOS stack already expects.
On client projects I maintain on shared EC2 infrastructure, staying on an EOL base OS means missed CVE patches, broken package mirrors, and compliance questions during audits. For a law-firm portal or eCommerce backend, that is not acceptable downtime risk.
Your choice depends on server age and tolerance for downtime. In-place migration is faster but harder to undo. A parallel build gives you a rollback VM at the cost of more planning.
| Approach | Downtime | Rollback ease | Best for |
|---|---|---|---|
| In-place (migrate2rocky) | Low to medium | Hard without snapshot | CentOS 8.x, single app server |
| Parallel new server | Controlled cutover | Easy — keep old VM | CentOS 7, multi-service stacks |
| Container re-platform | Varies | Image rollback | Stateless app tiers |
| Managed cloud rebuild | Provider-dependent | Snapshot restore | Teams without in-house Linux ops |
For a deeper distro comparison, read our write-up on RHEL, Rocky Linux, and AlmaLinux compared. Both Rocky and AlmaLinux are valid targets; Rocky is the focus here because its migration tooling is mature and well documented.
How do you prepare a CentOS server before migrating to Rocky Linux?
Preparation prevents the failures that show up only after reboot. Treat this phase like a production deploy, not a casual package update.
Confirm version and architecture
Run these commands and save the output to a ticket or runbook:
cat /etc/centos-release
uname -r
rpm -qa | wc -l
df -h
free -hmigrate2rocky supports CentOS 8 and later minor releases in most cases. CentOS 7 has no supported in-place path to Rocky 8—you typically build a new Rocky 8 or 9 host and migrate data. That mirrors how I handle website migrations between servers with zero data loss.
Take backups and a snapshot
Before you migrate from CentOS to Rocky Linux, capture:
- A full VM or volume snapshot from your hypervisor or cloud panel
- Database dumps for MySQL, PostgreSQL, or MariaDB
- Copies of
/etc, especially nginx, Apache, PHP-FPM, and SSL paths - A list of enabled systemd units via
systemctl list-unit-files --state=enabled
Automated dumps should already exist. If not, follow our guide to automate database backups on Linux before touching the OS.
Audit third-party repositories
Custom YUM/DNF repos are the top cause of broken upgrades. List them:
dnf repolist
ls -la /etc/yum.repos.d/Disable or remove repos that target CentOS specifically. EPEL usually survives the transition, but vendor repos for PHP, Node.js, or database engines may need Rocky-branded replacements after reboot.
Schedule a maintenance window
Plan for 30–90 minutes on a modest web stack. Larger database hosts can take longer when thousands of packages reconcile. Notify stakeholders and lower DNS TTL a day ahead if you will change IP addresses during a parallel migration.
What is the step-by-step process to migrate from CentOS to Rocky Linux?
The Rocky project publishes migrate2rocky, an official script that swaps repository definitions and upgrades packages in place. Always read the current README on the Rocky Linux rocky-tools repository before running it—flags and supported versions change.
Step 1: Update CentOS fully
sudo dnf clean all
sudo dnf update -y
sudo rebootReboot clears stale kernels and confirms the current stack boots cleanly. If CentOS cannot reboot reliably, fix that first.
Step 2: Download and verify migrate2rocky
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sudo ./migrate2rocky.sh -VReview the script if your security policy requires it. Some teams mirror it internally rather than curling directly on production.
Step 3: Run the migration
sudo ./migrate2rocky.sh -r -VThe -r flag tells the script to proceed without interactive prompts where supported. -V increases verbosity—keep that log. The script replaces CentOS repos with Rocky repos, imports Rocky GPG keys, and runs a full distro sync.
Expect hundreds or thousands of package changes. Do not interrupt the process. SSH drops are rare but possible; use screen or tmux.
Step 4: Reboot into Rocky Linux
cat /etc/rocky-release
sudo rebootAfter reboot, confirm the release file shows Rocky Linux and that the kernel matches expectations.
Alternative: parallel migration for CentOS 7
When in-place is not supported, provision Rocky Linux 8 or 9 on new hardware or a cloud instance. Then:
- Install matching application stacks (Apache or nginx, PHP-FPM, MySQL/MariaDB, Redis).
- Rsync application code and
/var/wwwor your deploy path. - Restore database dumps and verify character sets and user grants.
- Copy TLS certificates or re-issue via Certbot.
- Test on a staging hostname, then swap DNS or load-balancer backend.
That workflow aligns with professional website migration practice—whether the host OS changes or not, the validation checklist is similar.
How do you validate services after migrating from CentOS to Rocky Linux?
A successful package sync does not guarantee your application works. Validation is where most teams stop too early.
Check core platform health
hostnamectl
sestatus
dnf check-update
systemctl --failedAny failed unit deserves attention before you declare victory. Use our systemd service management guide to trace dependency issues.
Verify web stack and PHP
On Laravel or WordPress hosts I maintain, I confirm:
- Apache or nginx starts and serves a known static file
- PHP-FPM socket or TCP listener matches the vhost config
- OPcache is enabled and FPM pools reference correct PHP binaries
- Application
.envdatabase credentials still connect
PHP minor versions can shift during distro sync. Run php -v and compare to pre-migration notes. Composer 2.10 runs fine on modern PHP, but extensions like php-intl or php-redis may need reinstall:
php -m | sort
sudo dnf install php-intl php-mysqlnd php-redisConfirm cron, queues, and background jobs
Cron paths survive migration, but PHP or Python binary paths sometimes change. Audit root and app-user crontabs. Laravel schedulers and queue workers often break silently when the PHP path moves. See cron jobs explained for debugging tips.
Firewall and SELinux
Firewalld zones usually persist, but custom rules deserve a look. SELinux contexts on web roots must remain correct. If uploads fail after migration, run ausearch -m avc -ts recent before disabling SELinux. Our iptables vs nftables article helps if you run custom netfilter rules outside firewalld.
Performance and logs
Watch CPU, memory, and disk for 48 hours. Compare against baseline metrics. Check /var/log/messages, application logs, and slow-query logs. Basic tuning concepts in Linux performance tuning basics apply immediately after a major package churn.
What are common CentOS to Rocky Linux migration failures and fixes?
Most failures fall into a short list. Knowing them saves hours of log spelunking.
Unsupported CentOS version
Running migrate2rocky on CentOS 7 produces a hard stop. The fix is a parallel rebuild, not forced flags. Plan a new Rocky instance and migrate workloads deliberately.
Conflicting third-party repos
Errors mentioning GPG check failures or missing dependencies often trace to stale repo files. Move conflicting .repo files out of /etc/yum.repos.d/, run dnf clean all, and retry. Re-add vendor repos using Rocky-compatible URLs after migration.
Kernel or boot issues after reboot
If the server fails to boot, use hypervisor console access. Boot the previous kernel from GRUB if available. Restore from snapshot if not. This is why the snapshot step is non-negotiable.
PHP or module mismatch
Applications throwing 500 errors after migration often need missing PHP extensions reinstalled. Compare php -m output to your pre-migration save. Reload PHP-FPM and the web server after changes.
Database engine won't start
MariaDB 12.3 or MySQL 9.7 packages may replace older distro builds. Run mysql_upgrade when prompted in logs. Verify socket paths in my.cnf match what application configs expect.
File permission problems also appear after major upgrades. Review Linux file permissions and ACLs if uploads or session directories break.
When to call for help
If production revenue depends on the stack—eCommerce checkout, booking engines, client portals—budget for professional support and maintenance. A failed migration at the wrong hour costs more than planned ops time. Typical rescue engagements for Nepali SMB hosts run Rs 15,000–40,000 (~USD 110–295) depending on stack depth.
Projects like Adventure Third Pole Trek run on Laravel with queues and booking logic. An OS migration on that class of server demands queue verification, not just a homepage check.
Key Takeaways
- CentOS 7 requires a parallel Rocky build; CentOS 8 can use migrate2rocky in place with a snapshot first.
- Back up databases, copy
/etc, snapshot the VM, and audit third-party repos before running any migration script. - Run
migrate2rocky.sh -r -Vonly after a fulldnf updateand a clean reboot on CentOS. - Validate systemd units, cron paths, PHP extensions, TLS, and firewalld rules—not just HTTP 200 on the homepage.
- Monitor logs and resource metrics for 48 hours after cutover before you close the maintenance window.
- Keep the old VM or snapshot until stakeholders sign off; rollback beats heroic debugging at 2 a.m.
People Also Ask
Can you migrate CentOS 7 directly to Rocky Linux in place?
No supported in-place tool upgrades CentOS 7 to Rocky 8 or 9. The supported approach is provisioning a new Rocky server, migrating applications and data, and cutting over DNS or load-balancer backends. Treat CentOS 7 as a rebuild scenario.
Is Rocky Linux free for production use?
Yes. Rocky Linux is open source with no license fee for production deployments. You still pay for hardware, cloud compute, backups, and operational labour—the same cost model CentOS Linux offered before EOL.
How long does a CentOS to Rocky Linux migration take?
In-place migration on a modest single-server stack often takes 30–90 minutes of maintenance window plus validation time. Parallel rebuilds span hours or days depending on data volume, DNS TTL, and staging requirements.
Will Docker containers break after migrating to Rocky Linux?
Containers usually survive because they bundle their own userspace. The Docker engine itself may need reinstall or upgrade to a Rocky-compatible build. Re-test volume mounts, cgroup settings, and compose files after the host OS changes.
Plan your Rocky Linux migration with confidence
To migrate from CentOS to Rocky Linux safely, treat the job as a production change: snapshot first, run migrate2rocky only on supported versions, validate every background worker, and keep rollback options hot. The official Rocky Linux migrate2rocky documentation and Red Hat's CentOS Linux EOL guidance are worth bookmarking alongside your runbook.
If you host Laravel, WordPress, or custom APIs on aging CentOS boxes in Nepal or abroad, a structured migration protects uptime and security patches. Use our JSON formatter when debugging API responses during cutover testing, browse portfolio examples of production stacks I operate, and read Linux server monitoring with Netdata to watch the first 48 hours after go-live.
Need hands-on help? See Linux system administration services or hosting and domain support. For a full platform move—not just the OS—review why businesses in Nepal should migrate to cloud hosting. When you are ready to scope the work, contact us with your CentOS version, stack details, and maintenance window options.
Frequently Asked Questions
CentOS Linux reached end of life in June 2024, so servers still on it miss security patches, lose reliable package mirrors, and fail compliance checks. Rocky Linux is a community-backed, RHEL-compatible rebuild that keeps the same package manager, systemd units, and SELinux policies your stack already uses. On production hosts I maintain, staying on an EOL base OS is unacceptable downtime and audit risk for law-firm portals, eCommerce backends, and API services.
No. migrate2rocky does not support CentOS 7. Running it on CentOS 7 stops with a hard error. Plan a parallel Rocky Linux 8 or 9 build, migrate applications and data, then cut over DNS or load-balancer backends.
migrate2rocky is the official Rocky Linux script from the rocky-tools repository. It replaces CentOS repository definitions with Rocky repos, imports Rocky GPG keys, and runs a full distro sync. It supports CentOS 8 and later minor releases in most cases. Always read the current README before running it, because supported versions and flags change. CentOS 7 is out of scope and needs a parallel rebuild instead.
Treat preparation like a production deploy. Confirm version and architecture with cat /etc/centos-release, uname -r, and rpm -qa. Take a VM or volume snapshot, database dumps, and copies of /etc including web server, PHP-FPM, and SSL paths. List enabled systemd units and audit third-party repos with dnf repolist and ls on /etc/yum.repos.d/. Disable or remove CentOS-specific vendor repos. Schedule a 30–90 minute maintenance window and lower DNS TTL if you will change IPs during a parallel cutover.
First run sudo dnf clean all, sudo dnf update -y, and reboot so CentOS boots cleanly. Download migrate2rocky.sh from the Rocky Linux rocky-tools repository, chmod +x it, and review with -V. Run sudo ./migrate2rocky.sh -r -V inside screen or tmux and do not interrupt the sync. After completion, confirm cat /etc/rocky-release shows Rocky Linux, reboot, and begin service validation. Read the current script README before production use because flags and supported versions change.
In-place migration on a modest single-server web stack usually needs 30–90 minutes of maintenance window plus validation time. Parallel rebuilds can take hours or days depending on data volume, DNS TTL, and staging requirements.
Yes. Rocky Linux is open source with no license fee for production. You still pay for hardware, cloud compute, backups, and operational labour—the same cost model CentOS Linux offered before EOL.
In-place migrate2rocky suits CentOS 8.x single app servers with low to medium downtime and a snapshot for rollback. Parallel builds suit CentOS 7, multi-service stacks, and teams that want an easy rollback VM. Container re-platforming fits stateless tiers. Managed cloud rebuilds help teams without in-house Linux ops. Your choice depends on CentOS version, server age, and tolerance for downtime versus rollback ease.
Capture a full VM or volume snapshot from your hypervisor or cloud panel before touching the OS. Export database dumps for MySQL, PostgreSQL, or MariaDB. Copy /etc, especially nginx, Apache, PHP-FPM, and SSL paths. Save a list of enabled systemd units via systemctl list-unit-files --state=enabled. Automated dumps should already exist; if not, set those up first. The snapshot step is non-negotiable because kernel or boot failures after reboot may require console access or full restore.
Custom repos are the top cause of broken upgrades. List them with dnf repolist and inspect /etc/yum.repos.d/. Disable or remove repos that target CentOS specifically before running migrate2rocky. EPEL usually survives the transition, but vendor repos for PHP, Node.js, or database engines may need Rocky-branded replacements after reboot. GPG check failures and missing dependencies during migration often trace to stale repo files—move conflicting .repo files out, run dnf clean all, and retry.
Check hostnamectl, sestatus, dnf check-update, and systemctl --failed for any broken units. Confirm Apache or nginx serves a known static file, PHP-FPM sockets match vhost config, OPcache is enabled, and application database credentials still connect. Run php -v and php -m, reinstall missing extensions if needed, and audit cron paths because PHP binary paths can shift. Verify firewalld zones, SELinux contexts on web roots, TLS certificates, and watch CPU, memory, disk, and logs for 48 hours before closing the maintenance window.
Unsupported CentOS version means stop and plan a parallel rebuild—do not force flags. Conflicting third-party repos cause GPG or dependency errors; remove stale .repo files, run dnf clean all, and re-add Rocky-compatible vendor repos. Kernel or boot failures after reboot need hypervisor console access, booting a previous GRUB kernel, or snapshot restore. PHP 500 errors often need missing extensions reinstalled—compare php -m to pre-migration notes and reload PHP-FPM. Database engines may not start if packages shift; run mysql_upgrade when logs prompt and verify socket paths in my.cnf.
Containers usually survive because they bundle their own userspace. The Docker engine itself may need reinstall or upgrade to a Rocky-compatible build. Re-test volume mounts, cgroup settings, and compose files after the host OS changes. Do not assume a passing homepage check means container workloads are fine—validate each service explicitly after cutover.
Typical rescue engagements for Nepali SMB hosts run Rs 15,000–40,000, roughly USD 110–295, depending on stack depth. A failed migration at the wrong hour on a revenue-critical eCommerce checkout, booking engine, or client portal costs more than planned ops time. Budget professional support when production uptime depends on the stack, especially for Laravel apps with queues and background workers that need verification beyond a simple HTTP 200 check.
In-place migration is hard to undo without a snapshot—keep the VM or volume snapshot taken before migrate2rocky until stakeholders sign off. If the server fails to boot, use hypervisor console access and try the previous kernel from GRUB. If that fails, restore from snapshot. Parallel migration is easier to roll back because the old CentOS VM stays running until DNS or load-balancer cutover is confirmed. Rollback beats heroic debugging at 2 a.m. when revenue depends on the stack.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
