La idea clave: una migración de WordPress causa tiempo de inactividad cuando los pasos ocurren en el orden equivocado — el DNS se cambia antes de verificar el nuevo sitio, o el contenido cambia en el sitio antiguo después de que la base de datos ya se exportó. Hacer el trabajo en paralelo en el nuevo entorno, probarlo por completo antes del cambio, y bajar el TTL del DNS con antelación es lo que hace que el cambio sea invisible para los visitantes.
Por qué las migraciones suelen causar tiempo de inactividad
La forma predeterminada y sin planificar de mover un sitio WordPress — exportar la base de datos, copiar los archivos, apuntar el DNS al nuevo servidor, y luego empezar a arreglar lo que se rompió — crea una ventana en la que el sitio está completamente caído o sirviendo una versión medio migrada y rota. Cada paso de esa secuencia ocurre directamente en el sitio en producción, así que cualquier error es visible de inmediato para los visitantes.
La migración sin tiempo de inactividad resuelve esto invirtiendo el orden: construir y verificar completamente el nuevo entorno mientras el antiguo sigue atendiendo tráfico sin tocarlo, y cambiar solo una vez que todo esté confirmado que funciona. El sitio en producción nunca está en un estado intermedio roto porque el trabajo de migración nunca ocurre directamente sobre él.
Checklist previa a la migración
- Haz una copia de seguridad completa de los archivos y la base de datos del sitio actual, almacenada en algún lugar fuera de la cuenta de hosting actual.
- Baja el TTL del DNS en el registro A del dominio a 300 segundos (5 minutos) al menos 24-48 horas antes del cambio planeado — ver el detalle técnico más abajo sobre por qué importa este tiempo de antelación.
- Haz inventario de los plugins y temas activos, anotando versiones, ya que el nuevo entorno necesita coincidir con la versión de PHP y los requisitos de extensiones.
- Confirma que el nuevo hosting está completamente configurado — WordPress instalado, listo para recibir los archivos y la base de datos migrados, pero todavía no vinculado públicamente al dominio.
Paso 1: Baja el TTL del DNS antes de empezar
El TTL (tiempo de vida) del DNS controla cuánto tiempo los resolvers de todo internet cachean la dirección IP actual de un dominio antes de volver a comprobarla. Un TTL predeterminado típico de varias horas (a veces 24 o más) significa que incluso después de actualizar el DNS para apuntar al nuevo servidor, una parte significativa de los visitantes sigue llegando al antiguo hasta que expira la copia cacheada de su resolver. La propia explicación de Cloudflare sobre el TTL del DNS cubre este mecanismo con más profundidad técnica.
Bajar el TTL a 300 segundos uno o dos días antes del cambio real significa que, para cuando se cambia el DNS, el retraso de propagación es de minutos en lugar de horas — el paso de preparación individual más impactante para un cambio genuinamente con poco tiempo de inactividad.
Paso 2: Construye el nuevo entorno en paralelo
Configura WordPress en el nuevo hosting de forma completamente independiente del sitio en producción — misma versión de PHP, mismas extensiones requeridas, listo para recibir contenido pero todavía no vinculado de forma públicamente visible al dominio en producción. Este es el paso que hace posible el "sin tiempo de inactividad": todo el trabajo de configuración ocurre en una infraestructura que nadie visita todavía.
Paso 3: Migra archivos y base de datos
Herramientas como Duplicator o el plugin All-in-One WP Migration empaquetan los archivos y la base de datos del sitio en un único archivo transferible, gestionando los detalles técnicos de una exportación e importación de base de datos limpia. Para agencias que gestionan migraciones frecuentes, una herramienta de migración de hosting a hosting integrada en plataformas de hosting gestionado (Kinsta, WP Engine y otras la ofrecen) suele gestionar el proceso con menos trabajo manual.
Una trampa técnica específica que evitar aquí: no ejecutes un simple buscar y reemplazar en la base de datos para actualizar el dominio de la URL antigua a la nueva. WordPress almacena datos PHP serializados — usados por muchos widgets, algunos ajustes de plugins y opciones de tema — como cadenas con un prefijo de longitud de caracteres incorporado. Un reemplazo de texto ingenuo cambia la longitud de la cadena sin actualizar ese prefijo, corrompiendo silenciosamente los datos. El comando search-replace de WP-CLI está construido específicamente para manejar correctamente los datos serializados y es la herramienta estándar para este paso exacto.
Paso 4: Prueba el nuevo sitio usando tu propio archivo hosts
Antes de tocar el DNS público, edita el archivo hosts local de tu propio ordenador para que el dominio apunte a la dirección IP del nuevo servidor — esto solo afecta a tu máquina, permitiéndote navegar por el nuevo sitio usando el nombre de dominio real (probando inicio de sesión, pago, formularios de contacto y cualquier otra cosa que dependa de que el dominio coincida) sin afectar a ningún otro visitante. Este es el paso que detecta problemas de migración antes de que se vuelvan públicos.
Paso 5: Reconcilia los cambios de contenido hechos durante la ventana de migración
Si el sitio en producción siguió recibiendo comentarios, pedidos o envíos de formularios después de exportar la base de datos, ese contenido existe en el sitio antiguo pero no en el nuevo. Para la mayoría de los sitios corporativos, esta ventana es lo bastante pequeña como para ignorarla; para cualquier cosa transaccional (e-commerce, contenido de membresía), exporta solo los nuevos registros creados durante la ventana de migración e impórtalos a la nueva base de datos antes del cambio.
Paso 6: Cambia el DNS
Con el nuevo sitio completamente probado mediante el método del archivo hosts y cualquier brecha de contenido reconciliada, actualiza el registro A del DNS del dominio para que apunte al nuevo servidor. Como el TTL se bajó con antelación, la mayoría de los visitantes resuelven al nuevo servidor en minutos en lugar de horas.
Paso 7: Verifica y monitoriza después del cambio
- Confirma que el SSL está activo en el nuevo servidor para el dominio, ya que un certificado ausente o mal configurado rompe inmediatamente el acceso HTTPS.
- Revisa si hay avisos de contenido mixto causados por URLs http:// codificadas que hayan quedado en la base de datos o los archivos del tema.
- Verifica que las redirecciones siguen funcionando si la migración incluyó un cambio en la estructura de URL, y revisa Google Search Console en busca de un aumento de errores de rastreo en los días siguientes.
- Vigila los registros del servidor en busca de errores 404 en URLs que antes funcionaban, lo que normalmente indica un archivo omitido o un buscar-reemplazar incompleto.
Cronología de migración de un vistazo
| Fase | Momento | Acciones clave |
|---|---|---|
| Antes de la migración | 24-48 horas antes | Bajar el TTL del DNS, hacer copia de seguridad, confirmar que el nuevo hosting está listo |
| Construcción en paralelo | Antes del cambio | Configurar el nuevo entorno, migrar archivos/base de datos con una herramienta adecuada |
| Verificación | Antes del cambio | Probar mediante el archivo hosts local usando el dominio real |
| Cambio | Día de la migración | Reconciliar cualquier brecha de contenido, cambiar el DNS |
| Después de la migración | Primeras 48-72 horas | Verificar el SSL, revisar contenido mixto, monitorizar registros y Search Console |
Errores comunes de migración
- Saltarse el paso de bajar el TTL del DNS, dejando la propagación del cambio a merced de lo que estuviera configurado el TTL antiguo.
- Ejecutar un simple buscar y reemplazar en la base de datos en lugar de una herramienta consciente de la serialización como el search-replace de WP-CLI, corrompiendo silenciosamente los ajustes de widgets y tema.
- Cambiar el DNS antes de probar el nuevo sitio, descubriendo un plugin roto o un archivo faltante solo después de que los visitantes ya lo están alcanzando.
- Olvidar el contenido creado durante la ventana de migración, perdiendo comentarios, pedidos o envíos que llegaron al sitio antiguo después de la exportación.
- No confirmar el SSL en el nuevo servidor antes del cambio, causando un aviso de certificado visible en el momento en que cambia el DNS.
Cuándo buscar ayuda para mostrar progreso a un cliente
Las agencias que migran el sitio de un cliente a menudo necesitan mostrar el nuevo entorno paralelo para su aprobación antes del cambio real — sin ceder credenciales de hosting ni una confusa solución de archivo hosts para que la siga un cliente no técnico. Una herramienta como Erdo Client Preview o Erdo Draft Links le da al cliente un enlace sencillo para revisar el nuevo sitio directamente, lo cual encaja de forma natural con los hábitos de prueba cubiertos en nuestra guía de staging de WordPress y nuestra guía más amplia de velocidad y hosting de WordPress para evaluar el propio hosting de destino.
Para terminar
En resumen, una migración de WordPress sin tiempo de inactividad se reduce a la secuenciación: baja el TTL del DNS con buena antelación, construye y prueba por completo el nuevo entorno en paralelo usando tu propio archivo hosts en lugar del DNS público, usa una herramienta consciente de la serialización para cualquier actualización de URL, y cambia el DNS solo una vez que todo esté verificado que funciona. Sigue ese orden y el sitio en producción nunca queda en un estado intermedio roto — los visitantes simplemente resuelven al nuevo servidor una vez que ya se ha confirmado que está listo.