Migración de CentOS a Rocky Linux 10 o AlmaLinux 10: Guía Definitiva para Sysadmins 2026

octubre 7, 2026 Alfonso Moreno | Sysadmin Senior 28 Visitas 12 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

El problema de fondo: CentOS ya no es lo que era

Si hoy corres CentOS 7, CentOS 8 o CentOS Stream, estás en una de tres situaciones. La primera: estás en CentOS 7, que llegó a end-of-life en junio de 2024 y no recibe parches de seguridad upstream. La segunda: estás en CentOS 8, que se quedó sin soporte en diciembre de 2021. La tercera: estás en CentOS Stream, que sigue vivo pero con un modelo de release rolling que no todos los shops quieren asumir. Las tres convergen en la misma pregunta práctica: ¿a cuál de los dos clones comunitarios de RHEL me conviene migrar?

La respuesta corta en 2026: Rocky Linux 10 o AlmaLinux 10. Ambos son reconstrucciones binarias de RHEL 10 con kernel 6.12, ambos tienen soporte hasta 2030 (active) y 2035 (security), y los dos corren prácticamente cualquier workload que corría en CentOS. La respuesta larga requiere mirar tres cosas: qué versión de CentOS tienes hoy, qué tipo de hardware tienes, y cuánto valorás un camino de upgrade soportado a la próxima major release.

Esta guía cubre los tres escenarios de migración, los comandos reales verificados contra la documentación oficial de Rocky y AlmaLinux en octubre de 2026, y los gotchas que descubrí al probar las herramientas en servidores reales.

Rocky Linux 10 vs AlmaLinux 10: la diferencia que importa en 2026

Hasta RHEL 9, Rocky y AlmaLinux eran funcionalmente idénticos: misma base RHEL, mismo ciclo de release, misma compatibilidad binaria. Con RHEL 10 eso cambió en puntos que afectan directamente tu decisión de migración. La tabla resume las diferencias operativas verificadas contra docs.rockylinux.org y wiki.almalinux.org:

Característica	Rocky Linux 10	AlmaLinux 10
Última versión estable	10.2 (2026-05-29)	10.2 (2026-05-26)
Kernel	6.12.0-211.16.1	6.12.0-211.7.3
Active support hasta	2030-05-31	2030-05-31
Security support hasta	2035-05-31	2035-05-31
Arquitectura mínima x86	x86-64-v3 (Haswell 2014+)	x86-64-v2 (Nehalem 2008+)
Soporte 32-bit userspace	No (eliminado)	Sí (vía paquete i686)
Upgrade in-place 9→10 soportado	No oficialmente	Sí (vía ELevate)
Conversión desde CentOS	Sí (migrate2rocky)	Sí (almalinux-deploy)
OpenStack/RDO	Limitado	Mejor integración
Certificación hardware	Estricta (CIQ-style)	Abierta (más vendors)

Las dos celdas que importan para tu decisión son arquitectura mínima y soporte de upgrade in-place. Si tienes hardware anterior a 2014 (servidores viejos con CPUs Xeon E5 v2 o anterior, o workstations con Core i de tercera gen), Rocky 10 no va a bootear en modo x86-64-v3: necesitas AlmaLinux 10, que sigue soportando v2. Si quieres hacer upgrade de RHEL 9 / CentOS Stream 9 a 10 sin reinstalar, solo AlmaLinux tiene el camino oficial vía la herramienta ELevate.

Escenario 1: migrar CentOS 7 a Rocky 10 o AlmaLinux 10

Este es el camino más largo porque tienes que pasar por RHEL 9 primero: no existe leapp directo de CentOS 7 a 10. La estrategia de dos pasos (CentOS 7 → 9 → 10) sigue siendo la más limpia porque cada paso tiene tooling oficial y testeado. La alternativa es reinstalar limpio en Rocky 10 / AlmaLinux 10 y migrar datos con rsync, que es lo que recomendás si tu servidor tiene años de paquetes de terceros abandonados.

