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

Cómo migrar un sitio WordPress a un nuevo servidor hosting sin caídas: guía Zero Downtime 🚀

Migrar WordPress sin que el sitio se caiga parece, al principio, una pequeña hazaña de prestidigitación: mover la casa mientras la familia sigue cenando dentro. Y, sin embargo, se puede. No con magia, sino con método, paciencia y un saludable respeto por esa criatura caprichosa llamada DNS.

Una migración WordPress mal hecha tiene algo de tragicomedia: el nuevo hosting promete velocidad de cohete, el sitio queda más blanco que una pared recién pintada, los formularios dejan de enviar correos, el certificado SSL se ofende y Googlebot aparece justo cuando todo está ardiendo. Maravilloso progreso, sí; como comprar una cerradura nueva y quedarse encerrado fuera.

La migración Zero Downtime, o migración sin caídas, busca precisamente lo contrario: que los visitantes sigan entrando, comprando, leyendo, reservando o enviando formularios mientras tú trasladas archivos, base de datos, DNS, SSL, cachés, tareas cron y configuraciones del servidor. No se trata solo de “copiar y pegar WordPress”. Eso lo hace cualquiera un martes con demasiado café. Se trata de preservar continuidad, integridad de datos, posicionamiento SEO y confianza.

En esta guía aprenderás:

Qué significa realmente migrar WordPress sin downtime.
Cómo preparar DNS, TTL, backups, PHP, MySQL/MariaDB y SSL antes de tocar nada.
Cómo copiar archivos y base de datos de forma segura.
Cómo probar el sitio en el nuevo hosting antes de apuntar el dominio.
Qué hacer con WooCommerce, membresías, reservas y sitios con datos en tiempo real.
Cómo cambiar DNS minimizando el impacto.
Qué revisar después de la migración para evitar errores invisibles.

WordPress
Migración web
Hosting
DNS
WP-CLI
SEO técnico
Seguridad

Qué significa “Zero Downtime” en una migración WordPress

Conviene empezar con una verdad incómoda: cero downtime absoluto no siempre significa cero cambios pendientes. Significa que el sitio público no queda inaccesible durante la migración. El usuario no ve una pantalla de error, no se rompe el carrito, no aparece un “Error establishing a database connection” saludando como un fantasma en el pasillo.

Ahora bien, hay matices. Un blog corporativo no se comporta igual que una tienda WooCommerce con pedidos cada cinco minutos. Un sitio estático en WordPress —sí, la paradoja existe— se migra con relativa tranquilidad. Una plataforma con cursos, membresías, reservas, comentarios activos o pagos en tiempo real requiere un enfoque más cuidadoso: sincronización incremental, ventana de congelación mínima, modo solo lectura o incluso replicación de base de datos.

El contraste es brutal: por un lado, los archivos, quietos como muebles antiguos; por otro, la base de datos, viva como un mercado a mediodía. Migrar sin caídas consiste en entender esa diferencia.

Antes de migrar: auditoría técnica del sitio actual 🔍

Una migración profesional empieza antes de copiar un solo archivo. Empieza mirando. Parece poco heroico, pero en servidores, como en medicina, quien no diagnostica acaba improvisando cirugía con una cuchara.

1. Inventario del entorno actual

Registra la configuración del hosting de origen:

Versión de PHP: por ejemplo, PHP 8.1, 8.2 o 8.3.
Servidor web: Apache, Nginx, LiteSpeed u OpenLiteSpeed.
Versión de MySQL o MariaDB.
Límites de PHP: memory_limit, upload_max_filesize, post_max_size, max_execution_time.
Extensiones PHP necesarias: imagick, intl, mbstring, curl, zip, mysqli, openssl.
Configuración de caché: plugin de caché, Redis, Memcached, LiteSpeed Cache, Varnish o CDN.
Tareas cron: WP-Cron, cron real del servidor o procesos externos.
Registros DNS actuales: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC.
Certificado SSL: Let’s Encrypt, Cloudflare, certificado comercial o SSL gestionado por el hosting.

Este inventario evita uno de los errores más frecuentes: migrar el sitio a un servidor “mejor” que, curiosamente, no tiene las extensiones necesarias para que funcione. La modernidad, cuando olvida los detalles, se parece mucho a un coche deportivo sin ruedas.

2. Tamaño real del sitio

No todos los WordPress pesan igual. Hay instalaciones elegantes de 800 MB y monstruos de 80 GB alimentados durante años con imágenes sin comprimir, backups duplicados y plugins abandonados. Antes de migrar, calcula:

