Cómo migrar de cPanel a un VPS sin tiempo de inactividad

La mayoría de la gente se queda en un hosting compartido mucho después de haberlo superado, y casi nunca porque un VPS sea demasiado caro. Es porque la mudanza parece arriesgada. Una docena de sitios, un puñado de bases de datos, buzones que los clientes usan a diario, DNS repartidos entre dos registradores — y el temor persistente de que algo se quede caído un día entero mientras lo averiguas. La buena noticia: una migración hecha en el orden correcto no tiene ningún tiempo de inactividad visible. El truco es que casi todo el trabajo ocurre antes de cambiar un solo registro DNS. Este es el plan.

Paso 0: haz inventario antes de tocar nada

Todas las migraciones dolorosas empiezan con «nos olvidamos de…». Antes de copiar un solo byte, apunta lo que realmente vive en la cuenta antigua:

• Dominios: principal, dominios adicionales y aparcados, subdominios, y dónde está alojado el DNS de cada uno (el registrador, el hosting compartido, Cloudflare…).
• Bases de datos: cada base MySQL y qué sitio la usa. Las cuentas cPanel antiguas acumulan bases huérfanas de instalaciones abandonadas; este es el momento de eliminarlas.
• Versión de PHP y extensiones por sitio. Un sitio que lleva años funcionando discretamente en PHP 7.4 no tiene por qué sobrevivir a 8.3 el primer día.
• Tareas cron, invisibles hasta que la exportación nocturna deja de llegar.
• Correo: buzones, reenvíos, respuestas automáticas, cuentas comodín — y, a grandes rasgos, cuánto correo hay almacenado.
• Reglas .htaccess: redirecciones, carpetas protegidas con contraseña, reglas de reescritura. Si tu nuevo servidor usa Nginx, ninguna se lee. Hay que traducirlas.
• SSL: qué dominios tienen certificado y si hay certificados de pago que trasladar.

Esta lista se convierte al final en tu plan de pruebas.

Paso 1: baja el TTL de DNS uno o dos días antes

Los registros DNS llevan un TTL (time to live): cuánto tiempo pueden los resolvers guardar la respuesta en caché. Los hostings compartidos suelen usar 14400 segundos (4 horas) o incluso 86400 (un día entero). Si cambias el registro A con un TTL de un día, algunos visitantes siguen llegando al servidor antiguo durante hasta un día.

Así que entre 24 y 48 horas antes de la mudanza, baja el TTL de los registros A, AAAA y MX a 300 segundos. Luego espera a que caduque el TTL antiguo. Comprueba lo que ve el mundo ahora mismo:

dig +noall +answer example.com A
dig +noall +answer example.com MX

La segunda columna es el TTL restante. En cuanto muestre 300, un cambio se propaga en unos cinco minutos — y una vuelta atrás también, si la necesitas.

Paso 2: consigue un archivo de copia de seguridad completo

En cPanel, usa Copia de seguridad → Descargar una copia completa de la cuenta. Si tienes acceso root al servidor antiguo, /scripts/pkgacct usuario genera el mismo archivo más rápido. En Plesk, usa el Administrador de copias de seguridad. El archivo contiene el directorio personal (con public_html), cada base de datos como volcado SQL, los buzones y los datos de la zona DNS.

Llévalo directamente al servidor nuevo en lugar de pasarlo por tu portátil — cPanel puede enviar la copia a un servidor remoto por SCP, o puedes descargarla con wget desde la máquina nueva. Los archivos de varios gigabytes por una conexión doméstica son justo donde se atascan las migraciones.

Si no te fías del archivo completo (las cuentas muy grandes a veces agotan el tiempo), copia archivos y bases por separado:

# en el servidor nuevo: copiar la raíz web
rsync -avz --progress olduser@old-host:public_html/ /var/www/example/public_html/

# en el hosting antiguo: volcar una base de datos
mysqldump --single-transaction --routines --triggers olduser_wp > olduser_wp.sql

