Migración WordPress sin tiempo de caída: qué esperar

Guía práctica sobre migración WordPress sin tiempo de caída: fases, herramientas, errores frecuentes y qué esperar en cada paso del proceso real.

Qué significa realmente una migración WordPress sin tiempo de caída

Cuando hablamos de una migración WordPress sin tiempo de caída, nos referimos a un proceso en el que un sitio web se traslada de un servidor, dominio o configuración a otra sin que los visitantes experimenten errores, páginas en blanco o interrupciones visibles. La diferencia entre una migración convencional y una sin downtime no está en las herramientas —que son similares—, sino en la planificación y la secuencia de pasos técnicos que se ejecutan.

Según datos de Wikipedia sobre tiempo de inactividad, incluso minutos de caída pueden traducirse en pérdida de ventas, indexación negativa por parte de buscadores y deterioro de la confianza del usuario. En sitios WooCommerce con tráfico constante, el coste de una hora sin servicio puede superar los cientos o miles de euros dependiendo del volumen de transacciones.

El objetivo de esta guía es explicar, desde la experiencia técnica real, qué implica cada fase, qué puede salir mal y cómo se minimizan los riesgos. No se trata de vender una solución mágica, sino de que quien vaya a afrontar este proceso —ya sea internamente o delegándolo— sepa exactamente qué esperar.

Las fases reales de una migración sin interrupciones

Una migración limpia no es un evento, es un proceso con fases bien definidas. Saltarse alguna es precisamente lo que genera caídas inesperadas. Estas son las etapas que cualquier migración profesional debería cubrir:

1. Auditoría previa del entorno de origen

Antes de mover nada, hay que entender qué se está moviendo. Esto incluye:

• Versiones de PHP, MySQL/MariaDB y WordPress en el servidor actual.
• Lista completa de plugins activos y sus dependencias de servidor (extensiones PHP como Imagick, cURL, ionCube).
• Configuraciones personalizadas en .htaccess, wp-config.php o en el nivel de servidor (reglas de caché, redirecciones, certificados SSL).
• Tamaño real de la base de datos y de archivos: un sitio con 8 GB de medios requiere una estrategia diferente que uno con 200 MB.
• Cron jobs o tareas programadas que podrían fallar durante la transición.

Esta auditoría permite detectar incompatibilidades antes de que se conviertan en problemas. He visto migraciones que fallaron simplemente porque el servidor de destino usaba una versión de PHP incompatible con un plugin crítico que nadie había verificado.

2. Preparación del entorno de destino

El servidor de destino debe ser un espejo funcional del de origen antes de iniciar la transferencia. Esto significa:

• Misma versión de PHP (o superior si se ha validado compatibilidad).
• Mismos módulos y extensiones de servidor activos.
• Certificado SSL configurado y funcionando.
• Límites de memoria, tiempo de ejecución y tamaño de subida ajustados.

Un error frecuente es asumir que «todos los hostings son iguales». La realidad es que diferencias mínimas en la configuración de PHP pueden romper funcionalidades enteras.

3. Copia y transferencia de archivos y base de datos

Esta es la fase que la mayoría considera «la migración», pero en realidad es solo una parte. Para ejecutarla sin caída visible:

• Se realiza una copia completa (archivos + base de datos) al servidor de destino mientras el sitio original sigue funcionando con normalidad.
• El sitio se monta en el destino bajo un dominio temporal o mediante modificación del archivo hosts local para verificar que todo funciona antes de cambiar los DNS.
• Se ejecutan pruebas exhaustivas en el destino: navegación, formularios, carrito (si es WooCommerce), pasarelas de pago en modo sandbox, y rendimiento general.

4. Sincronización delta antes del cambio de DNS

Entre el momento en que se hizo la copia inicial y el momento en que se van a cambiar los DNS, habrán ocurrido cambios en el sitio de origen: nuevos pedidos, nuevos comentarios, actualizaciones de contenido. La sincronización delta —transferir solo los cambios incrementales— es lo que garantiza que no se pierda información durante la ventana de transición.