Tamaño total de archivos.
Tamaño de wp-content/uploads.
Tamaño de la base de datos.
Tablas especialmente grandes: logs, sesiones, transients, acciones programadas, estadísticas.

Con WP-CLI puedes obtener información útil:

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

Si no tienes WP-CLI, phpMyAdmin, Adminer o el panel del hosting también pueden darte una imagen razonable del terreno.

3. Limpieza previa, pero sin entusiasmo destructivo

Antes de migrar, conviene limpiar cachés, backups antiguos y archivos temporales. Pero cuidado: no es el momento de “ya que estamos, borro esto que no sé qué es”. Esa frase ha causado más desastres que algunos plugins nulled.

Elimina cachés generadas por plugins.
Borra backups antiguos almacenados dentro de wp-content, si ya tienes copias externas.
Revisa carpetas de staging olvidadas.
Optimiza tablas si sabes lo que haces.
No elimines tablas de plugins antiguos sin confirmar dependencias.

⚠️ Advertencia práctica: no actualices WordPress core, plugins y tema justo antes de migrar, salvo que haya una razón de seguridad urgente. Migrar y actualizar al mismo tiempo mezcla variables. Si algo falla, no sabrás si fue el servidor, el plugin, PHP, la base de datos o ese “pequeño ajuste” que parecía inofensivo.

La estrategia: dos servidores vivos, un solo dominio

La idea central de una migración sin caídas es sencilla: mantener el sitio antiguo funcionando mientras preparas una copia completa en el nuevo servidor. El dominio seguirá apuntando al hosting viejo hasta que el nuevo esté probado, ajustado y listo. Solo entonces cambias el tráfico.

Es como construir un puente paralelo antes de cerrar el viejo. La versión negligente sería dinamitar el puente actual y luego descubrir que los planos del nuevo estaban en otra carpeta. Irónico, sí. También bastante común.

Flujo general de una migración Zero Downtime

Auditar sitio y servidor actual.
Contratar y preparar el nuevo hosting.
Reducir TTL de DNS con antelación.
Crear backups completos externos.
Copiar archivos al nuevo servidor.
Exportar e importar base de datos.
Ajustar wp-config.php, permisos y configuración del servidor.
Probar el sitio nuevo usando archivo hosts, URL temporal o subdominio protegido.
Sincronizar cambios finales.
Cambiar DNS o IP.
Monitorizar tráfico, logs, pedidos, formularios, cron y SEO.
Mantener el hosting antiguo activo unos días como red de seguridad.

Preparar DNS: el pequeño reloj que decide la velocidad del cambio ⏱️

El DNS suele ser tratado como una formalidad, hasta que se convierte en protagonista. Entonces todos preguntan por qué “ya cambié la IP y todavía carga el servidor viejo”. El DNS no es un interruptor; es más bien una bandada de pájaros llevando mensajes en direcciones distintas. Algunos llegan pronto. Otros, con admirable desprecio por tu urgencia, tardan más.

Qué es el TTL y por qué importa

El TTL —Time To Live— indica durante cuánto tiempo los resolvers DNS pueden cachear un registro. Si tu registro A tiene un TTL de 14400 segundos, algunos visitantes podrían seguir llegando al servidor antiguo durante varias horas después del cambio.

Para una migración sin caídas, reduce el TTL con anticipación:

24 a 48 horas antes de migrar, baja el TTL del registro A y AAAA a 300 segundos.
Si usas Cloudflare u otro proxy/CDN, revisa si el tráfico está proxied o solo DNS.
No toques registros MX si no vas a migrar correo electrónico.
Documenta todos los registros actuales antes de modificar nada.

Registro	Uso	Riesgo al migrar
A	Apunta el dominio a una dirección IPv4.	Debe cambiarse a la IP del nuevo servidor.
AAAA	Apunta a una dirección IPv6.	Si existe y no se actualiza, algunos usuarios podrían llegar al servidor viejo.
CNAME	Alias hacia otro dominio.	Importante para `www`, CDN o servicios externos.
MX	Correo electrónico.	No modificar salvo migración de email. Aquí se rompen bandejas de entrada con sorprendente facilidad.
TXT	SPF, DKIM, DMARC, verificaciones.	Crítico para entregabilidad de correo y servicios de terceros.