Para el primer paso, el camino es idéntico al que documenta la guía previa de CentOS 7 a Rocky/AlmaLinux 9 con leapp. La diferencia es qué distribución eliges como destino intermedio. Si pensás quedarte en esa distro por el resto del ciclo de vida, elegí directamente Rocky 9 o AlmaLinux 9 según cuál te convence más a largo plazo. Si sabes que vas a querer migrar a 10 en el futuro, elegí AlmaLinux 9 porque el upgrade 9→10 está soportado oficialmente.

Después de tener Rocky 9 o AlmaLinux 9 corriendo y parchado, recién ahí empezás el segundo paso. El flujo para AlmaLinux 9→10 vía ELevate es el siguiente:

# 1. Instalar el repo de ELevate y leapp
sudo dnf install -y https://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
sudo dnf install -y leapp-upgrade leapp-data-almalinux
# 2. Pre-check
sudo leapp preupgrade
# 3. Leer el reporte de incompatibilidades
sudo cat /var/log/leapp/leapp-report.txt

El reporte lista inhibidores. Los más comunes en 9→10 son el módulo remove_pam_pkcs11_module_check y cambios en /etc/login.defs. Resolvé cada inhibidor con la respuesta que leapp espera:

# Confirmar acciones automáticas (un entry por línea del answerfile)
sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True
sudo leapp answer --section ssh_config_weak_perms.confirm=True
# Upgrade real
sudo leapp upgrade
sudo reboot

Si tu hardware no soporta x86-64-v3 (Haswell o posterior), este paso va a fallar en el primer boot. La solución no es desactivar el flag en el kernel, es elegir AlmaLinux 10 desde el principio. Para Rocky 10 no hay downgrade de arquitectura posible.

Escenario 2: migrar CentOS Stream 9 a Rocky 10 o AlmaLinux 10

CentOS Stream 9 sigue recibiendo updates, pero su modelo rolling upstream-first genera fricciones con shops que tienen procesos de QA largos. Si te cansaste de Stream y quieres pasarte a un clon RHEL clásico, tienes dos opciones: migrate2rocky para Rocky, o almalinux-deploy para AlmaLinux. Ambos convierten el sistema in-place sin reinstalar.

Para ir a Rocky 10 desde CentOS Stream 9, el flujo es:

# 1. Bajar y revisar el script de migración
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
less migrate2rocky.sh
# 2. Ejecutar conversión a Rocky 9 primero (no salta directo a 10)
sudo bash migrate2rocky.sh -r 9
# 3. Después de reboot, ya estás en Rocky 9. Upgrade a Rocky 10:
#    OJO: Rocky NO soporta leapp 9→10 oficialmente.
#    La opción soportada es reinstalar limpio.

El detalle que pilla a mucha gente: migrate2rocky no salta directo a Rocky 10. El script convierte a Rocky 9, y desde ahí no hay upgrade oficial a Rocky 10. La política del proyecto Rocky es que las major releases son instalaciones nuevas. Si quieres llegar a Rocky 10 desde CentOS Stream 9, las opciones son: reinstalar limpio, o ir a Rocky 9 y después saltar a 10 con leapp no oficial (forks de la comunidad, no soportado por el proyecto).

Para AlmaLinux 10 desde CentOS Stream 9, el camino es más corto y oficial:

# 1. Instalar el script de deploy
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.sh
# 2. Después del reboot, ya estás en AlmaLinux 9
# 3. Upgrade a AlmaLinux 10 vía ELevate (mismo flujo que en el escenario 1)
sudo dnf install -y https://repo.almalinux.org/elevate/elevate-release-latest-el9.noarch.rpm
sudo dnf install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade
sudo leapp upgrade
sudo reboot

Este es el flujo más limpio para alguien que hoy corre CentOS Stream 9 y quiere terminar en AlmaLinux 10 sin reinstalar. El primer paso convierte, el segundo upgrade. Ambos son soportados oficialmente.

Escenario 3: migrar CentOS 8 (EOL desde dic-2021) a Rocky 10 o AlmaLinux 10

CentOS 8 lleva más de cuatro años sin soporte upstream. Si todavía lo tienes en producción, estás corriendo con CVEs conocidos sin parche. La migración acá es más urgente que en los otros escenarios. El proceso recomendado es reinstalar limpio en Rocky 10 o AlmaLinux 10, porque el camino de leapp CentOS 8 → RHEL 10 tiene demasiados saltos intermedios y es propenso a fallar con paquetes viejos.

