¿Cómo migrar un sitio WordPress a un nuevo servidor hosting sin caídas (Zero Downtime)?

Migrar WordPress sin caídas no es apretar un botón mágico y esperar que los duendes del DNS hagan su trabajo con puntualidad suiza. Es más bien trasladar una biblioteca durante horario de apertura: los lectores siguen entrando, los libros cambian de edificio y nadie debería notar que el suelo se movió bajo sus pies.

La promesa de una migración Zero Downtime —cero interrupciones visibles para el usuario— exige método, paciencia y una saludable desconfianza hacia todo lo que diga “automático” en letras demasiado brillantes. Porque sí: un plugin puede ayudar. Pero un plan salva.

Qué significa realmente migrar WordPress sin caídas ⚙️

Una migración WordPress sin caídas significa que los visitantes pueden seguir accediendo al sitio mientras tú mueves archivos, base de datos, configuración DNS, certificados SSL y correo —si aplica— de un servidor a otro. No significa que el universo conspire para que todos los resolvers DNS del planeta obedezcan al mismo segundo. Esa fantasía suele vivir en la misma estantería que “solo será un cambio rápido en producción”.

La idea práctica es simple: preparar el nuevo hosting en paralelo, copiar el sitio, probarlo con precisión quirúrgica, sincronizar los cambios recientes y dirigir el tráfico al nuevo servidor solo cuando todo esté listo. Antiguo y nuevo conviven durante un rato, como dos puentes sobre el mismo río: uno sostiene el tráfico actual; el otro espera, limpio, firme, casi impaciente.

Dato útil: WordPress ronda históricamente el 43% de todos los sitios web medidos por fuentes como W3Techs. Esa popularidad tiene una consecuencia directa: existen muchas formas de migrarlo, desde plugins visuales hasta procesos con WP-CLI, rsync, snapshots y replicación de base de datos. La mejor opción depende del tipo de sitio, no de la herramienta más ruidosa.

¿Existe el cero absoluto?

En sitios estáticos o blogs con pocos cambios, sí, una migración puede ser prácticamente imperceptible. En tiendas WooCommerce, comunidades, academias online, reservas o webs con formularios críticos, el asunto se vuelve más delicado: mientras copias la base de datos, alguien puede estar comprando, registrándose o enviando un formulario. La quietud técnica y la vida comercial rara vez se dan la mano.

Por eso conviene distinguir entre:

• Zero Downtime visible: el usuario no ve errores, pantallas en blanco ni sitio en mantenimiento.
• Zero Data Loss: no se pierde ningún pedido, usuario, comentario, formulario o cambio editorial.
• Zero Risk: no existe. Y si alguien lo vende, revise la letra pequeña con lupa y café.

Antes de empezar: preparación estratégica 🧰

Una migración impecable empieza antes del primer comando. Empieza con preguntas incómodas, esas que parecen exageradas hasta que algo se rompe a las 23:47 y el panel del hosting decide convertirse en estatua.

Inventario técnico

• Versión de WordPress.
• Versión de PHP actual y recomendada.
• Versión de MySQL o MariaDB.
• Tamaño de archivos y base de datos.
• Plugins activos, must-use plugins y tema.
• Cron jobs, integraciones externas y webhooks.

Accesos necesarios

• Panel del hosting antiguo.
• Panel del nuevo servidor.
• SSH o SFTP.
• phpMyAdmin o acceso MySQL.
• Registrador del dominio o proveedor DNS.
• Panel de CDN, WAF o Cloudflare si existe.

Plan de reversión

• Backup completo verificado.
• DNS antiguo documentado.
• IP anterior anotada.
• Tiempo estimado de rollback.
• Responsable técnico disponible.

Hace años, durante una migración aparentemente trivial, descubrí que el sitio tenía un pequeño script olvidado que enviaba leads a un CRM por FTP. FTP, sí, ese fósil con sombrero. Nadie lo recordaba, pero era el hilo que alimentaba al equipo comercial. La web cargaba perfecta; el negocio, en silencio, dejaba de respirar. Desde entonces, cuando alguien dice “es un WordPress normal”, sonrío con una prudencia casi religiosa.