💡 Consejo: si usas Cloudflare, puedes cambiar la IP del origen manteniendo el proxy activo. En muchos casos el usuario ni se entera, porque sigue entrando por la red de Cloudflare. Aun así, prueba SSL, reglas de caché, firewall, redirects y cabeceras.

Backups: la diferencia entre valentía y temeridad 🛡️

Antes de migrar, crea una copia completa del sitio. Completa significa: archivos, base de datos, configuraciones relevantes, DNS, correos si aplica y cualquier integración externa. Un backup que no se ha probado es una promesa. Bonita, quizá. Pero promesa al fin.

Qué debe incluir un backup serio

Todos los archivos de WordPress: core, temas, plugins, uploads y archivos ocultos como .htaccess.
Base de datos completa.
wp-config.php, con especial atención a prefijo de tablas, credenciales y salts.
Configuraciones del servidor: reglas Nginx, Apache, redirecciones, cron jobs.
Exportación de DNS o capturas del panel.
Configuración de SMTP, CDN, seguridad y caché.

Con WP-CLI puedes exportar la base de datos:

wp db export backup-previo-migracion.sql

Desde línea de comandos, puedes comprimir archivos:

tar -czf sitio-wordpress.tar.gz public_html/

Y si tienes acceso SSH, rsync suele ser una herramienta magnífica para copiar archivos de forma eficiente:

rsync -avz --progress usuario@servidor-origen:/ruta/public_html/ /ruta/nuevo-servidor/public_html/

⚠️ Importante: guarda al menos una copia fuera de ambos servidores. Si el backup está solo en el hosting que vas a tocar, es como guardar el paraguas dentro del coche que se está hundiendo.

Preparar el nuevo hosting: no todo servidor “rápido” está listo

El nuevo servidor debe parecerse lo suficiente al antiguo para no romper compatibilidades, pero ser mejor donde importa: rendimiento, seguridad, estabilidad, escalabilidad y soporte. Antítesis pura: continuidad sin inmovilismo; mejora sin aventura suicida.

Configuración recomendada para WordPress moderno

PHP 8.1 o superior, verificando compatibilidad de plugins y tema.
MySQL 8 o MariaDB 10.5+ en entornos actuales, según soporte del hosting.
HTTPS activo con certificado SSL válido.
HTTP/2 o HTTP/3 si está disponible.
OPcache habilitado.
Compresión Brotli o Gzip.
Backups automáticos del proveedor, idealmente externos.
Firewall a nivel servidor o WAF.
Soporte para WP-CLI y SSH, especialmente en sitios profesionales.

Crear la base de datos en el nuevo servidor

Crea una base de datos vacía y un usuario con permisos adecuados. Después actualiza wp-config.php:

define('DB_NAME', 'nombre_base_datos');
define('DB_USER', 'usuario_base_datos');
define('DB_PASSWORD', 'password_seguro');
define('DB_HOST', 'localhost');

En algunos proveedores, DB_HOST no es localhost, sino una ruta interna o host específico. Verifícalo en el panel. Es un detalle pequeño, como una llave diminuta, pero puede cerrar toda la casa.

Copiar archivos WordPress al nuevo servidor 📦

Para migrar archivos tienes varias opciones: SFTP, administrador de archivos del hosting, plugin de migración, rsync, Git o una combinación. En entornos profesionales, SSH y rsync ofrecen más control, especialmente en sitios grandes.

Opción recomendada: rsync con SSH

Desde el nuevo servidor, puedes traer los archivos del servidor antiguo:

rsync -avz --progress usuario@IP_ANTIGUA:/home/usuario/public_html/ /home/usuario/public_html/

Para una segunda sincronización más rápida antes del cambio final:

rsync -avz --delete --progress usuario@IP_ANTIGUA:/home/usuario/public_html/ /home/usuario/public_html/

El parámetro --delete elimina en destino archivos que ya no existen en origen. Úsalo con cuidado. Es útil para mantener una copia fiel, pero no perdona distracciones.

Permisos correctos

Una vez copiados los archivos, revisa permisos. Como orientación general:

Directorios: 755.
Archivos: 644.
wp-config.php: 600 o 640 si el entorno lo permite.

find /ruta/public_html -type d -exec chmod 755 {} \;
find /ruta/public_html -type f -exec chmod 644 {} \;
chmod 600 /ruta/public_html/wp-config.php

En servidores con usuarios específicos, también revisa propietario y grupo. Muchos errores 403, fallos de subida o actualizaciones imposibles nacen ahí, silenciosos como humedad detrás de una pared.

