Se abre en una pestaña nueva
Cómo migrar WordPress sin downtime (guía 2026) - ilustracion

Cómo migrar WordPress sin downtime (guía 2026)

En pocas palabras: Se migra WordPress sin downtime subiendo archivos y base de datos al hosting nuevo, probando el sitio con el archivo hosts local y recién después cambiando las DNS. El dominio sigue apuntando al hosting viejo hasta validar que todo funcione.

Migrar WordPress sin downtime significa mover tu sitio de un hosting a otro sin que los visitantes vean una página caída, un error 500 o un «mantenimiento en curso» durante horas. Se logra probando el sitio completo en el servidor nuevo antes de tocar el DNS público, un proceso que en esta guía llamamos «Interactive Update» aunque no es un término oficial del core de WordPress ni un nombre estandarizado en la industria del hosting.

El Interactive Update, en la práctica, es un entorno de staging o sandbox donde subís los archivos y la base de datos, verificás visualmente que todo funcione, y recién después promovés los cambios a producción de forma atómica. No tumbás el sitio en vivo en ningún momento del proceso, porque el dominio real sigue apuntando al hosting viejo hasta el último paso.

En 30 segundos

  • Migrar WordPress sin downtime implica probar el sitio en el hosting nuevo con el archivo hosts local antes de cambiar el DNS público.
  • «Interactive Update» no es jerga oficial de developer.wordpress.org, sino la forma de describir un staging controlado que se promueve a producción.
  • El checklist mínimo: backup completo de archivos y base de datos, acceso FTP/SSH al nuevo hosting, y bajar el TTL del DNS con anticipación.
  • Con WP-CLI, el comando search-replace evita enlaces rotos al cambiar de dominio o de URL base.
  • La propagación de DNS puede tardar de 4 a 48 horas según el proveedor y el TTL configurado.

¿Qué es el Interactive Update y cómo evita la caída del sitio durante una migración?

El Interactive Update es un mecanismo donde copiás tu sitio a un entorno aislado, lo revisás a mano (de ahí lo de «interactivo») y solo después lo subís a producción. No existe como feature nativa documentada en el manual de actualización del core de WordPress, que habla de updates de un click o manuales.

¿Y qué tiene que ver esto con migrar de hosting? Todo. El principio es el mismo: nunca tocás el sitio que ven tus visitantes hasta que confirmaste que la copia nueva funciona. Ya sea que lo hagas con una función de tu hosting, con un plugin o a mano con el archivo hosts, el objetivo es idéntico.

¿Qué necesitás antes de empezar a migrar tu WordPress?

Antes de mover un solo archivo necesitás cuatro cosas: backup completo, acceso al hosting destino, un TTL de DNS bajo, y un plan B si algo falla. Sin esto, cualquier migración se convierte en una apuesta. Sobre eso hablamos en migrar tu sitio usando Duplicator.

  • Backup completo de archivos y base de datos. El handbook oficial de WordPress es categórico en esto: antes de cualquier operación grande, backup de todo, incluyendo el .htaccess, y verificar que ese backup se pueda restaurar. No sirve de nada un backup que nunca probaste.
  • Acceso FTP, SSH o panel al hosting nuevo. Vas a necesitar subir archivos y crear una base de datos MySQL antes de tocar nada en producción, según detalla la guía de Raiola Networks sobre migración manual.
  • TTL del DNS bajo con anticipación. Esto acorta el tiempo de propagación cuando llegue el momento de cambiar los registros A.
  • Un hosting destino que soporte WordPress en serio. Si vas a migrar, elegí un proveedor con soporte técnico real para WP. Para proyectos en Argentina, el hosting WordPress de Donweb tiene migración asistida, que te saca de encima buena parte de este dolor de cabeza.

Ojo con esto: si tu hosting actual tiene WP-Toolkit (algo común en paneles cPanel o Plesk, según menciona el propio developer.wordpress.org), puede que ya tengas herramientas de un click para parte de este proceso. Vale la pena mirar antes de armar todo a mano.

¿Cómo migrar los archivos y la base de datos de WordPress paso a paso?

La migración de archivos y base de datos se hace en dos frentes paralelos: copiar la carpeta wp-content junto con los archivos core, y exportar/importar la base MySQL. Raiola Networks lo resume bien: primero subís el dump SQL, después los archivos, y recién al final editás la configuración.