Auditoría del sitio actual: conocer la casa antes de mudarla 🔍

Antes de migrar un sitio WordPress a un nuevo servidor hosting, hay que mirar debajo de la alfombra. No por morbo técnico, sino porque allí suelen vivir los problemas: plugins abandonados, cachés fosilizadas, rutas absolutas, permisos incorrectos, archivos enormes en uploads, tablas transitorias infladas como globos de feria.

Comprobaciones recomendadas

• Salud del sitio: en WordPress, revisa Herramientas > Salud del sitio.
• Errores PHP: consulta logs del hosting antiguo.
• Tamaño de la base de datos: identifica tablas gigantes, especialmente de logs, estadísticas o caché.
• URLs absolutas: revisa si hay rutas duras al dominio o al directorio del servidor.
• Correo saliente: verifica SMTP, SPF, DKIM y DMARC si el hosting también cambia correo.
• Licencias: algunos plugins premium vinculan licencia al dominio o IP.
• Tareas programadas: WP-Cron, cron real del servidor, importadores, sincronizaciones externas.

Si tienes SSH y WP-CLI instalado, puedes obtener información rápida:

wp core version
wp plugin list
wp theme list
wp option get siteurl
wp option get home
wp db size --tables

Consejo profesional: no migres basura por romanticismo. Antes del traslado, limpia cachés, elimina backups antiguos dentro de wp-content, borra plugins inactivos que no necesites y optimiza tablas. Mover menos peso es más rápido, más seguro y menos propenso a fallos.

Configurar el nuevo servidor hosting antes de copiar nada 🏗️

El nuevo servidor no debe ser una habitación vacía donde arrojar cajas. Debe estar preparado: versión correcta de PHP, extensiones necesarias, base de datos creada, límites razonables, reglas del servidor listas y seguridad básica activada.

Requisitos recomendados para WordPress moderno

Crear base de datos y usuario

En el nuevo hosting crea una base de datos limpia, un usuario con contraseña fuerte y permisos suficientes. Luego actualiza el archivo wp-config.php cuando copies el sitio:

define('DB_NAME', 'nueva_base_de_datos');
define('DB_USER', 'nuevo_usuario');
define('DB_PASSWORD', 'contraseña_larga_y_segura');
define('DB_HOST', 'localhost');

Algunos proveedores usan hosts de base de datos distintos, como mysql.tudominio.com o una IP interna. No lo adivines. Verifícalo. La intuición es útil para elegir pan en una cafetería; para configurar bases de datos, no tanto.

DNS y TTL: la coreografía invisible 🌐

El DNS es el sistema que traduce tu dominio —por ejemplo, tudominio.com— a la IP del servidor. Durante una migración sin caídas, no quieres que esa traducción cambie tarde, mal y en distintas direcciones, como una bandada de pájaros confundida por el viento.

Baja el TTL antes de migrar

El TTL —Time To Live— indica cuánto tiempo pueden cachear los resolvers DNS un registro. Si tu TTL actual es de 24 horas, algunos usuarios podrían seguir llegando al servidor antiguo durante casi un día después del cambio. Por eso conviene reducirlo con antelación.

• 24 a 48 horas antes: baja el TTL de los registros A, AAAA y CNAME relevantes a 300 segundos.
• No cambies nameservers si no es necesario: cambiar servidores DNS completos suele ser más lento y menos controlable que cambiar un registro A.
• Documenta todo: captura registros actuales antes de modificar nada.

Importante: “propagación DNS” no es un proceso mágico que se empuja desde un botón. Es una suma de cachés, resolvers, proveedores y TTLs previos. Lo más elegante no es pelear con el DNS, sino anticiparse a su pereza.

Registros que debes revisar