Migrar la base de datos sin romper datos serializados

La base de datos de WordPress contiene entradas, páginas, usuarios, configuraciones, widgets, menús, opciones del tema, pedidos de WooCommerce, metadatos y más. También contiene datos serializados: estructuras donde la longitud de las cadenas importa. Por eso, hacer buscar y reemplazar directamente con un editor de texto puede romper configuraciones.

Exportar la base de datos

En el servidor antiguo:

wp db export migracion.sql

O con mysqldump:

mysqldump -u usuario -p nombre_base_datos > migracion.sql

Importar en el nuevo servidor

wp db import migracion.sql

O con MySQL:

mysql -u usuario -p nombre_base_datos < migracion.sql

¿Hay que hacer search-replace?

Si mantienes el mismo dominio y la misma estructura, normalmente no necesitas reemplazar URLs. Si durante pruebas usaste una URL temporal, un subdominio o cambiaste de HTTP a HTTPS, usa WP-CLI:

wp search-replace 'http://dominio-temporal.com' 'https://tudominio.com' --all-tables --precise --recurse-objects --skip-columns=guid

No reemplaces el campo guid salvo que sepas exactamente por qué. En WordPress, el guid no está pensado como URL pública editable de forma ordinaria, aunque se parezca sospechosamente a una. WordPress tiene esas pequeñas bromas históricas.

Cómo probar el nuevo sitio antes de cambiar DNS 🧪

Esta es la parte que separa una migración limpia de una mudanza con platos rotos. Antes de apuntar el dominio al nuevo hosting, debes ver el sitio funcionando allí.

Opción 1: modificar el archivo hosts

El archivo hosts permite que solo tu ordenador resuelva el dominio hacia la nueva IP, sin afectar a los demás usuarios. Es una de esas herramientas humildes que parecen antiguas y, sin embargo, siguen salvando proyectos enteros.

En macOS o Linux:

sudo nano /etc/hosts

En Windows, abre como administrador:

C:\Windows\System32\drivers\etc\hosts

Añade:

123.123.123.123 tudominio.com
123.123.123.123 www.tudominio.com

Después limpia la caché DNS local si es necesario:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

En Windows:

ipconfig /flushdns

Opción 2: URL temporal o subdominio protegido

Algunos hostings ofrecen una URL temporal. También puedes usar un subdominio como staging.tudominio.com, protegido con contraseña o bloqueado para indexación. Si haces esto, recuerda usar search-replace correctamente antes de producción.

⚠️ SEO: no dejes un staging indexable. Añade autenticación básica, cabecera X-Robots-Tag: noindex o bloqueo adecuado. Un duplicado indexado puede convertirse en una sombra incómoda para tu sitio principal.

Checklist de pruebas antes del cambio

No basta con que la home cargue. La home es educada; casi siempre finge estar bien. Hay que revisar el sitio como lo haría un usuario real, un bot, un comprador impaciente y un plugin con mal carácter.

✅ Página de inicio, páginas internas, entradas y categorías.
✅ Login en /wp-admin.
✅ Subida de imágenes a la biblioteca de medios.
✅ Enlaces permanentes y reglas de reescritura.
✅ Formularios de contacto y notificaciones por email.
✅ Carrito, checkout y pasarelas de pago si hay WooCommerce.
✅ Área de usuario, membresías o cursos.
✅ Búsqueda interna.
✅ Imágenes, fuentes, CSS y JavaScript sin errores 404.
✅ Redirecciones 301 importantes.
✅ Certificado SSL válido y sin contenido mixto.
✅ Caché de página, caché de objetos y CDN.
✅ Cron jobs y tareas programadas.
✅ Logs de errores PHP y servidor.
✅ Sitemap XML y robots.txt.
✅ Integraciones externas: CRM, ERP, newsletter, analytics, píxeles, APIs.

SSL y HTTPS: no lo dejes para el último minuto 🔐

Un sitio migrado sin certificado SSL válido puede cargar con advertencias del navegador, bloquear recursos o romper integraciones. Y nada transmite tanta confianza como un aviso rojo diciendo que la conexión no es segura; ironías del comercio digital.

Antes del cambio DNS, instala el certificado en el nuevo hosting. Si el proveedor necesita que el dominio ya apunte al servidor para emitir Let’s Encrypt, tienes alternativas:

Usar validación DNS si el panel lo permite.
Emitir el certificado justo después del cambio, manteniendo Cloudflare en modo proxy si aplica.
Subir un certificado existente, si tienes acceso a los archivos del certificado y clave privada.
Coordinar una ventana breve de activación con el proveedor.