Esta sincronización puede hacerse manualmente exportando solo las tablas de base de datos que han cambiado, o mediante herramientas que automatizan la comparación. El objetivo es que, en el momento del cambio, la diferencia entre origen y destino sea de minutos, no de horas.

5. Cambio de DNS y monitorización

El cambio de DNS es el punto de no retorno visible. Reducir el TTL (Time to Live) de los registros DNS a 300 segundos (5 minutos) al menos 24-48 horas antes de la migración permite que la propagación sea mucho más rápida. Aun así, la propagación DNS global puede tardar entre 2 y 48 horas según el proveedor y la ubicación geográfica del visitante.

Durante este período, ambos servidores deben estar operativos. El de origen sigue respondiendo a quienes todavía apuntan a él, y el de destino atiende a quienes ya tienen los nuevos DNS. Es una fase donde la monitorización activa es crítica.

Herramientas y enfoques: cuál conviene según el caso

No existe una herramienta única que resuelva todas las migraciones. La elección depende del tamaño del sitio, la complejidad técnica y el nivel de personalización.

Plugins de migración automatizada

Herramientas como Duplicator, All-in-One WP Migration o Migrate Guru cubren bien el escenario de sitios pequeños a medianos (hasta 1-2 GB) sin configuraciones de servidor muy personalizadas. Sus ventajas: interfaz simple, proceso guiado, búsqueda y reemplazo de URLs integrado.

Sus limitaciones: en sitios grandes con bases de datos complejas (multisitio, WooCommerce con miles de productos y pedidos), pueden agotar los tiempos de ejecución del servidor, fallar silenciosamente en la serialización de datos o no capturar configuraciones a nivel de servidor.

Migración manual por línea de comandos

Para sitios complejos o con datos sensibles, la migración mediante WP-CLI, rsync, mysqldump y búsqueda-reemplazo con herramientas como Search Replace DB de Interconnect/IT ofrece control total. Permite:

• Transferencias incrementales (rsync solo mueve archivos que han cambiado).
• Exportaciones parciales de base de datos.
• Búsqueda y reemplazo serializado seguro.
• Control preciso sobre permisos de archivos y propiedad.

El inconveniente es que requiere conocimiento técnico sólido. Un error en el search-replace puede corromper datos serializados de plugins y dejar el sitio inservible.

Servicios de migración del hosting

Muchos proveedores de hosting ofrecen migraciones gratuitas o asistidas. Son útiles como punto de partida, pero rara vez cubren verificaciones de funcionalidad específica (pasarelas de pago, integraciones con CRM, formularios complejos). La transferencia de archivos puede ser impecable, pero si nadie verifica que el checkout funciona en el nuevo servidor, la migración no está completa.

Errores frecuentes que causan caídas durante una migración

Conocer los errores más comunes es la mejor forma de evitarlos. Estos son los que he encontrado con mayor frecuencia en proyectos reales:

No reducir el TTL de DNS con antelación

Si el TTL está configurado en 86400 segundos (24 horas), los DNS pueden tardar un día completo en propagarse. Durante ese tiempo, parte de los visitantes verán el servidor antiguo y parte el nuevo. Si el antiguo ya se ha desconectado o desactualizado, esos visitantes verán errores.

Olvidar la búsqueda y reemplazo de URLs

WordPress almacena URLs absolutas en la base de datos: en contenido de posts, opciones de tema, widgets, y datos serializados de plugins. Si se cambia de dominio (incluso de http a https) sin un search-replace adecuado, aparecerán contenidos mixtos, imágenes rotas y redirecciones infinitas.

No verificar los certificados SSL en destino

Un certificado SSL mal configurado en el nuevo servidor genera advertencias de seguridad en el navegador que espantan a cualquier visitante. Es uno de los detalles que más se pasan por alto en migraciones rápidas.

Ignorar la base de datos durante la ventana de propagación

Si el sitio de origen sigue recibiendo pedidos o registros mientras los DNS se propagan, y esos datos no se sincronizan con el destino, se pierden transacciones. En un WooCommerce activo, esto puede significar pedidos perdidos y clientes frustrados.

No hacer backup verificado antes de empezar

