Migrar a un nuevo hosting sin tiempo de inactividad: el paso a paso que usamos

Mover un sitio WordPress entre proveedores de hosting es una tarea que suena sencilla y que, en la práctica, está llena de pequeñas trampas. Una migración mal hecha puede perder visitantes, romper formularios, extraviar contenido reciente o, lo peor de todo, dejar el sitio en un estado en el que durante días unos visitantes llegan al hosting antiguo y otros al nuevo.

Bien ejecutada, una migración es invisible para los visitantes y libre de estrés para el dueño del negocio. Esta es la secuencia exacta de ocho pasos que usamos en Defyn para mover sitios WordPress, refinada a lo largo de más de cien migraciones.

Paso 1: Audita antes de tocar nada

Antes de que el nuevo hosting tenga la base de datos, antes de que el DNS se acerque a cualquier cambio, enumera todo lo que importa. Versiones de plugins, código personalizado, tareas programadas, integraciones de terceros, pasarelas de pago, cuentas de correo, registros DNS, proveedor del certificado SSL, claves antispam, destinos de copias de seguridad. Todo lo que no esté en la lista corre el riesgo de pasarse por alto.

Este paso lleva una o dos horas. Ahorra cuatro horas de apagar incendios después de la migración.

Paso 2: Reduce el TTL del DNS

Tres días antes del cambio, baja el TTL del registro A y de los CNAME relevantes desde el valor por defecto (a menudo 24 o 48 horas) hasta 300 segundos. Esto significa que, una vez hecho el cambio, el DNS se propaga en cinco minutos en lugar de esperar a que las cachés caduquen a lo largo de uno o dos días.

Este único paso es lo que separa una migración limpia de un limbo de DNS de 36 horas en el que unos visitantes ven el sitio antiguo y otros el nuevo.

Paso 3: Prepara el nuevo hosting como entorno de staging

Pon en marcha el nuevo hosting con el sitio WordPress cargado en una URL temporal o mediante una anulación del archivo hosts. Aquí es donde se hace el trabajo real: importar la base de datos, copiar los archivos, instalar el certificado SSL, configurar la caché y validar que todo funciona de verdad.

Este paso suele llevar una jornada completa. El enfoque del archivo hosts permite al equipo probar todo el sitio desde dentro de la oficina sin que el DNS público apunte todavía al nuevo hosting.

Paso 4: Prueba cada formulario, pago e integración

Aquí es donde fallan la mayoría de las migraciones. El formulario de contacto se ve igual, pero las credenciales SMTP deben reconfigurarse para el nuevo hosting. La pasarela de pago está activa, pero las URL de los webhooks siguen apuntando al hosting antiguo. El plugin de correo funciona, pero la reputación de la IP del nuevo hosting es desconocida.

Recorre cada formulario del sitio. Envíalos. Confirma que llega el correo. Realiza una transacción real (y reembolsada). Ejecuta manualmente las tareas cron programadas y verifica el resultado. Prueba en tres navegadores, incluido el móvil.

Paso 5: Sincronización final de la base de datos

Justo antes del cambio de DNS, haz una sincronización final de la base de datos para recoger cualquier edición de contenido, comentario o transacción que se haya producido durante las pruebas. Después, si es posible, pon el sitio de origen en estado de solo lectura (un plugin de mantenimiento o una breve congelación de contenido) para que no se generen datos nuevos en el hosting antiguo durante el cambio.

Paso 6: Cambia el DNS

Con el TTL ya reducido, apunta el registro A (o CNAME, o ANAME según el hosting) al nuevo servidor. En cinco minutos, la mayoría de los visitantes llegan al nuevo hosting. En una hora, casi todos.

Mantén ambos servidores en marcha durante las primeras 24 horas. Si un visitante usa un resolver de DNS lento que aún no ha propagado, llega al hosting antiguo y sigue viendo un sitio que funciona. La ventana de dos servidores cuesta un día de hosting en la cuenta antigua. La protección lo vale.

Paso 7: Monitoriza durante las primeras 48 horas

Vigila la monitorización de disponibilidad, vigila los registros de errores del hosting, vigila la bandeja del formulario de contacto. La mayoría de los problemas que surgen tras la migración aparecen en las primeras 12 horas: una redirección que falta, un certificado SSL mal configurado para un subdominio, una integración de terceros que necesitaba actualizar una lista blanca de IP.

Paso 8: Da de baja y documenta

Tras 48 horas de tráfico limpio en el nuevo hosting, haz una copia de seguridad final del entorno antiguo con fines de archivo y luego da de baja la cuenta antigua. Documenta la nueva arquitectura: dónde está la base de datos, qué nivel de plan, qué credenciales de acceso viven dónde, qué monitorización está conectada y cuál sería el procedimiento de reversión si ocurriera algo catastrófico.

Esta documentación es el entregable que importará dentro de seis meses. Sin ella, la próxima persona que deba tomar una decisión de hosting no tendrá ningún contexto.

Dónde se tuercen las migraciones por cuenta propia

Los dos fallos más comunes en las migraciones por cuenta propia son saltarse el Paso 2 (reducir el TTL) y saltarse el Paso 4 (las pruebas completas de integración). Ambos parecen aburridos. Ambos evitan horas de frustración al otro lado. Una migración que sigue los ocho pasos completos es, según nuestra experiencia, invisible para los visitantes y sin sobresaltos para el dueño del negocio.

Si te enfrentas a un cambio de hosting y quieres un socio que lo haya hecho decenas de veces, el equipo de hosting de Defyn gestiona las migraciones de WordPress como un proyecto estructurado de alcance fijo. El sitio se mueve sin problemas, tú sigues trabajando y después nadie menciona la migración porque nada salió mal. Si necesitas ayuda para dejar tu hosting actual, habla con Defyn.