Cómo Mover Todas las Cuentas de cPanel de un Servidor a Otro

Migrar todas las cuentas de cPanel entre servidores es el proceso de transferir cada dominio alojado, sus archivos, bases de datos MySQL, cuentas de correo electrónico, zonas DNS, certificados SSL y trabajos cron desde una instancia WHM de origen a una instancia WHM de destino — generalmente utilizando la Herramienta de Transferencia de WHM integrada a través de una conexión SSH autenticada. Cuando se ejecuta correctamente, este proceso no requiere copiar archivos manualmente y preserva todos los metadatos de las cuentas intactos.

Esta guía cubre el flujo de trabajo completo de migración a nivel de producción: verificaciones previas, configuración de la Herramienta de Transferencia, estrategia de cambio de DNS, validación posterior a la migración y limpieza — incluyendo casos extremos que causan fallos silenciosos en entornos del mundo real.

Requisitos previos y lista de verificación previa a la migración

Omitir la preparación es la causa más común de migraciones de cPanel fallidas o incompletas. Antes de tocar cualquiera de los servidores, verifique cada elemento a continuación.

Acceso root en ambos servidores. La Herramienta de Transferencia de WHM se autentica en el servidor de origen a través de SSH como root. Si el servidor de origen tiene PermitRootLogin no en /etc/ssh/sshd_config, debe habilitarlo temporalmente o preconfigurar la autenticación SSH basada en claves para root.

Versiones de cPanel/WHM compatibles. cPanel puede transferir cuentas de versiones más antiguas a más nuevas, pero no a la inversa. Un destino que ejecuta cPanel 110 puede obtener datos de un origen que ejecuta cPanel 98, pero lo contrario fallará. Verifique las versiones en WHM en Información del Servidor o ejecute:

cat /usr/local/cpanel/version

Versiones de PHP y MySQL coincidentes o compatibles. Si el origen ejecuta PHP 7.4 y MySQL 5.7 mientras el destino ejecuta PHP 8.2 y MySQL 8.0, las aplicaciones pueden fallar después de la transferencia incluso si los archivos se copian correctamente. Audite las versiones de PHP instaladas y los manejadores predeterminados en ambos servidores antes de continuar.

Espacio en disco suficiente en el destino. La Herramienta de Transferencia requiere espacio libre igual al menos al tamaño total comprimido de todas las cuentas que se transfieren, más margen para la extracción. Ejecute df -h en el destino y compárelo con el uso total de disco de las cuentas visible en la vista Listar Cuentas de WHM en el origen.

Reglas de firewall que permitan SSH entre servidores. El servidor de destino inicia una conexión SSH saliente al origen. Asegúrese de que el puerto 22 (o el puerto SSH personalizado) esté abierto en el firewall del servidor de origen para la dirección IP del destino.

Copias de seguridad completas de las cuentas en el origen. Genere una copia de seguridad completa de cPanel para cada cuenta antes de comenzar. Este es su punto de recuperación si la transferencia corrompe o copia parcialmente una cuenta.

/scripts/pkgacct username /backup/directory

Si está ejecutando su nuevo entorno en un plan de Hosting VPS, confirme que su VPS ya tenga cPanel/WHM con licencia e instalado antes de continuar. Una instalación nueva de cPanel requiere una licencia válida vinculada a la dirección IP del servidor.

Paso 1: Instalar y configurar cPanel/WHM en el servidor de destino

Si cPanel aún no está instalado en el destino, ejecute el instalador oficial como root. Este proceso tarda entre 20 y 45 minutos dependiendo del hardware:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

Una vez completada la instalación, acceda a WHM en https://your-server-ip:2087 y complete el asistente de configuración inicial. Preste especial atención a:

• Nombre de host: Establezca un nombre de dominio completamente calificado (FQDN) que resuelva a la IP del servidor. Un nombre de host que no se puede resolver causa fallos en la entrega de correo después de la migración.
• Servidores de nombres: Configure los nombres de host de sus servidores de nombres y sus direcciones IP si planea alojar DNS en el nuevo servidor.
• Manejadores PHP: Instale las mismas versiones de PHP disponibles en el servidor de origen usando WHM > MultiPHP Manager para evitar incompatibilidades en las aplicaciones.
• Versión de MySQL/MariaDB: Haga coincidir la versión del motor de base de datos del servidor de origen donde sea posible, o pruebe la compatibilidad de las aplicaciones con la versión más nueva antes de migrar las cuentas de producción.

Para equipos que gestionan múltiples entornos de clientes, un VPS con cPanel proporciona un entorno preconfigurado que elimina por completo la fase de instalación manual.

Paso 2: Configurar la Herramienta de Transferencia de WHM

La Herramienta de Transferencia de WHM es el método autorizado para la migración masiva de cuentas. Gestiona el empaquetado, la transferencia, la extracción y la creación de cuentas de forma atómica para cada cuenta.

2.1 Acceder a la Herramienta de Transferencia

En el servidor de destino, inicie sesión en WHM y navegue a:

WHM > Transferencias > Herramienta de Transferencia

Este es un punto crítico que confunde a muchos administradores: la Herramienta de Transferencia siempre se ejecuta desde el servidor de destino que obtiene las cuentas del origen — no al revés.

2.2 Conectarse al servidor de origen

Ingrese los siguientes detalles de conexión:

• Dirección del servidor remoto: Dirección IP o nombre de host del servidor de origen
• Puerto SSH remoto: El predeterminado es 22; use el puerto real si fue cambiado (verifique /etc/ssh/sshd_config en el origen para la directiva Port)
• Método de autenticación: Contraseña root o clave SSH (se prefiere ampliamente la autenticación basada en claves por seguridad y fiabilidad)

Para usar autenticación por clave SSH, copie la clave pública root del servidor de destino al origen:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Una vez conectada, la Herramienta de Transferencia consulta el servidor de origen y devuelve una lista de todas las cuentas de cPanel, paquetes y configuraciones de revendedor.

2.3 Seleccionar cuentas y alcance de la transferencia

Puede seleccionar todas las cuentas o un subconjunto. Más allá de las cuentas individuales, la Herramienta de Transferencia también ofrece:

• Paquetes: Transferir definiciones de planes de hosting para que las cuentas conserven sus asignaciones de recursos
• Zonas DNS: Copiar todos los archivos de zona, lo cual es esencial si el nuevo servidor actuará como servidor de nombres autoritativo
• Privilegios de revendedor y ACLs: Preservar las configuraciones de cuentas de revendedor y sus permisos asociados

2.4 Configurar las opciones de transferencia

Dos configuraciones aquí tienen un impacto operativo significativo:

Transferencia Express automatiza el cambio de DNS actualizando las zonas DNS en el servidor de origen para apuntar a la IP del destino inmediatamente después de que se copia cada cuenta. Esto minimiza la ventana durante la cual un dominio resuelve al servidor antiguo. Úselo solo si el destino está listo para servir tráfico de inmediato y ha confirmado que todas las aplicaciones funcionan correctamente.

Enrutamiento de correo: Configúrelo en Automático a menos que tenga una razón específica para forzar el enrutamiento local o remoto. El enrutamiento de correo incorrecto es una de las principales causas de fallos en la entrega de correo electrónico después de la migración.

2.5 Iniciar la transferencia

Haga clic en Copiar para iniciar el proceso. WHM:

1. Se conectará por SSH al servidor de origen
2. Ejecutará pkgacct para crear un archivo comprimido de cada cuenta
3. Transferirá el archivo al destino a través de SSH/SCP
4. Ejecutará restorepkg en el destino para extraer y crear la cuenta
5. Registrará el resultado de cada cuenta

Monitoree el registro de transferencia en vivo con atención. Los errores en cuentas individuales no detienen el proceso general — una cuenta puede fallar silenciosamente mientras otras tienen éxito. Revise el registro completo después de que finalice la transferencia y vuelva a ejecutar las cuentas fallidas individualmente.