Parece obvio, pero la cantidad de migraciones que se inician sin un backup completo y verificado es alarmante. Verificado significa restaurado en un entorno de prueba para confirmar que funciona, no simplemente descargado y archivado.

Checklist para evaluar si una migración está bien planificada

Independientemente de quién ejecute la migración, esta lista de verificación ayuda a determinar si el proceso está correctamente estructurado para evitar tiempo de inactividad:

1. ¿Se ha documentado el entorno de origen? Versiones, plugins, configuraciones de servidor.
2. ¿El entorno de destino replica las condiciones técnicas necesarias?
3. ¿Se ha reducido el TTL a 300 segundos con 48 horas de antelación?
4. ¿Se ha planificado una sincronización delta antes del cambio de DNS?
5. ¿Se ha verificado el sitio en el destino antes de apuntar el dominio? (vía archivo hosts o dominio temporal)
6. ¿El certificado SSL está activo y correctamente configurado en destino?
7. ¿Se ha ejecutado un search-replace seguro que respete datos serializados?
8. ¿Hay un plan de rollback? Si algo falla, ¿se puede volver al servidor original en minutos?
9. ¿Se mantendrá el servidor de origen activo durante la propagación completa de DNS?
10. ¿Se monitorizará activamente el sitio durante las primeras 48 horas post-migración?

Si alguno de estos puntos no tiene respuesta clara, la migración tiene riesgo de generar caída.

Tiempos realistas: cuánto tarda una migración sin downtime

Los tiempos varían enormemente según la complejidad del sitio. Como referencia basada en proyectos reales:

• Sitio informativo pequeño (hasta 500 MB, sin e-commerce): 2-4 horas de trabajo técnico, más 24-48 horas de propagación DNS.
• WooCommerce mediano (1-5 GB, cientos de productos, integraciones de pago): 4-8 horas de trabajo técnico distribuido en 2-3 días para incluir pruebas, sincronización delta y monitorización.
• Sitio complejo (multisitio, más de 10 GB, integraciones con CRM, ERP o APIs externas): 1-2 semanas de planificación y ejecución, con ventanas de mantenimiento coordinadas.

Cualquier proveedor que prometa migrar un sitio WooCommerce complejo «en 30 minutos sin caída» está simplificando el proceso hasta un punto que debería generar desconfianza.

Preguntas frecuentes sobre migración sin caída

¿Es posible una migración con cero segundos de caída absoluta?

Técnicamente, la propagación DNS introduce una ventana en la que distintos usuarios pueden ver distintos servidores. Con TTL bajo, sincronización delta y ambos servidores activos, la experiencia del usuario es continua. Pero afirmar «cero absoluto» ignora variables fuera de control como cachés de ISP o resolvedores DNS lentos.

¿Puedo hacer una migración sin downtime yo mismo?

Sí, si tienes experiencia con WordPress a nivel de servidor, acceso SSH, y familiaridad con herramientas como WP-CLI y rsync. Si tu experiencia se limita al panel de administración, las probabilidades de cometer errores que generen caída aumentan significativamente.

¿Qué pasa con el SEO durante la migración?

Si se mantienen las mismas URLs, el impacto SEO es mínimo. Si cambian las URLs (nuevo dominio, nueva estructura de permalinks), se necesitan redirecciones 301 exhaustivas. Google puede tardar semanas en procesar el cambio, pero la migración en sí no debería penalizar si se ejecuta correctamente.

¿Necesito poner el sitio en modo mantenimiento?

En una migración bien ejecutada sin tiempo de caída, no. El modo mantenimiento es un recurso que se usa cuando no se puede garantizar la continuidad —es la admisión de que habrá interrupción, solo que controlada y con un mensaje bonito en lugar de un error 500.

Si estás planificando una migración y necesitas un perfil técnico que controle todo el proceso, puedes consultar mis servicios de desarrollo WordPress para evaluar si encaja con lo que necesitas.

// Sobre el autor

fernandodomecq

Desarrollador WordPress freelance especializado en WooCommerce, integraciones e IA. Escribo sobre proyectos web, agencias y buenas prácticas técnicas.

Ver todos los artículos →