--single-transaction te da una instantánea coherente de InnoDB sin bloquear el sitio en producción.

Paso 3: reconstruye el sitio en el VPS

En el servidor nuevo, crea el sitio — su propio usuario Linux, raíz web, pool PHP-FPM y vhost — y luego importa archivos y datos:

mysql -e "CREATE DATABASE example_wp; CREATE USER 'example_wp'@'localhost' IDENTIFIED BY 'una-contrasena-larga-y-aleatoria'; GRANT ALL ON example_wp.* TO 'example_wp'@'localhost';"
mysql example_wp < olduser_wp.sql

cPanel antepone el nombre de la cuenta a los nombres de las bases (olduser_wp). En el servidor nuevo casi seguro usarás otros nombres, usuarios y contraseñas, así que actualiza la configuración de la aplicación — wp-config.php, el .env de Laravel, etc. Después corrige la propiedad para que el usuario del sitio sea dueño de sus archivos, y mantén la versión de PHP con la que funcionaba el sitio. Sube de versión más adelante, como un paso aparte y deliberado.

Paso 4: prueba el servidor nuevo antes de que el DNS sepa que existe

Puedes navegar por el servidor nuevo con el dominio real sin cambiar el DNS público. Apunta el dominio a la nueva IP en tu archivo hosts local, o prueba desde la línea de comandos:

curl -I --resolve example.com:80:203.0.113.10 http://example.com/

Recorre el sitio, entra en el área de administración, envía un formulario, revisa el registro de errores. Aquí es donde encuentras la extensión de PHP que falta, la ruta absoluta escrita a fuego hacia /home/olduser/ y la redirección que solo existía en .htaccess.

Paso 5: el correo, la parte que todo el mundo subestima

Los sitios web son lo bastante estáticos como para copiarlos dos veces; el correo no. Sigue llegando correo nuevo durante la mudanza, y los usuarios notan al instante cuando falta algo. Tienes tres opciones:

1. Dejar el correo donde está por ahora y mover solo los sitios. Los registros MX siguen apuntando al hosting antiguo. Es perfectamente válido, y divide una mudanza arriesgada en dos fáciles.
2. Mover el correo a un proveedor de correo dedicado.
3. Alojar el correo en tu VPS. Crea los buzones en el servidor nuevo y copia los mensajes existentes por IMAP con imapsync:

imapsync --host1 old-host.example --user1 info@example.com --password1 'antigua' \
         --host2 new-host.example --user2 info@example.com --password2 'nueva'

Ejecútalo una vez antes del cambio y otra después del cambio de MX para recoger los rezagados. Antes de llevar el correo a tu propio servidor, infórmate sobre SPF, DKIM, DMARC y el DNS inverso — una IP nueva sin reputación es exactamente de lo que desconfían los filtros antispam.

Paso 6: el cambio

Con un TTL de 300 segundos y un servidor probado, el cambio en sí no tiene nada de dramático:

1. Congela los cambios en los sitios dinámicos (nada de nuevas entradas, pedidos ni actualizaciones de plugins durante la próxima hora).
2. Haz una última sincronización diferencial: vuelve a ejecutar rsync (solo se transfieren los archivos modificados) y vuelve a volcar e importar las bases de datos.
3. Cambia los registros A y AAAA a la nueva IP. Cambia el MX solo si mueves el correo ahora.
4. Emite los certificados SSL en cuanto el DNS resuelva al servidor nuevo — el desafío HTTP de Let's Encrypt exige que el dominio apunte a la máquina que solicita el certificado.
5. Vigila el registro de accesos del servidor antiguo. Cuando el tráfico allí se agote, la propagación ha terminado.
6. Conserva el hosting antiguo al menos una semana. Es tu vuelta atrás y el archivo de cualquier cosa que hayas olvidado.