La duración de la transferencia depende del volumen total de datos y el ancho de banda entre servidores. Un servidor con 50 GB de datos de cuentas a través de un enlace de 1 Gbps generalmente completa en menos de 30 minutos. A través de un enlace de 100 Mbps, calcule entre 60 y 90 minutos.

Paso 3: Estrategia de cambio de DNS

La gestión de DNS es donde las migraciones con mayor frecuencia generan tiempos de inactividad prolongados. Comprender la mecánica de propagación es esencial para minimizar el impacto en los usuarios.

3.1 Reducir el TTL antes de la migración

Idealmente, entre 24 y 48 horas antes de la migración, reduzca el TTL en todos los registros A de los dominios alojados a 300 segundos (5 minutos). Esto garantiza que una vez que actualice los registros DNS, el cambio se propague globalmente en minutos en lugar de horas. Si no lo hizo con anticipación, debe tener en cuenta el valor TTL existente como su ventana máxima de propagación.

3.2 Actualizar zonas DNS

Si el nuevo servidor es el servidor de nombres autoritativo para los dominios, actualice los registros A en cada archivo de zona a través de WHM > Funciones DNS > Editar Zona DNS, cambiando la IP de la dirección del servidor antiguo a la nueva.

Si los dominios usan un proveedor de DNS externo o DNS del registrador, inicie sesión en cada registrador o panel de gestión de DNS y actualice los registros A manualmente. Para actualizaciones masivas en muchos dominios, la mayoría de los registradores ofrecen acceso a API o importación CSV.

3.3 Actualizar los registros glue de los servidores de nombres

Si también está migrando servidores de nombres (por ejemplo, ns1.yourdomain.com), debe actualizar los registros glue en el registrador de dominios — no solo el archivo de zona. Los registros glue son mapeos de direcciones IP para servidores de nombres registrados bajo el mismo dominio al que sirven. No actualizar los registros glue es un error común que causa un fallo completo en la resolución DNS para todos los dominios alojados.

3.4 Verificar la propagación

Use dig para verificar la resolución desde múltiples ubicaciones geográficas:

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Compruebe con un verificador de propagación basado en web. La propagación global completa generalmente se completa en 1 a 4 horas cuando el TTL se redujo previamente, o hasta 48 horas cuando el TTL no se redujo con anticipación.

Si sus dominios están registrados a través de Registro de Dominios, las actualizaciones de servidores de nombres se pueden gestionar directamente desde el mismo panel de control, simplificando el proceso de cambio.

Paso 4: Validación posterior a la migración

Nunca declare una migración completa basándose únicamente en el registro de éxito de la Herramienta de Transferencia. Valide cada capa del stack de forma independiente.

4.1 Funcionalidad de la aplicación web

Acceda a cada dominio transferido directamente por IP usando una anulación del archivo hosts (para evitar la propagación de DNS) y verifique que la aplicación carga correctamente:

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Verifique errores de conexión a la base de datos, rutas de archivos faltantes y configuraciones de aplicaciones rotas. Los sitios WordPress comúnmente fallan si las credenciales de base de datos en wp-config.php hacen referencia a localhost pero la ruta del socket MySQL difiere entre servidores.

4.2 Integridad de la base de datos

Inicie sesión en cPanel para cada cuenta y verifique que las bases de datos existan y sean accesibles. Para bases de datos críticas, ejecute una verificación de integridad:

mysqlcheck -u root -p --all-databases --check

4.3 Funcionalidad del correo electrónico

Pruebe el correo entrante y saliente para cada cuenta. Verifique que los registros MX resuelvan correctamente y que el servidor de correo acepte conexiones en los puertos 25, 465 y 587. Verifique /var/log/exim_mainlog para errores de entrega:

tail -f /var/log/exim_mainlog

Para empresas con infraestructura de correo dedicada, el Hosting de Correo Electrónico proporciona entornos de correo aislados que no se ven afectados por las migraciones del servidor web.