Copiar archivos de WordPress sin interrumpir el sitio 📦

Los archivos de WordPress incluyen el núcleo, temas, plugins, medios subidos, cachés, mu-plugins y configuraciones. En una migración profesional conviene copiar todo, pero no todo pesa igual ni todo merece el mismo cariño.

Opción 1: rsync por SSH

Si tienes acceso SSH en ambos servidores, rsync es una herramienta magnífica: copia diferencias, conserva permisos y permite sincronizaciones posteriores rápidas. Es como un mensajero que recuerda qué cajas ya llevó y se niega a repetir trabajo inútil. Una rareza admirable.

rsync -avz --progress usuario@servidor-antiguo:/ruta/al/sitio/ /ruta/nueva/del/sitio/

Para excluir cachés o backups pesados:

rsync -avz --progress \
--exclude='wp-content/cache/' \
--exclude='wp-content/backup*' \
--exclude='*.zip' \
usuario@servidor-antiguo:/ruta/al/sitio/ /ruta/nueva/del/sitio/

Opción 2: SFTP o administrador de archivos

Es viable en sitios pequeños, aunque más lento y propenso a cortes. Si el sitio pesa varios gigabytes, descargar a tu equipo y subir al nuevo servidor convierte la migración en una procesión con velas: solemne, lenta y con muchas posibilidades de apagarse.

Opción 3: plugins de migración

Herramientas como Duplicator, UpdraftPlus, All-in-One WP Migration, WP Migrate o BlogVault pueden ser muy útiles. Para sitios corporativos sencillos funcionan bien. Para WooCommerce activo, bases enormes o servidores con límites estrictos, conviene combinarlas con control manual.

No dependas de un único método. Si usas plugin, guarda también backup independiente de archivos y base de datos. La redundancia parece exagerada hasta el momento exacto en que deja de parecerlo.

Migrar la base de datos: el corazón de WordPress 🫀

La base de datos contiene entradas, páginas, usuarios, pedidos, configuraciones, menús, widgets, opciones del tema, sesiones y un largo etcétera. Si los archivos son el cuerpo, la base de datos es la memoria. Y una memoria mal copiada produce síntomas raros: imágenes que existen pero no aparecen, widgets que olvidan su lugar, plugins que despiertan creyendo estar en otra vida.

Exportar con WP-CLI

wp db export backup-pre-migracion.sql

Exportar con mysqldump

mysqldump -u usuario -p nombre_base_datos > backup-pre-migracion.sql

Importar en el nuevo servidor

mysql -u nuevo_usuario -p nueva_base_de_datos < backup-pre-migracion.sql

Si el dominio no cambia, normalmente no necesitas hacer reemplazos de URL. Si migras también de dominio, subdominio o entorno temporal, usa una herramienta que respete datos serializados. En WordPress, un simple “buscar y reemplazar” en SQL puede romper configuraciones serializadas; elegante como arreglar un reloj con martillo.

Search-replace seguro con WP-CLI

wp search-replace 'https://dominio-temporal.com' 'https://tudominio.com' --skip-columns=guid --dry-run

Si el resultado es razonable, ejecuta sin --dry-run:

wp search-replace 'https://dominio-temporal.com' 'https://tudominio.com' --skip-columns=guid

Sobre el campo GUID: en WordPress no debe tratarse como una URL pública normal. En migraciones de dominio suele evitarse modificarlo salvo casos muy específicos, porque su función histórica está relacionada con identificadores de contenido en feeds.

Sincronización final: el minuto donde se gana o se pierde la elegancia ⏱️

Aquí aparece el verdadero desafío de una migración WordPress Zero Downtime: mientras preparas el nuevo servidor, el sitio antiguo puede seguir cambiando. Nuevos comentarios, pedidos, usuarios, formularios, reservas. El tiempo no se congela porque tú estés migrando; sería cómodo, desde luego, pero el comercio electrónico tiene la mala costumbre de seguir vendiendo.

Estrategias según el tipo de sitio