Si vas por el camino manual, el orden que funciona es este: sacás un dump de la base vía phpMyAdmin (o con WP-CLI si tenés acceso SSH), comprimís los archivos de WordPress en origen, los subís por FTP o File Manager al nuevo servidor, y creás la base de datos nueva antes de importar el SQL. La carpeta wp-content y el archivo wp-config.php son los elementos críticos. Sin ellos, según remarca Raiola, no tenés garantía de que la migración funcione.

Si preferís no hacerlo a mano, plugins como Duplicator automatizan buena parte del proceso. Según documenta WPBeginner, Duplicator genera un paquete (archive.zip) y un instalador (installer.php) que subís al hosting destino. Corrés el instalador, apuntás a la base de datos nueva, y el plugin se encarga de reescribir las rutas automáticamente. Es más cómodo, aunque la versión gratuita (Duplicator Lite) tiene funciones limitadas en comparación con la versión Pro.

¿Cómo probar el sitio nuevo antes de cambiar el DNS público?

Probás el sitio nuevo editando el archivo hosts de tu computadora para que tu dominio apunte temporalmente a la IP del hosting destino, sin que el resto del mundo note nada. Esto es, en esencia, el «interactive update» hecho a mano: vos ves el sitio nuevo, el resto de los visitantes sigue viendo el viejo.

El procedimiento, según detalla WPBeginner, es así: conseguís la IP del servidor nuevo desde el panel de hosting, abrís el archivo hosts (en Windows es C:\Windows\System32\drivers\etc\hosts, en Mac se edita con sudo nano /private/etc/hosts), y agregás una línea con la IP nueva seguida de tu dominio. Guardás, y listo: tu navegador ahora ve el sitio nuevo cuando escribís tu dominio, mientras que cualquier otra persona en el mundo sigue viendo el sitio viejo sin enterarse de nada.

Con eso podés navegar el sitio completo en el servidor destino, entrar al wp-admin, revisar que las imágenes carguen, probar formularios, chequear el checkout si tenés WooCommerce. Si algo falla, lo arreglás ahí, sin presión, porque el sitio público sigue funcionando en el hosting viejo. Recién cuando todo esté verificado pasás al paso del DNS. Y sí: no te olvides de deshacer el cambio en el archivo hosts después, porque si no, vos vas a seguir viendo una versión del sitio que ya no es la real.

¿Cómo actualizar las URLs y evitar enlaces rotos después de migrar?

Actualizás las URLs corriendo un search-replace con WP-CLI sobre la base de datos completa, reemplazando el dominio o la ruta vieja por la nueva en todas las tablas de una sola pasada. Si cambiaste de dominio o de carpeta raíz, este paso no es opcional: sin él, tenés imágenes rotas, enlaces internos muertos y el checkout de WooCommerce apuntando a una URL que ya no existe. Esto se conecta con lo que analizamos en entender mejor el core de WordPress.

El comando típico es wp search-replace 'https://dominioviejo.com' 'https://dominionuevo.com' --all-tables. Corre sobre posts, opciones, metadatos, prácticamente todo lo que guarda WordPress en texto plano dentro de la base. Si no tenés acceso SSH para usar WP-CLI, la alternativa es hacerlo manualmente en phpMyAdmin, aunque ahí hay que tener cuidado con los datos serializados (arrays de PHP guardados como string), porque un reemplazo mal hecho puede corromper la configuración de algunos plugins o de los widgets. La razón técnica es simple: un string serializado guarda la longitud exacta del texto original, así que si reemplazás «a mano» y cambiás esa longitud sin actualizar el número que la precede, PHP deja de poder leer ese dato y el plugin lo descarta o tira error.

Además de la base, revisá el wp-config.php: ahí van los datos de conexión a la base nueva (host, usuario, contraseña, nombre de la DB), según lo describe Raiola Networks en su guía de migración manual. Y si tu tema o algún plugin guarda rutas absolutas hardcodeadas en archivos PHP (pasa más de lo que debería), esas también hay que ajustarlas a mano.

¿Cómo cambiar el DNS sin generar downtime?

Cambiás el DNS bajando el TTL a un valor chico con anticipación al corte, y manteniendo ambos servidores activos y sincronizados hasta que el 100% del tráfico pase al nuevo. Así, cuando actualizás el registro A, la propagación es rápida y no hay una ventana larga donde parte de tus visitantes vean el sitio viejo y parte el nuevo con contenido desactualizado.