Después verifica:

Redirección de HTTP a HTTPS.
Ausencia de contenido mixto.
Cabeceras de seguridad: HSTS solo si estás seguro.
Compatibilidad con www y sin www.

El problema delicado: sitios dinámicos, WooCommerce y datos en tiempo real 🛒

Aquí la migración se vuelve más interesante. En un sitio corporativo, puedes copiar la base de datos, probar y cambiar DNS. Si entra un comentario durante el proceso, quizá no sea dramático. Pero en WooCommerce, cada pedido es dinero, contabilidad, cliente, email, stock y a veces impuestos. Perder un pedido es como perder una carta en una novela: quizá era la que explicaba todo.

Riesgo principal: escritura dividida

Durante la propagación DNS, algunos usuarios pueden llegar al servidor antiguo y otros al nuevo. Si ambos aceptan pedidos o registros, tendrás datos repartidos. Este es el punto donde muchos planes “sin downtime” descubren que eran solo optimismo con interfaz gráfica.

Estrategias para WooCommerce y sitios transaccionales

Estrategia	Cuándo usarla	Ventaja	Limitación
Ventana breve de solo lectura	Tiendas pequeñas o medianas.	Reduce riesgo de pedidos perdidos.	Puede impedir compras durante minutos.
Modo mantenimiento solo en checkout	WooCommerce con tráfico moderado.	El sitio sigue navegable.	Requiere comunicación clara.
Sincronización final de base de datos	Sitios con pocas escrituras.	Sencilla y efectiva.	Hay que controlar el momento exacto.
Replicación MySQL/MariaDB	Proyectos críticos o de alto volumen.	Minimiza pérdida de datos.	Más compleja; requiere experiencia.
Proxy/CDN con cambio controlado de origen	Sitios detrás de Cloudflare u otro proxy.	Transición más limpia para usuarios.	No resuelve por sí solo el problema de escrituras simultáneas.

Proceso recomendado para WooCommerce

Reducir TTL con 48 horas de antelación.
Copiar archivos y base de datos al nuevo servidor.
Probar checkout en modo sandbox.
Programar una ventana de baja actividad.
Activar temporalmente modo solo lectura, pausar checkout o mostrar aviso breve.
Exportar e importar la base de datos final.
Cambiar DNS o IP del proxy.
Verificar pedidos, pagos, emails y stock.
Reactivar operaciones normales.

💡 Nota honesta: en tiendas con pedidos constantes, prometer “cero impacto” sin arquitectura preparada es vender humo con corbata. Se puede lograr una transición prácticamente invisible, pero requiere planificación, pruebas y control de escrituras.

Sincronización final: el instante quirúrgico

Cuando el nuevo servidor ya está probado, llega el momento de sincronizar cambios finales. Si durante la preparación se subieron nuevas imágenes, se publicaron entradas o hubo pedidos, debes llevar esas diferencias al destino.

Sincronizar archivos finales

rsync -avz --delete usuario@IP_ANTIGUA:/home/usuario/public_html/ /home/usuario/public_html/

En sitios con uploads frecuentes, revisa especialmente:

wp-content/uploads
wp-content/cache, aunque normalmente no conviene migrar caché
carpetas de plugins de backup o formularios
archivos generados por plugins de descargas, facturación o LMS

Sincronizar base de datos final

Para sitios simples, puedes hacer una exportación final del origen e importarla en destino. Para WooCommerce o sitios con usuarios, hazlo durante una ventana controlada.

wp db export final.sql
scp final.sql usuario@IP_NUEVA:/home/usuario/
wp db import final.sql

Después limpia cachés:

wp cache flush
wp transient delete --all

Si usas Redis u object cache persistente, reinicia o purga según el proveedor:

wp redis flush

El comando exacto depende del plugin y del entorno. No todos los Redis obedecen igual; algunos parecen gatos.

Cambiar DNS sin provocar un pequeño eclipse digital

Con el nuevo sitio probado y sincronizado, cambia el registro A del dominio hacia la nueva IP. Si existe registro AAAA y el nuevo servidor no tiene IPv6 configurado, elimínalo o actualízalo correctamente. Muchos olvidan el AAAA y luego algunos usuarios, especialmente en redes modernas, siguen llegando al servidor anterior. Es una trampa elegante, casi invisible.

Si usas DNS tradicional