Sincronización delta de archivos

Después de la primera copia, ejecuta un segundo rsync justo antes del cambio DNS. Será más rápido porque solo moverá diferencias:

rsync -avz --delete \
--exclude='wp-content/cache/' \
usuario@servidor-antiguo:/ruta/al/sitio/ /ruta/nueva/del/sitio/

Usa --delete con cuidado: elimina en destino lo que ya no existe en origen. Es poderoso, y como todas las cosas poderosas, no perdona distracciones.

Sincronización final de base de datos

Para sitios de bajo movimiento:

1. Pausa edición o cambios administrativos.
2. Desactiva temporalmente formularios críticos si es necesario.
3. Exporta la base actual del servidor antiguo.
4. Importa en el nuevo servidor.
5. Verifica el sitio en el nuevo entorno.
6. Cambia DNS.

Para sitios transaccionales, considera una de estas opciones:

• Modo solo lectura: los usuarios navegan, pero no compran ni se registran durante unos minutos.
• Proxy inverso temporal: enruta tráfico al nuevo servidor mientras controlas backend y caché.
• Replicación MySQL: más compleja, útil en migraciones de alto valor.
• Servicios especializados: plataformas de migración con sincronización incremental.

Atención con WooCommerce: no copies una base antigua encima de una nueva si ya entraron pedidos en el nuevo servidor. Ese gesto, tan rápido como fatal, puede borrar ventas reales. La base de datos no sabe de arrepentimientos.

Probar el nuevo hosting con el archivo hosts 🧪

Antes de cambiar DNS para todo el mundo, puedes hacer que solo tu equipo vea el dominio apuntando al nuevo servidor. Para eso se modifica el archivo hosts local. Es una especie de mentira privada y útil: tu ordenador cree que el dominio ya vive en la nueva IP, mientras el resto de internet sigue viendo el servidor antiguo.

Ejemplo de entrada hosts

203.0.113.10 tudominio.com
203.0.113.10 www.tudominio.com

Rutas comunes:

• Windows: C:\Windows\System32\drivers\etc\hosts
• macOS/Linux: /etc/hosts

Qué probar antes del cambio

• Home, páginas principales y entradas.
• Panel /wp-admin.
• Login y recuperación de contraseña.
• Formularios de contacto.
• Proceso de compra si hay WooCommerce.
• Pasarelas de pago en modo prueba cuando sea posible.
• Imágenes, CSS y JavaScript sin errores 404.
• Permalinks y reglas de reescritura.
• Emails transaccionales.
• Conexiones API externas.

Abre la consola del navegador. Mira la pestaña Network. Revisa errores mixtos HTTP/HTTPS. Observa tiempos de carga. No te fíes solo de “se ve bien”. Un sitio puede verse como un palacio y tener el sótano inundado.

SSL y HTTPS: que el candado no llegue tarde 🔐

Uno de los fallos más comunes al migrar WordPress a un nuevo hosting es cambiar DNS antes de tener el certificado SSL listo. Resultado: visitantes viendo advertencias de seguridad, navegadores dramáticos, clientes inquietos y alguien diciendo “pero en mi ordenador funciona”. Magnífico, justo lo que necesitaba la marca.

Buenas prácticas SSL

• Instala el certificado en el nuevo servidor antes del cambio DNS si el proveedor lo permite.
• Si usas Cloudflare, revisa el modo SSL: Full o Full Strict es preferible a Flexible.
• Verifica redirecciones de HTTP a HTTPS.
• Comprueba contenido mixto: imágenes o scripts cargando por HTTP.
• Confirma que siteurl y home usan https://.

wp option get siteurl
wp option get home
wp option update siteurl 'https://tudominio.com'
wp option update home 'https://tudominio.com'

También puedes revisar cabeceras de seguridad como Strict-Transport-Security, pero con cautela. HSTS mal configurado puede convertir un problema temporal en una jaula cromada.

El cambio DNS: abrir la puerta del nuevo servidor 🚪