4.4 Verificación de certificados SSL

Confirme que los certificados SSL se transfirieron correctamente y están activos. En WHM, navegue a SSL/TLS > Gestionar Hosts SSL y verifique que cada dominio tenga un certificado válido y no vencido. AutoSSL debería reemitir automáticamente los certificados Let’s Encrypt para los que no se transfirieron, pero actívelo manualmente para evitar esperar la ejecución programada:

/usr/local/cpanel/bin/autossl_check --all

Si gestiona certificados de forma independiente, los Certificados SSL se pueden instalar directamente en el nuevo servidor sin depender del proceso de transferencia.

4.5 Trabajos cron y tareas programadas

Los trabajos cron se transfieren como parte del paquete de cuenta, pero verifíquelos en cPanel > Trabajos Cron para cada cuenta. Preste especial atención a los trabajos cron que hacen referencia a rutas de archivos absolutas o variables de entorno específicas del servidor que pueden diferir en el nuevo servidor.

Paso 5: Limpieza y refuerzo posterior a la migración

5.1 Suspender cuentas en el servidor de origen

Una vez que el DNS se haya propagado y la validación esté completa, suspenda todas las cuentas en el servidor de origen a través de WHM > Listar Cuentas > Suspender. No las elimine todavía. La suspensión evita que se escriban nuevos datos en el origen mientras lo mantiene disponible como alternativa si surge un problema crítico después de la migración.

5.2 Copia de seguridad posterior a la migración

Cree una copia de seguridad completa y nueva de todas las cuentas en el nuevo servidor inmediatamente después de la migración. El estado transferido es su nueva línea base:

/scripts/cpbackup --force

Verifique que las copias de seguridad se completen correctamente y se almacenen en una ubicación separada del propio servidor — idealmente un destino de copia de seguridad externo al servidor configurado en WHM > Configuración de Copias de Seguridad.

5.3 Monitoreo del rendimiento

Monitoree la utilización de recursos del nuevo servidor durante 72 horas después de la migración. Métricas clave a observar:

• Promedio de carga de CPU (debe permanecer por debajo del número de núcleos de CPU bajo carga normal)
• Uso de memoria y actividad de swap
• Tiempo de espera de E/S de disco (un tiempo de espera de E/S elevado indica cuellos de botella en el almacenamiento)
• Registro de consultas lentas de MySQL para consultas que funcionan mal con el nuevo esquema o versión del motor

Use top, iostat y vmstat para monitoreo en tiempo real, y revise el Monitor de Recursos de cPanel en WHM para el consumo de recursos por cuenta.

5.4 Descomisionar el servidor de origen

Después de un período mínimo de observación de 7 días sin problemas reportados, puede descomisionar el servidor de origen. Antes de terminar el servidor antiguo, archive una copia de seguridad final en almacenamiento en frío. Este archivo sirve como registro legal y operativo y cuesta muy poco conservarlo.

Comparación de métodos de migración de cuentas cPanel

Errores comunes y cómo evitarlos

Fallos silenciosos en la transferencia de cuentas. La Herramienta de Transferencia continúa procesando incluso cuando fallan cuentas individuales. Siempre lea el registro de transferencia completo — no asuma el éxito porque la herramienta terminó sin detenerse.

Discrepancia en los privilegios de usuario de MySQL. restorepkg recrea los usuarios de la base de datos, pero si un nombre de usuario de base de datos supera el límite de 32 caracteres de MySQL (un problema común con cuentas heredadas), el usuario se crea con un nombre truncado y las credenciales de base de datos de la aplicación ya no coinciden. Audite los nombres de usuario de base de datos largos antes de migrar.

Dependencias de módulos Perl y software personalizado. Las aplicaciones que dependen de módulos Perl compilados de forma personalizada, paquetes Python o bibliotecas del sistema instaladas fuera de las rutas gestionadas por cPanel no se transferirán. Estas dependencias deben reinstalarse manualmente en el destino.