Cambia el registro A de tudominio.com a la nueva IP.
Cambia el registro A o CNAME de www.
Verifica registros AAAA.
Mantén TTL bajo durante unas horas.
Cuando todo esté estable, sube TTL a un valor razonable, como 3600 o 14400 segundos.

Si usas Cloudflare

Actualiza la IP del registro A en Cloudflare.
Mantén el proxy activo si ya estaba activo.
Purga caché si hay contenido obsoleto.
Revisa modo SSL: Full o Full Strict, idealmente Full Strict con certificado válido en origen.
Comprueba reglas de página, Transform Rules, WAF y redirecciones.

Para verificar DNS:

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

También puedes consultar resolvers públicos:

dig @1.1.1.1 tudominio.com A
dig @8.8.8.8 tudominio.com A

Después del cambio: monitorizar como quien escucha una casa nueva de noche 👂

La migración no termina cuando el dominio apunta al nuevo servidor. Termina cuando has comprobado que el sitio respira bien bajo tráfico real. Los primeros minutos y horas importan.

Revisión inmediata

Abre el sitio desde redes distintas: Wi-Fi, datos móviles, VPN.
Comprueba cabeceras HTTP y códigos de estado.
Revisa logs de error PHP.
Verifica que el panel de WordPress carga sin lentitud anormal.
Haz una compra de prueba si hay ecommerce.
Envía formularios reales.
Comprueba correos transaccionales.
Revisa Search Console y Analytics en las siguientes horas.

Comandos útiles:

curl -I https://tudominio.com
curl -I https://www.tudominio.com

Busca códigos 200, redirecciones 301 coherentes y ausencia de bucles. Un bucle de redirección es como una puerta giratoria sin salida: técnicamente hay movimiento, pero nadie llega a ninguna parte.

Revisión de logs

Según el servidor, los logs pueden estar en rutas distintas. Algunos ejemplos habituales:

/var/log/nginx/error.log
/var/log/apache2/error.log
/home/usuario/logs/
wp-content/debug.log

Si activas WP_DEBUG, no muestres errores en pantalla en producción. Usa log:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Después de diagnosticar, desactiva debug si no es necesario. Dejarlo activo eternamente es como poner cámaras en toda la casa y olvidarse de cerrar las ventanas.

SEO en una migración WordPress: conservar la memoria del sitio 📈

Una migración de hosting, si no cambia dominio ni estructura de URLs, no debería afectar negativamente al SEO. De hecho, si el nuevo servidor mejora velocidad y estabilidad, puede beneficiar la experiencia de usuario. Pero Google no premia el caos. Lo rastrea, lo indexa y, a veces, lo recuerda.

Puntos críticos para SEO técnico

Mantén la misma estructura de URLs.
Conserva redirecciones 301 existentes.
No cambies slugs durante la migración.
Verifica robots.txt.
Comprueba sitemap XML.
Revisa canonical tags.
Evita indexar entornos temporales.
Controla códigos 404 y 500.
Verifica Core Web Vitals tras el cambio.
Revisa Search Console por errores de rastreo.

Si usas plugins SEO como Yoast SEO, Rank Math, SEOPress o similares, comprueba que sus mapas del sitio se regeneran correctamente y que no arrastran URLs temporales.

Rendimiento tras la migración: no confundas servidor nuevo con sitio optimizado ⚡

Un hosting más potente puede ocultar problemas, pero no siempre los resuelve. Cambiar de servidor y esperar que un WordPress inflado se vuelva ágil por gratitud es pedirle poesía a una lavadora. Puede sorprenderte, sí, pero no conviene basar la estrategia en eso.

Qué optimizar después

Activar OPcache.
Configurar caché de página.
Usar caché de objetos con Redis si el sitio lo justifica.
Optimizar imágenes: WebP/AVIF cuando sea viable.
Revisar consultas lentas.
Eliminar plugins redundantes.
Configurar CDN para recursos estáticos.
Revisar precarga de fuentes y scripts críticos.
Medir TTFB antes y después.

Herramientas útiles:

PageSpeed Insights.
GTmetrix.
WebPageTest.
Query Monitor para WordPress.
New Relic o herramientas APM similares en proyectos avanzados.

Seguridad: migrar también es una oportunidad para cerrar puertas 🧱

Muchas migraciones arrastran años de polvo: usuarios administradores olvidados, plugins abandonados, temas viejos, claves FTP que deberían estar jubiladas y archivos .zip con nombres como backup-final-definitivo-ahora-si.zip. Todos hemos visto alguno. Nadie está orgulloso.