Las trampas detrás de las historias de «estuvo caído todo el fin de semana»

• Cambiar el DNS con un TTL de 24 horas. Un TTL largo no se puede deshacer a posteriori. Bájalo primero.
• .htaccess en Nginx. Las redirecciones y carpetas protegidas dejan de funcionar sin avisar. Tradúcelas a la configuración del servidor.
• Rutas y URL escritas a fuego. Busca en el código y en la base de datos /home/olduser y las versiones http:// del dominio.
• Tareas cron olvidadas. Vuelve a crearlas, con el binario de PHP adecuado para la versión del sitio.
• Cancelar la cuenta antigua demasiado pronto. Cancélala solo cuando el servidor nuevo lo haya servido todo — web y correo — durante una semana.
• Cambiarlo todo a la vez. Servidor nuevo, versión de PHP nueva, correo nuevo y actualización del tema la misma noche significa que no sabrás qué cambio rompió las cosas. Primero muda, después moderniza.

Cómo ShadowPanel automatiza la mudanza

ShadowPanel es un panel de control de hosting autoalojado, y dejar cPanel o Plesk es un flujo integrado en lugar de una tarde de comandos de shell.

• Importa un archivo de copia de seguridad de cPanel o Plesk. Deja el archivo en la carpeta de migraciones del panel por SFTP (la opción correcta para copias grandes) o sube las más pequeñas desde el navegador. El panel lo inspecciona en modo solo lectura, detecta si viene de cPanel o de Plesk y lista los dominios, bases de datos y buzones que ha encontrado.
• Elige qué traer. Indica el dominio de destino y la versión de PHP, si importar los archivos, qué bases y qué buzones. La migración se ejecuta entonces como tarea en segundo plano: crea el sitio con su propio usuario Linux aislado, pool PHP-FPM y vhost de Nginx, copia la raíz web a su sitio e importa cada base bajo un nombre, usuario y contraseña gestionados nuevos. El resultado asocia cada base original con su nuevo nombre, así que actualizar la configuración de la app es cosa de dos minutos.
• Los buzones se crean con contraseñas nuevas, que se muestran una sola vez al final para que puedas repartirlas — los hashes de contraseña del hosting antiguo no se pueden reutilizar. Los mensajes almacenados no se copian, así que el imapsync del paso 5 sigue siendo válido.
• ¿Ya copiaste un sitio a mano? La función Importar sitio existente adopta un sitio que ya está en el disco del servidor. Muestra una vista previa del tamaño, el número de archivos, la aplicación detectada y la versión de PHP, y deduce la base de datos a partir de wp-config.php o .env. Después copia los archivos a la estructura gestionada — nunca los mueve, así que el original queda intacto —, hace copia de cualquier vhost existente y adopta o emite el certificado SSL.
• El hueco de .htaccess lo cubren las redirecciones y rutas protegidas con contraseña por sitio en el panel, y los certificados se emiten y renuevan automáticamente (consulta SSL gratis con Let's Encrypt).

Ambas herramientas de importación son solo para administradores, ya que actúan sobre todo el servidor. Si aún no has elegido servidor, instalar un panel de hosting en un VPS de Hetzner cubre la puesta en marcha de principio a fin.

En resumen

Una migración sin tiempo de inactividad es sobre todo cuestión de orden: hacer inventario, bajar el TTL pronto, reconstruir y probar en el servidor nuevo mientras el antiguo sigue sirviendo, tratar el correo como un proyecto aparte y luego cambiar el DNS con un TTL corto y el hosting antiguo como red de seguridad. Ningún paso es difícil. Lo que duele es saltarse uno. ShadowPanel toma un archivo de cPanel o Plesk y convierte la reconstrucción — sitio, aislamiento, archivos, bases de datos, buzones — en una importación guiada, para que dediques tu atención a probar y no a la fontanería.

curl -fsSL https://shadowpanel.de/install.sh | bash

Ver precios y descargar →