El flujo limpio para un servidor CentOS 8 que quieres pasar a AlmaLinux 10:

# 1. Snapshot del sistema actual
sudo rsync -aAXv /etc/ /var/ /opt/ /home/ [email protected]:/backup/centos8-pre-migration/
# 2. Identificar paquetes críticos para reinstalar después
rpm -qa | sort > /tmp/packages-centos8.txt
sudo dnf repoquery --userinstalled | sort > /tmp/user-installed-centos8.txt
# 3. Instalar AlmaLinux 10 desde USB o ISO netboot
#    (particionar igual que CentOS 8, /home separado)
# 4. Después del primer boot, restaurar configs
scp [email protected]:/backup/centos8-pre-migration/etc.tar.gz .
sudo tar -xzf etc.tar.gz -C /
# 5. Reinstalar paquetes
sudo dnf install -y $(cat /tmp/user-installed-centos8.txt)

El paso de dnf repoquery --userinstalled es clave: te lista solo los paquetes que tú instalaste explícitamente, no las dependencias. Restaurar ese listado en el sistema nuevo te da una réplica funcional del viejo sin arrastrar basura. Después de la migración, corré sudo dnf check y sudo rpm -Va para encontrar archivos de config que cambiaron entre CentOS 8 y AlmaLinux 10.

Verificación post-migración: los chequeos que sí importan

Después de cualquier migración, hay un set mínimo de verificaciones que tienen que pasar antes de declarar el servidor en producción. Estos son los comandos que más problemas detectaron en mis migraciones:

# 1. Confirmar la versión
cat /etc/redhat-release
cat /etc/os-release
uname -r
# Debe decir Rocky Linux 10.x o AlmaLinux 10.x, kernel 6.12+
# 2. Servicios críticos
sudo systemctl --failed
sudo systemctl list-unit-files --state=enabled
# 3. Network
sudo nmcli connection show
ip addr show
# Verificar que la IP y rutas del viejo sistema estén aplicadas
# 4. SELinux y firewall
sudo getenforce
sudo firewall-cmd --list-all
# 5. Repos activos
sudo dnf repolist
# No debe haber repos de CentOS remanentes
sudo dnf repolist | grep -i centos

Si dnf repolist | grep -i centos devuelve algo, te quedaron repos viejos. Eso pasa cuando el script de migración no limpia /etc/yum.repos.d/ completo. La solución es borrar los .repo de CentOS manualmente y refrescar:

# Limpiar repos CentOS residuales
sudo rm -f /etc/yum.repos.d/CentOS-*.repo
sudo dnf clean all
sudo dnf repolist

Otro chequeo que ahorra incidentes: validar que el kernel activo es el nuevo. Después de un upgrade de major release, GRUB puede quedar apuntando al kernel viejo:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grubby --default-kernel
# Debe apuntar al kernel 6.12, no al anterior

Cuándo NO migrar a 10 y quedarse en 9

No todos los shops deberían saltar a RHEL 10. Las razones legítimas para quedarse en Rocky 9 o AlmaLinux 9:

Software legacy que no fue testeado con glibc 2.39+ o systemd 257+: las versiones que trae RHEL 10 son más nuevas y pueden romper binarios viejos que no se recompilaron.
Hardware anterior a Haswell (2014): Rocky 10 no bootea en CPUs sin x86-64-v3. La única opción acá es AlmaLinux 10, que soporta v2.
Dependencias de vendors que aún no certificaron contra RHEL 10: Oracle, SAP y algunos vendors de storage certifican contra RHEL 9 pero todavía no contra 10. verifica con tu vendor antes de migrar.
Stack de containers con imágenes base RHEL 9 que no quieres tocar: si todo tu pipeline CI/CD usa UBI 9, migrar el host a 10 sin migrar el pipeline genera fricción operativa.

Si alguno de estos puntos te pega, quedarte en Rocky 9 o AlmaLinux 9 hasta 2028 (cuando el ecosistema RHEL 10 madure) es la decisión correcta. El active support de RHEL 9 corre hasta 2027-05-31 y el security support hasta 2029-05-31, así que tienes margen.