Medidas recomendadas

Actualizar salts de WordPress si sospechas exposición de credenciales.
Cambiar contraseñas de FTP, SSH, base de datos y usuarios administradores.
Eliminar usuarios innecesarios.
Desactivar edición de archivos desde el panel:

define('DISALLOW_FILE_EDIT', true);

Verificar permisos de archivos.
Eliminar instaladores, backups públicos y archivos temporales.
Configurar firewall o WAF.
Activar autenticación en dos pasos para administradores.
Revisar plugins y temas sin mantenimiento.
Configurar backups automáticos externos.

Errores comunes al migrar WordPress a otro hosting

Algunos errores se repiten tanto que parecen tradiciones. Malas, pero tradiciones.

Error	Consecuencia	Cómo evitarlo
No reducir TTL antes	Propagación lenta y tráfico dividido durante más tiempo.	Bajar TTL 24-48 horas antes.
Olvidar registros AAAA	Usuarios con IPv6 llegan al servidor antiguo.	Actualizar o eliminar AAAA si no aplica.
No probar con archivo hosts	Descubrir errores cuando ya hay tráfico real.	Probar el dominio en el nuevo servidor antes del cambio.
Buscar y reemplazar URLs con SQL simple	Datos serializados dañados.	Usar WP-CLI o herramientas compatibles con serialización.
Migrar cachés antiguas	Contenido roto, rutas incorrectas, errores extraños.	Vaciar caché antes y después.
Apagar el servidor viejo demasiado pronto	Pérdida de datos o usuarios aún llegando al origen.	Mantenerlo activo al menos 72 horas, según TTL y criticidad.
No revisar emails	Formularios y pedidos sin notificaciones.	Configurar SMTP y probar envíos reales.
Cambiar demasiadas cosas a la vez	Diagnóstico difícil si algo falla.	Migrar primero, optimizar después.

Migración con plugins: cuándo sí y cuándo no

Plugins como Duplicator, All-in-One WP Migration, UpdraftPlus, WPvivid o Migrate Guru pueden ser muy útiles. No hay que despreciarlos por orgullo técnico. A veces son como una buena navaja suiza: no construyen una catedral, pero resuelven el picnic.

Úsalos cuando:

El sitio es pequeño o mediano.
No hay pedidos o datos críticos en tiempo real.
No tienes acceso SSH.
El hosting limita herramientas avanzadas.
Necesitas una migración rápida y controlada.

Evítalos o combínalos con método manual cuando:

El sitio pesa decenas de gigabytes.
Hay WooCommerce con pedidos frecuentes.
Existen tablas enormes.
Hay configuraciones complejas de servidor.
Necesitas mínima ventana de escritura.
Hay requisitos de compliance, auditoría o alta disponibilidad.

El problema no es el plugin; es creer que un botón sustituye al criterio. La automatización es magnífica cuando sabe uno qué está automatizando.

Plan de migración profesional paso a paso

Este sería un plan realista para migrar WordPress a un nuevo servidor hosting sin caídas en la mayoría de escenarios profesionales.

48 horas antes

Auditar hosting actual y nuevo.
Reducir TTL DNS a 300 segundos.
Confirmar acceso a panel DNS.
Verificar credenciales SSH, SFTP, base de datos y WordPress.
Crear backup completo externo.
Revisar compatibilidad de PHP y extensiones.

24 horas antes

Preparar nuevo servidor.
Crear base de datos y usuario.
Copiar archivos iniciales.
Importar base de datos inicial.
Ajustar wp-config.php.
Configurar SSL si es posible.
Configurar Nginx, Apache o LiteSpeed.

Horas antes

Probar sitio usando archivo hosts.
Revisar formularios, checkout, login, medios y enlaces permanentes.
Solucionar errores de logs.
Configurar caché y CDN con prudencia.
Preparar plan de rollback.

Momento de cambio

Activar modo solo lectura si el sitio recibe datos críticos.
Realizar sincronización final de archivos.
Exportar e importar base de datos final.
Limpiar cachés.
Cambiar DNS o IP de origen en CDN.
Verificar resolución DNS desde varios resolvers.
Hacer pruebas funcionales inmediatas.

Primeras 24-72 horas