La propagación de DNS varía según el proveedor del dominio y el TTL que tenía configurado antes del cambio. Puede tardar entre 4 y 48 horas en completarse, siendo más rápida cuando el TTL se bajó con anticipación. Durante ese período de transición, lo más seguro es dejar el sitio viejo intacto (no lo borres todavía) para que los visitantes que todavía resuelven al servidor anterior no se encuentren con una página caída.

Subís el sitio nuevo, lo probás en local con el archivo hosts, funciona bárbaro, cambiás el DNS, y de repente algunos usuarios ven el sitio nuevo y otros el viejo porque la propagación todavía no terminó en todos los resolutores del mundo. Es normal. No es un error tuyo, es cómo funciona el sistema. Por eso el truco de bajar el TTL antes no es opcional si te importa minimizar esa ventana.

Ejemplo hipotético (caso ilustrativo, no es un caso real): imaginá que tenés que migrar «tienda-ejemplo.com» de un hosting a otro. Un orden razonable, siguiendo la lógica descrita arriba, sería algo así:

  • Unos días antes: bajás el TTL del DNS a un valor chico para que, cuando llegue el momento del corte, la propagación sea lo más rápida posible.
  • Día de la migración, primera mitad: sacás el dump de la base y comprimís los archivos en el hosting viejo, los subís al nuevo y creás la base de datos destino.
  • Día de la migración, segunda mitad: editás el archivo hosts de tu computadora para apuntar tu dominio a la IP del hosting nuevo, y recorrés el sitio completo: home, posts, wp-admin, y si hay WooCommerce, un intento de checkout de prueba.
  • Si algo falla: lo corregís ahí mismo (base mal importada, plugin incompatible, ruta hardcodeada) sin ninguna presión, porque el público sigue viendo el hosting viejo.
  • Recién entonces: cambiás el registro DNS y dejás el hosting viejo activo sin borrar nada hasta confirmar que la propagación terminó para la mayoría de los visitantes.

Este orden —verificar antes de exponer, exponer antes de borrar— es la idea central detrás de cualquier migración «sin downtime», más allá de qué herramienta uses para ejecutarla.

¿Qué métodos de migración de WordPress existen y cuál conviene usar?

Existen tres caminos principales para migrar WordPress: manual (phpMyAdmin + FTP), con plugin (Duplicator y similares), o asistida por el panel del hosting (WP-Toolkit en cPanel/Plesk). Cada uno tiene un trade-off distinto entre control, velocidad y curva de aprendizaje.

MétodoTiempo estimadoRiesgo de downtimeNivel técnico requerido
Manual (phpMyAdmin + FTP)Variable según el tamaño del sitioBajo si se usa archivo hostsAlto
Plugin (Duplicator u otro)Variable, depende de la configuraciónBajoMedio
Asistida por hosting (WP-Toolkit)Variable según el hostingMuy bajoBajo
migrar wordpress sin downtime diagrama explicativo

El método manual te da control total sobre cada archivo y cada tabla, pero exige saber qué estás haciendo. Si nunca editaste un wp-config.php a mano, no es el mejor lugar para arrancar. El método con plugin es el punto medio: automatiza el search-replace y empaqueta todo, aunque depende de que el plugin esté bien configurado y de las funciones disponibles en la versión que uses (las versiones gratuitas suelen tener funciones limitadas). La migración asistida por el hosting es la más cómoda, siempre que tu proveedor la ofrezca de verdad y no solo de nombre.

¿Cómo elegir entre los tres? Algunos criterios prácticos, en base a lo que venimos repasando:

  • Elegí el método manual si tenés experiencia previa editando bases de datos y archivos de configuración, y necesitás control fino sobre qué se mueve y qué no (por ejemplo, si querés dejar afuera ciertas tablas o carpetas).
  • Elegí un plugin como Duplicator si querés automatizar el search-replace y el empaquetado, pero no tenés acceso SSH o preferís no tocar la base a mano. Es un buen punto medio entre control y comodidad.
  • Elegí la migración asistida del hosting si tu proveedor nuevo la ofrece de verdad (no solo como promesa de marketing) y preferís delegar el proceso completo, especialmente si el sitio tiene mucho tráfico o no tenés margen para improvisar el día del corte.

