System Migration Options After CentOS 7/8 End of Life: Alternative Distributions and Strategies

CentOS 8 reached end-of-life (EOL) at the end of 2021, and CentOS 7 followed in mid-2024. The practical impacts of this EOL are twofold: no more security updates and unavailability of official software repositories (software installation will fail directly).

This is not a “deal with it later” issue—repository failure immediately affects daily operations. Dealing with package installation failures only when they occur puts you in a passive position.

First, Confirm the Current Status

# Check current system version
cat /etc/redhat-release
cat /etc/os-release

# Check if EOL has been reached (official repos become unavailable after EOL)
yum repolist
yum makecache
# If you get connection errors to mirror sources, it likely means the repos are offline

Alternative Directions

If your team is familiar with CentOS, choosing Rocky or AlmaLinux incurs the lowest migration cost—commands, paths, and package management methods are basically identical, allowing direct reuse of operational experience.

Two Migration Strategies

Strategy 1: New Server + Application Migration (Recommended)

1. Create a new server using the target OS
2. Deploy the environment on the new machine and sync applications and data
3. Verify using hosts or a temporary domain name
4. Switch DNS resolution, keeping the old machine active for a period

This is the most stable approach because the old system remains unchanged, allowing for immediate rollback. The trade-off is the effort required to reinstall the environment.

Strategy 2: In-Place Conversion (Risky)

The community provides scripts to convert CentOS in-place to Rocky/AlmaLinux. The advantage is no need to reinstall; the disadvantage is high risk:

• Interruption during conversion can render the system unbootable
• Third-party repositories and custom kernel modules may cause issues
• Failure in production environments carries high recovery costs

Recommendation: Use in-place conversion only for test environments or non-critical machines. For production systems, use Strategy 1.

Three Things to Confirm Before Migration

# ① List currently installed packages (to install on the new machine)
rpm -qa > /tmp/packages.txt
yum list installed > /tmp/installed.txt

# ② Identify custom configurations
ls /etc/nginx/ /etc/php* /etc/my.cnf 2>/dev/null
crontab -l > /tmp/crontab.txt

# ③ List auto-start services
systemctl list-unit-files --state=enabled > /tmp/services.txt

“Installing packages based on the old machine’s list” is far more reliable than relying on memory. When relying on memory, extensions used only for specific functions are often forgotten.

Data and Application Migration

# Database (pay attention to character sets and routines)
mysqldump -u root -p --default-character-set=utf8mb4 
  --single-transaction --routines --triggers --events dbname > db.sql

# Website files (preserve permissions and ownership)
rsync -avz /var/www/ root@NewServerIP:/var/www/

# Configuration files
rsync -avz /etc/nginx/ root@NewServerIP:/etc/nginx/

# Verify on the new machine
nginx -t
php -v
php -m | tr 'n' ' '          # Compare extension list with the old machine
systemctl list-unit-files --state=enabled

Points to Note Regarding Version Differences

Even if you choose Rocky/AlmaLinux, software versions change between major releases (e.g., default versions of PHP and MySQL differ):

# Confirm key software versions one by one after migration
php -v
mysql --version
nginx -v

# Compare with the old machine (handle differences before switching)
diff <(php -m | sort) /tmp/old_php_modules.txt

“The system changes, so software versions change too” is the most common pitfall in this migration. Applications may not run directly under the new version (especially with major PHP version changes).

Decision Tree

CentOS End of Life
├─ First confirm impact: Are yum repos still usable?
├─ Choose alternative OS
│  ├─ Want to keep existing experience → Rocky / AlmaLinux (lowest migration cost)
│  ├─ Want vendor support → Cloud provider variants
│  └─ Don't mind changing ecosystems → Ubuntu / Debian
├─ Choose migration strategy
│  ├─ Production environment → New server + migration (keep old system for rollback)
│  └─ Test/Non-critical → Consider in-place conversion tools
└─ Post-migration must-dos
   ├─ Compare package lists and extension lists
   ├─ Compare key software versions (PHP/MySQL, etc.)
   └─ Switch DNS only after verification; keep old machine active for a while

Scenario Walkthrough: System EOL, Want to Upgrade but Afraid to Move

Symptom: A batch of servers runs an operating system version that has reached EOL,
receiving no more security updates. You want to upgrade but fear business interruption; if you don’t upgrade, vulnerabilities accumulate.

1. First, clarify exactly what is running on these machines → List services, versions, data locations, and dependencies one by one.
   If this step is incomplete, any subsequent plan is a gamble.
2. Distinguish between “can be upgraded in-place” and “must be rebuilt” → In-place upgrades across major versions carry high risks on critical business machines;
   the more common choice is “new build + migration”.
3. Choose batch migration rather than in-place upgrade → Replicate the environment on new machines of the same version first,
   verify success, then migrate business; if issues arise, you can roll back immediately.
4. Confirm compatibility of the target version → Carefully check for changes in runtime environments, database versions, and dependency libraries,
   which are common causes of migration failure.
5. Migrate non-critical nodes first → Run the full process on the least impactful machines first,
   exposing potential issues before the formal cutover.
6. Keep old machines active for a period after cutover → Decommission them only after confirming stable operation,
   ensuring a fallback path is ready before switching.

# ① Assess current status
hostnamectl 2>/dev/null | head -3
cat /etc/os-release | head -3
systemctl list-unit-files --type=service | grep enabled
ss -lntp
dpkg -l 2>/dev/null | wc -l || rpm -qa | wc -l

# ② Record key versions for alignment on the target system
php -v | head -1; mysqld --version 2>/dev/null; nginx -v 2>&1

# ③ Verify item by item after migration
curl -sS -o /dev/null -w '%{http_code}n' https://example.com/
mysql -e "SELECT VERSION();"

Root Cause: After a system reaches EOL, there are no more security updates, and risks accumulate over time.
The real difficulty lies not in technical selection, but in the lack of a complete inventory, causing hesitation to make changes.

Two key takeaways:

• “Fear of upgrading” is usually not a technical issue, but an information gap.
  Once the current state is clarified (services, versions, dependencies, data locations), the solution becomes apparent.
• For critical business, prioritize “new build + migration” over in-place cross-version upgrades.
  The former allows easy rollback; if the latter fails midway, the recovery cost is much higher.

8 Common Pitfalls

1. Procrastinating until repos fail: This creates a passive situation; plan ahead.
2. Assuming switching to archive repos solves everything: Security updates are still missing.
3. Using in-place conversion in production: High risk of failure and difficult recovery.
4. Failing to compare package lists: Leading to missing packages on the new machine.
5. Ignoring software version changes: Major PHP version changes can cause application errors.
6. Decommissioning old machines immediately after cutover: Leaves no fallback option if problems arise.
7. Failing to backup before migration: At minimum, ensure rollback-capable data exists.
8. Switching without verification: Should verify in a test environment or using hosts first.

Real Customer Feedback (From Similar Service Reviews and Consultations on Cloud Markets)

The following excerpts are taken from real buyer reviews and consultations for similar IT operations services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud marketplaces (providers include our store and peers, provided solely as reference for genuine feedback, not fictional tickets from this site):

45***76 2021-04-14 5.0 On-time delivery Excellent

10***02 2024-07-31 5.0 Secure and Reliable | Comprehensive Features | Affordable Timely handling, successful migration 10***31 2022-06-22 5.0 Affordable | Skilled Tech | Complete After-sales Good job, helped me migrate my years-old site to a new server.

10***31 2022-11-17 5.0 On-time delivery | Quick Response | Affordable Successful system migration 10***31 2022-11-17 5.0 Skilled Tech | Secure and Reliable | Affordable Successful migration