Si todo está probado, sincronizado y documentado, el cambio DNS debería ser casi anticlimático. Y eso es bueno. En infraestructura, la épica suele ser señal de mala planificación.

Procedimiento recomendado

1. Confirma backup final de archivos y base de datos.
2. Ejecuta sincronización delta de archivos.
3. Ejecuta exportación/importación final de base de datos.
4. Limpia cachés en el nuevo WordPress.
5. Prueba con archivo hosts una última vez.
6. Cambia el registro A del dominio raíz a la nueva IP.
7. Cambia el registro A o CNAME de www según corresponda.
8. Verifica que no queda un registro AAAA apuntando al servidor antiguo.
9. Purga caché CDN si existe.
10. Monitoriza logs, uptime y conversiones.

Comandos útiles para comprobar DNS

dig tudominio.com A
dig www.tudominio.com A
dig tudominio.com AAAA
nslookup tudominio.com

También puedes usar herramientas externas de verificación DNS global para observar cómo distintos resolvers ven tu dominio. No te obsesiones con que todos cambien al mismo minuto. Lo importante es que ambos servidores sigan sirviendo correctamente durante el periodo de transición.

Clave Zero Downtime: mantén el servidor antiguo activo al menos 24-48 horas después del cambio, especialmente si el TTL anterior era alto. Apagarlo inmediatamente es como retirar el puente viejo mientras todavía hay coches cruzándolo.

WooCommerce, membresías y sitios vivos: cuando la web no deja de moverse 🛒

Una tienda online no es una página: es una caja registradora, un almacén, una conversación con el cliente y a veces una criatura temperamental que se ofende por un plugin de pagos mal configurado. Migrar WooCommerce sin caídas requiere una estrategia distinta a la de un blog.

Elementos críticos en WooCommerce

• Pedidos nuevos y cambios de estado.
• Inventario y stock.
• Cupones usados.
• Usuarios registrados durante la migración.
• Sesiones y carritos activos.
• Webhooks hacia ERP, CRM, facturación o logística.
• Pasarelas de pago y callbacks IPN.

Estrategia segura para tiendas

1. Elige una ventana de bajo tráfico según analítica real, no según corazonada.
2. Reduce TTL con suficiente antelación.
3. Copia archivos y base inicial.
4. Prueba checkout en entorno nuevo usando archivo hosts.
5. Activa un breve modo de pausa para compras o coloca aviso de mantenimiento solo en checkout, no en toda la web.
6. Sincroniza base final.
7. Cambia DNS.
8. Verifica pedidos, correos, pasarela y webhooks.
9. Mantén vigilancia intensa durante las primeras horas.

Si el coste de perder un pedido es alto, invierte en una migración asistida, replicación o arquitectura temporal más avanzada. Lo barato en infraestructura a veces cobra intereses con una sonrisa.

Seguridad durante la migración: no mudes también los ladrones 🛡️

Una migración es una oportunidad excelente para mejorar seguridad. También es un momento vulnerable: backups expuestos, credenciales compartidas, permisos relajados “por un minuto”, instaladores olvidados. La historia de internet está pavimentada con “luego lo borro”.

Medidas esenciales

• Usa contraseñas nuevas para base de datos, SFTP, SSH y usuarios administrativos si hubo accesos compartidos.
• Activa autenticación en dos factores para administradores de WordPress y panel del hosting.
• Elimina archivos de instalación de plugins de migración: paquetes ZIP, instaladores PHP, dumps SQL.
• Revisa permisos: archivos normalmente 644, directorios 755, salvo configuraciones específicas.
• Protege wp-config.php y evita permisos demasiado abiertos.
• Desactiva edición de archivos desde el panel:

define('DISALLOW_FILE_EDIT', true);

• Regenera salts de WordPress para invalidar sesiones antiguas si sospechas exposición.
• Instala WAF o reglas de seguridad si el servidor lo permite.
• Escanea malware antes y después de migrar.