¿Qué está confirmado y qué no sobre el Interactive Update en hosting WordPress?

  • Confirmado: WordPress core documenta oficialmente el proceso de actualización de un click y manual en su handbook de administración avanzada, pero no usa el término «Interactive Update» como feature propia.
  • No confirmado: que «Interactive Update» sea un nombre estandarizado en la industria del hosting. Cada proveedor que ofrece algo parecido lo llama distinto (staging, sandbox, preview environment).

¿Qué errores comunes causan downtime al migrar WordPress?

Los errores más frecuentes al migrar no son técnicos complejos, son descuidos del checklist básico. Repasemos los tres que más tiempo de caída generan en la práctica.

  • Cambiar el DNS antes de verificar el sitio nuevo. Es el error número uno. Si apuntás el dominio al hosting destino sin haberlo probado con el archivo hosts primero, cualquier falla (base mal importada, plugin incompatible) la ven todos tus visitantes en tiempo real.
  • No bajar el TTL con anticipación. Si tu TTL está configurado en un valor alto (el default en muchos proveedores), el cambio de DNS puede tardar más en propagar completamente, dejando una ventana larga de inconsistencia.
  • Olvidarse del search-replace en datos serializados. Reemplazar URLs directamente en phpMyAdmin sin herramientas que entiendan la serialización de PHP corrompe la configuración de theme options, widgets y algunos plugins populares.
  • Borrar el sitio viejo antes de confirmar la propagación completa del DNS. Como la propagación no es instantánea en todo el mundo, borrar el hosting anterior demasiado pronto deja a una porción de usuarios sin sitio durante horas.

Preguntas Frecuentes

¿Cómo migro mi sitio WordPress a otro hosting sin que se caiga?

Subís archivos y base de datos al hosting nuevo, probás todo con el archivo hosts local apuntando a la IP destino, y recién después cambiás el DNS público con el TTL bajado previamente. El sitio en vivo sigue funcionando en el hosting viejo durante toda la prueba, así que los visitantes nunca ven una caída. Cubrimos ese tema en detalle en probar los cambios en un entorno de staging.

¿Qué es el Interactive Update en un hosting de WordPress?

Es la forma de describir un entorno de staging o sandbox donde se aplican cambios o migraciones, se verifican visualmente, y después se promueven a producción de forma atómica. No es un término oficial del core de WordPress, sino un concepto que algunos proveedores y herramientas de staging implementan bajo distintos nombres.

¿Cuánto tarda en propagarse el DNS al migrar un WordPress?

Puede tardar entre 4 y 48 horas, dependiendo del TTL configurado antes del cambio y de los resolutores DNS que usen tus visitantes. Bajar el TTL del DNS con anticipación acelera notablemente la propagación.

¿Cómo pruebo mi WordPress en el nuevo hosting antes de cambiar el DNS?

Editás el archivo hosts de tu computadora agregando una línea con la IP del servidor nuevo y tu dominio, lo que hace que tu navegador vea el sitio destino sin afectar a nadie más. Así podés revisar el wp-admin, el frontend y funcionalidades críticas antes del cambio real.

¿Qué pasa si no actualizo las URLs después de migrar WordPress a otro dominio o hosting?

Quedan enlaces internos rotos, imágenes que no cargan y, si tenés WooCommerce, el checkout puede apuntar a una URL inexistente. El comando wp search-replace de WP-CLI resuelve esto reemplazando el dominio viejo por el nuevo en todas las tablas de la base de datos.

Conclusión

Migrar WordPress sin downtime no depende de una feature mágica llamada «Interactive Update», depende de un orden de operaciones bien ejecutado: backup, prueba aislada con el archivo hosts, verificación de URLs con WP-CLI, y DNS con TTL bajo recién al final. El concepto de staging antes de producción ya es una práctica habitual en el ecosistema de hosting, así que no hace falta inventar nada, solo aplicarlo con disciplina.

Si vas a migrar un sitio con tráfico real, no improvises el día del corte. Armá el checklist, probá todo en el hosting destino antes de tocar el DNS, y si preferís no lidiar con cada paso a mano, buscá un proveedor que incluya migración asistida real, no solo de nombre. El hosting WordPress de Donweb es una opción pensada justamente para sacarte ese trabajo de encima sin perder control sobre el resultado final.

Fuentes

Volver a

Novedades

Publicaciones relacionadas