Mantener hosting antiguo activo.
Monitorizar logs.
Revisar pedidos, registros y formularios.
Comprobar métricas de rendimiento.
Revisar Search Console.
Subir TTL a valor normal cuando todo esté estable.
Cancelar hosting antiguo solo cuando ya no reciba tráfico ni datos.

Plan de rollback: el paracaídas que ojalá no uses 🪂

Un plan profesional siempre incluye marcha atrás. No porque esperes fallar, sino porque los sistemas reales tienen costumbres propias. A veces una extensión PHP falta, una regla Nginx contradice a WordPress, un plugin codificado con entusiasmo en 2014 decide rebelarse. La informática, como el clima, humilla a los soberbios.

Rollback básico

Mantén intacto el servidor antiguo.
No borres la base de datos original.
No cambies contraseñas críticas antes de confirmar estabilidad.
Conserva el TTL bajo para poder revertir IP rápidamente.
Documenta la IP antigua y registros DNS previos.

Si algo grave ocurre, puedes apuntar el dominio de nuevo al servidor anterior. Pero cuidado: si el nuevo servidor ya recibió pedidos o registros, revertir sin sincronizar puede perder datos. En sitios transaccionales, rollback y consistencia de datos deben pensarse juntos.

¿Cuánto tarda una migración WordPress sin caídas?

Depende del tamaño, acceso técnico y complejidad. Como referencia:

Tipo de sitio	Tiempo estimado	Complejidad
Blog pequeño o web corporativa	1 a 3 horas	Baja
WordPress con muchos medios	3 a 8 horas	Media
WooCommerce pequeño	4 a 10 horas	Media-alta
Membresía, LMS o reservas	6 a 12 horas	Alta
WooCommerce de alto tráfico	Planificación por fases	Crítica

El tiempo visible para el usuario puede ser cero o casi cero. El trabajo invisible, en cambio, es donde vive la calidad.

Preguntas frecuentes sobre migrar WordPress sin downtime

¿Puedo migrar WordPress sin apagar el sitio?

Sí. Manteniendo el servidor antiguo activo mientras preparas el nuevo, probando antes del cambio DNS y realizando una sincronización final. En sitios con datos en tiempo real, necesitarás controlar escrituras para evitar información dividida.

¿Debo cambiar los nameservers o solo el registro A?

Si solo migras hosting web, normalmente basta con cambiar el registro A y, si aplica, AAAA o CNAME de www. Cambiar nameservers implica mover toda la zona DNS y aumenta el riesgo de afectar correo u otros servicios.

¿Cuánto tarda la propagación DNS?

Depende del TTL y de cachés intermedias. Con TTL bajo, muchos cambios se reflejan en minutos. Aun así, algunos proveedores o redes pueden tardar más. Por eso conviene mantener el servidor anterior activo durante al menos 48-72 horas.

¿La migración afecta al SEO?

No debería, si mantienes URLs, redirecciones, contenido, metadatos y disponibilidad. Una migración mal ejecutada puede generar errores 404, 500, problemas de indexación o lentitud. Una migración bien hecha incluso puede mejorar rendimiento.

¿Qué hago si después de migrar aparece “Error establishing a database connection”?

Revisa DB_NAME, DB_USER, DB_PASSWORD y DB_HOST en wp-config.php. Verifica que el usuario tenga permisos y que el servicio MySQL/MariaDB esté activo.

¿Es mejor usar un plugin o migrar manualmente?

Para sitios pequeños, un plugin puede ser suficiente. Para sitios grandes, WooCommerce, membresías o entornos críticos, la migración manual o semimanual con SSH, WP-CLI y rsync ofrece más control y menor riesgo.

Una migración limpia es una migración que nadie nota

La mejor migración WordPress no tiene épica visible. No hay pantalla de mantenimiento dramática, no hay clientes escribiendo “no puedo entrar”, no hay pánico en el chat interno. Solo un sitio que, de pronto, responde más rápido, vive en un servidor mejor y sigue su rutina como si nada hubiera pasado.

Ese es el arte discreto del Zero Downtime: mover una estructura compleja sin romper su música. Detrás hay DNS preparado, backups verificados, pruebas con archivo hosts, sincronización final, SSL correcto, logs vigilados y una pizca de humildad técnica. Porque un sitio web, aunque parezca intangible, tiene peso. Pesa en ventas, en reputación, en posicionamiento, en confianza.

Migrar sin caídas no consiste en correr. Consiste en llegar sin que el visitante tropiece. Y en internet, donde la paciencia dura menos que una chispa sobre papel seco, eso ya es una forma de excelencia. ✅