Troubleshooting común que aparece en producción

Los tres problemas que aparecieron en todas las migraciones que hice, en orden de frecuencia:

1. Python 2 vs Python 3 en scripts de systemD o cron. CentOS 7 traía Python 2.7. Rocky y AlmaLinux 10 usan Python 3.12. Si tenías shebangs #!/usr/bin/python2 en scripts de cron, dejás de tener Python 2 después de la migración. La forma rápida de encontrarlos y arreglarlos:

# Buscar scripts con shebang python2
grep -rl '^#!/usr/bin/python2' /usr/local/bin/ /opt/ /etc/cron.* 2>/dev/null
# Reemplazar masivamente
sudo find /usr/local/bin/ -name '*.py' -exec sed -i 's|#!/usr/bin/python2|#!/usr/bin/python3|' {} ;

2. NetworkManager reemplazó network-scripts definitivamente. RHEL 10 usa solo NetworkManager. Los scripts legacy en /etc/sysconfig/network-scripts/ifcfg-* ya no existen por default. Si tenías configs de red custom en esos archivos, migrá a nmcli:

# Convertir ifcfg-eth0 a conexión NetworkManager
sudo nmcli connection add type ethernet ifname eth0 con-name eth0-static 
  ip4 192.168.5.50/24 gw4 192.168.5.1
sudo nmcli connection modify eth0-static ipv4.dns "192.168.5.1,1.1.1.1"
sudo nmcli connection up eth0-static

3. Drivers de terceros (NVIDIA, VMware, DKMS) que no compilan contra el kernel nuevo. El kernel 6.12 trae cambios en varias APIs internas que rompen DKMS de drivers viejos. Si tienes una GPU NVIDIA de data center o drivers de VMware, el camino seguro es desinstalar el driver antes de la migración y reinstalar la versión compatible con RHEL 10 después.

# Antes de la migración
sudo dnf remove kmod-nvidia xorg-x11-drv-vmware
# Después del primer boot en el sistema nuevo
sudo dnf install kmod-nvidia

Resumen: el árbol de decisión que uso

Después de hacer esto varias veces, el árbol de decisión que aplico es:

¿tienes hardware anterior a 2014? → AlmaLinux 10 (Rocky 10 no soporta tu CPU).
¿tienes CentOS 7 y quieres evitar reinstalar? → Dos saltos con leapp: CentOS 7 → AlmaLinux 9 → AlmaLinux 10.
¿tienes CentOS Stream 9 y quieres el camino más corto? → almalinux-deploy + ELevate, llegas a AlmaLinux 10 en una sesión.
¿Tu prioridad es estabilidad y certification strict? → Rocky 10 (reinstalación, no leapp 9→10).
¿tienes apps con dependencias de 32-bit? → AlmaLinux 10 (incluye i686 userspace).
¿tienes un servidor con paquetes legacy y config muy custom? → Reinstalación limpia en Rocky 10 o AlmaLinux 10, restaurás datos con rsync.

La regla que más me ahorró tiempo: si puedes tolerar una hora de downtime, reinstalá limpio. El leapp in-place ahorra tiempo de instalación pero te puede dejar configuraciones zombie que aparecen seis meses después en producción. Una instalación nueva con Ansible o tu sistema de config management te da un baseline conocido y reproducible.

Después de migrar, planificá la próxima transición. RHEL 11 sale en 2027, y los clones comunitarios van a seguir con un delay de 4-6 meses. Si el ciclo de upgrade cada 4 años te parece mucho, RHEL ofrece EUS (Extended Update Support) que te da parches durante 16 meses adicionales después del active support, pero es de pago. Para shops chicos o sysadmins independientes, quedarse en la versión N hasta que N+1 madure (12-18 meses) es la estrategia más común.

Preguntas frecuentes

¿Por qué Migración de CentOS a Rocky Linux 10 o AlmaLinux 10: Guía Definitiva para Sysadmins 2026 es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Migración de CentOS a Rocky?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Migración de CentOS a Rocky?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Migración de CentOS a Rocky y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Migración de CentOS a Rocky?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.