Cabeceras recomendadas

Según el tipo de sitio, puedes aplicar cabeceras como:

• X-Content-Type-Options: nosniff
• X-Frame-Options: SAMEORIGIN
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy ajustada a necesidades reales

No copies reglas de seguridad como quien colecciona estampillas. Cada cabecera tiene efectos. Algunas pueden romper iframes, mapas, pasarelas o integraciones.

Optimización después de migrar: que el nuevo servidor no sea solo nuevo ⚡

Migrar a un hosting mejor y dejar WordPress sin optimizar es como comprar un coche deportivo para circular siempre con el freno de mano puesto. El nuevo servidor puede ofrecer más CPU, mejor I/O, caché avanzada o CDN, pero WordPress necesita ajustes para aprovecharlo.

Acciones post-migración

• Vacía cachés: plugin de caché, caché del servidor, OPcache, CDN.
• Regenera permalinks: guarda ajustes en Ajustes > Enlaces permanentes.
• Activa caché de página si el sitio no es altamente dinámico.
• Configura object cache con Redis o Memcached si el hosting lo soporta.
• Optimiza imágenes y sirve WebP/AVIF cuando sea viable.
• Revisa Core Web Vitals: LCP, INP y CLS.
• Comprueba TTFB desde distintas ubicaciones.
• Actualiza PHP solo tras validar compatibilidad.
• Revisa consultas lentas en WooCommerce o sitios con mucho contenido.

WP-CLI para mantenimiento

wp cache flush
wp rewrite flush
wp transient delete --all
wp cron event list

Después mide. No con una sola herramienta ni desde una sola ciudad. Usa PageSpeed Insights, WebPageTest, GTmetrix, logs del servidor, datos de Search Console y analítica real. La velocidad percibida es una experiencia; la velocidad medida, un conjunto de pistas.

Errores frecuentes al migrar WordPress a otro hosting 🧯

La mayoría de migraciones fallidas no fracasan por una gran catástrofe. Fracasan por pequeñas omisiones acumuladas, como gotas que terminan abriendo una grieta en la piedra.

Checklist final para una migración WordPress Zero Downtime ✅

Antes

• Auditoría técnica completada.
• Backups verificados.
• TTL reducido.
• Nuevo hosting configurado.
• PHP, MySQL y extensiones validadas.
• Plan de reversión preparado.

Durante

• Archivos copiados.
• Base de datos importada.
• wp-config.php actualizado.
• Permalinks funcionando.
• Pruebas con archivo hosts realizadas.
• SSL instalado y validado.

En el cambio

• Sincronización delta ejecutada.
• Base final sincronizada.
• Cachés purgadas.
• DNS actualizado.
• CDN revisado.
• Servidor antiguo mantenido activo.

Después

• Logs monitorizados.
• Formularios probados.
• Pedidos o registros verificados.
• Search Console revisada.
• Rendimiento medido.
• Archivos temporales eliminados.

Un traslado limpio es una obra de precisión 🎯

Migrar WordPress a un nuevo servidor hosting sin caídas no consiste en correr. Consiste en no improvisar. La prisa empuja; el método guía. Y entre ambas fuerzas se decide si el usuario navega tranquilamente o contempla una página de error como quien mira una persiana cerrada en pleno horario comercial.

La migración ideal es silenciosa. Nadie la aplaude porque nadie la nota. El sitio carga, los formularios llegan, los pedidos entran, el candado HTTPS permanece sereno y el DNS, por una vez, parece comportarse como un funcionario inspirado. Detrás de esa calma hay backups, pruebas, sincronización, vigilancia y una pizca de humildad técnica.

Porque en la web moderna, cambiar de servidor no es abandonar una casa vieja por una nueva. Es cruzar un puente mientras el puente sigue lleno de gente. Y hacerlo bien —sin ruido, sin pérdida, sin teatro— es una de esas pequeñas artes invisibles que sostienen internet cada día. 🌍