Cambiar de proveedor de alojamiento es un evento habitual en la vida de un sitio WordPress: fin de contrato, necesidad de más rendimiento, paso a un modelo autoalojado. El riesgo casi nunca viene de copiar los archivos en sí, sino del cambio de DNS y del orden en que se encadenan los pasos. Una migración bien preparada se reduce a unos pocos ajustes hechos varios días antes, no el mismo día.
Por qué el cambio de DNS es el punto de ruptura
Cada registro DNS tiene un tiempo de vida, el TTL (Time To Live), expresado en segundos. Mientras ese plazo no haya pasado, los resolutores DNS intermedios —los de los proveedores de acceso, los navegadores, las cachés corporativas— siguen respondiendo con la dirección IP antigua. Con un TTL por defecto de 86.400 segundos (24 horas), parte de los visitantes puede seguir llegando al servidor antiguo durante todo un día después del cambio, lo cual es un problema en cuanto el servidor antiguo se apaga o el contenido empieza a divergir entre los dos entornos.
| Plazo | Acción | Objetivo |
|---|---|---|
| Día -3 | Bajar el TTL del registro A a 300 segundos | Reducir la ventana de propagación antes del cambio |
| Día -1 | Copiar archivos y base de datos al nuevo alojamiento, probar en local con el archivo hosts | Validar el sitio sin tocar el DNS de producción |
| Día 0, mañana | Sincronización final (delta) y cambio del DNS | Minimizar la diferencia de contenido entre las dos copias |
| Día 0, unas horas después | Revisar los registros de ambos servidores, confirmar que el tráfico ha cambiado | Asegurarse de que ningún visitante se queda en el servidor antiguo |
| Día +7 | Apagar el alojamiento antiguo | Dejar margen para las cachés DNS más lentas |
Preparar el nuevo alojamiento antes de copiar nada
Antes de mover un solo archivo, el nuevo entorno debe estar listo para recibir el sitio en condiciones iguales o mejores que las actuales: al menos la misma versión de PHP, las mismas extensiones activas, un certificado TLS ya instalado para el dominio final. En un panel de autoalojamiento como el ya tratado para alojar WordPress uno mismo con CloudPanel, este paso se limita a crear el sitio y su certificado antes de cualquier copia. Preparar este entorno con antelación permite probar la configuración del servidor (reescritura de URL, límites de memoria PHP, configuración de caché) de forma independiente a la migración del contenido, separando los problemas de configuración de los problemas de datos.
Sincronizar archivos y base de datos sin errores
La copia se hace en dos flujos distintos: los archivos mediante rsync o una transferencia SFTP, la base de datos mediante una exportación SQL. WP-CLI simplifica bastante este paso en un servidor autoalojado, en particular para sustituir las URL guardadas en campos serializados, que las herramientas genéricas de buscar y reemplazar suelen dañar.
# En el servidor antiguo: exportación limpia de la base de datos
wp db export backup.sql --add-drop-table
# Copia de los archivos, excluyendo caché y logs
rsync -avz --exclude 'wp-content/cache' --exclude '*.log' \
./ user@nuevo-servidor:/var/www/site/
# En el nuevo alojamiento: importación y reescritura de las URL
wp db import backup.sql
wp search-replace 'https://dominio-antiguo.tld' 'https://dominio-nuevo.tld' \
--all-tables --precise
Elegir wp search-replace en lugar de un reemplazo de texto plano evita romper los arrays y objetos PHP serializados que WordPress guarda en ciertos campos (widgets, opciones de tema, datos de constructores de página): un reemplazo ingenuo cambia la longitud de una cadena sin actualizar el contador de caracteres que la precede, lo que corrompe el dato de forma silenciosa.
Cambiar el DNS y comprobar antes de apagar el servidor antiguo
Una vez hecha la sincronización final, actualizar el registro DNS activa el cambio progresivo del tráfico. Este es el momento de vigilar en paralelo los registros de acceso de ambos servidores: una bajada progresiva del tráfico en el antiguo y una subida simétrica en el nuevo confirman una propagación normal. Probar el sitio desde varias redes (móvil, línea fija, VPN) da una imagen más fiel de lo que ven realmente los visitantes que probarlo desde un solo equipo.
Bajar el TTL a 300 segundos tres días antes del cambio reduce la ventana de propagación del DNS a unos minutos, frente a varias horas con el valor por defecto de 86.400 segundos.
Punto de atención: no apagar el alojamiento antiguo en cuanto el nuevo responda correctamente. Los resolutores DNS más lentos y algunas cachés corporativas pueden conservar la respuesta antigua varios días más allá del TTL indicado. Mantener el servidor antiguo activo, aunque sea solo en lectura, durante al menos una semana evita que algunos visitantes se encuentren con una página en blanco.
Los errores más habituales de una migración mal preparada
Tres errores se repiten con más frecuencia. El primero es cambiar el DNS antes de probar el sitio en el nuevo alojamiento: sin cambio de DNS, una prueba mediante el archivo local hosts (apuntando temporalmente el dominio a la nueva IP desde un solo equipo) permite validar el aspecto y las funciones sin exponer al público un sitio todavía inestable. El segundo es olvidar las URL fijadas en extensiones de terceros: constructores de página, plugins de formularios o pasarelas de pago a veces guardan la dirección antigua fuera de las tablas cubiertas por wp search-replace --all-tables, lo que obliga a revisar también los archivos de configuración propios de esas extensiones. El tercero afecta a las tareas programadas (cron de WordPress o cron del sistema): una copia de seguridad automática o un envío masivo de correos aún configurado para dispararse en el servidor antiguo puede seguir funcionando por duplicado varios días si nadie piensa en desactivarlo.
Un contrato de alojamiento con fecha de finalización fija añade otra restricción: conviene fijar el cambio de DNS varios días antes del vencimiento del contrato, y no el mismo día, para conservar un margen si algún imprevisto retrasa la comprobación final.
Limpiar y vigilar tras la migración
Una vez confirmado el cambio, queda por actualizar los servicios de terceros que apuntan explícitamente a la antigua dirección IP o al antiguo servidor: robots de copia de seguridad, servicio de monitorización, un posible cortafuegos de aplicación, y los registros SPF si el envío de correos pasa por el mismo alojamiento. También es un buen momento para revisar de nuevo la base mínima de hardening en el nuevo servidor, cuyos ajustes por defecto suelen ser distintos a los del alojamiento anterior. Una revisión de Search Console unos días después de la migración ayuda a detectar un posible error de rastreo debido a un certificado TLS mal configurado o a una regla de reescritura olvidada en el nuevo servidor.
Lo que hay que recordar
El riesgo de una migración de alojamiento casi nunca viene de copiar los datos, sino del retraso de propagación del DNS y del orden de las operaciones alrededor de ese cambio. Bajar el TTL varios días antes, validar el nuevo entorno antes de tocar el DNS, y mantener el servidor antiguo activo una semana tras el cambio cubre la mayoría de los escenarios de interrupción evitables.
La migración fallida más habitual que he visto siempre viene del mismo descuido: el TTL dejado en su valor por defecto, descubierto solo cuando el servidor antiguo ya está apagado. Bajar el TTL con tres días de antelación cuesta cinco minutos de configuración y evita casi todos los incidentes de cambio que sigo solucionando de urgencia para clientes — Simon Janvier.
Para saber más: la documentación oficial del comando wp search-replace.