Discrepancias en las cuotas de disco. El sistema de cuotas de disco de cPanel utiliza cuotas a nivel de sistema de archivos. Después de la migración, las cuotas pueden no reflejarse con precisión hasta que se ejecute el script de recálculo de cuotas:

/scripts/fixquotas

Conflictos de reglas de ModSecurity. Si el servidor de origen tenía reglas de ModSecurity personalizadas o una versión de conjunto de reglas diferente a la del destino, los sitios transferidos pueden recibir errores 403 inesperados. Revise los registros de ModSecurity en /usr/local/apache/logs/error_log después de la migración.

Brechas en los permisos de cuentas de revendedor. Las ACLs de revendedor y las asignaciones de paquetes se transfieren, pero si el WHM de destino tiene listas de funciones diferentes configuradas, los revendedores pueden encontrar que sus cuentas tienen menos capacidades o diferentes a las esperadas. Audite las configuraciones de revendedor después de la migración.

Para entornos de alto tráfico donde la tolerancia al tiempo de inactividad es casi nula, considere ejecutar la migración en un Servidor Dedicado con recursos dedicados, eliminando el riesgo de contención de recursos durante las fases de transferencia y validación.

Matriz de decisión técnica

Use esta matriz para determinar su enfoque de migración según las características del entorno:

Preguntas frecuentes

¿Puedo migrar cuentas de cPanel sin acceso root al servidor de origen?

No. La Herramienta de Transferencia de WHM requiere acceso SSH root al servidor de origen para ejecutar pkgacct y leer todos los datos de las cuentas. Si el acceso root no está disponible, la única alternativa es solicitar archivos de copia de seguridad individuales de cPanel (archivos .tar.gz) al administrador del servidor de origen y restaurarlos manualmente usando restorepkg en el destino.

¿Cuánto tiempo tarda una migración completa de servidor cPanel?

El tiempo de transferencia depende del volumen total de datos y el ancho de banda de red entre servidores. Un servidor con 100 GB de datos de cuentas a través de un enlace dedicado de 1 Gbps generalmente se transfiere en 15 a 30 minutos. A través de conexiones compartidas o limitadas, los mismos datos pueden tardar varias horas. La propagación de DNS agrega entre 1 y 48 horas adicionales dependiendo de los valores TTL.

¿Los certificados SSL se transfieren automáticamente?

Los certificados SSL instalados a través de AutoSSL (Let’s Encrypt) no se transfieren como certificados válidos — son reemitidos por AutoSSL en el servidor de destino porque están vinculados a la IP del servidor y a la cuenta. Los certificados comprados comercialmente almacenados en cPanel sí se transfieren como parte del paquete de cuenta, pero deben verificarse y reactivarse después de la migración.

¿Qué sucede con el correo electrónico en el servidor antiguo durante la ventana de migración?

El correo electrónico entregado al servidor antiguo durante la ventana de migración se almacena en la cola de correo y los buzones de usuario del servidor antiguo. No se replica automáticamente al nuevo servidor. Para evitar la pérdida de correo, mantenga los servicios de correo del servidor antiguo en funcionamiento hasta que el DNS se propague completamente, o configure el Exim del servidor antiguo para reenviar el correo entrante a la IP del nuevo servidor durante el período de transición.

¿Puede la Herramienta de Transferencia de WHM migrar cuentas entre diferentes sistemas operativos (por ejemplo, de CentOS a AlmaLinux)?

Sí. La Herramienta de Transferencia es agnóstica al sistema operativo en la capa de aplicación — transfiere datos de cuentas de cPanel, no configuraciones a nivel de sistema operativo. Las migraciones de CentOS 7 a AlmaLinux 8 o Rocky Linux 8 son totalmente compatibles y son el escenario de migración más común tras el fin de vida de CentOS 7. Verifique que cualquier configuración personalizada a nivel de sistema (políticas SELinux, módulos de kernel personalizados, servicios fuera de cPanel) se replique manualmente en el destino.