Cómo migrar WordPress a otro hosting sin perder datos

La forma más segura de migrar WordPress a otro hosting sin perder datos es preparar primero el destino, crear una copia inicial, aplicar una barrera durable o sincronizar las escrituras, ejecutar un delta final, probar el nuevo servidor con el dominio forzado y cambiar DNS solo cuando exista un rollback comprobable. Después del corte, conserva el origen y vigila ambos servidores hasta que expire el periodo de observación. Esta secuencia amplía el proceso general de la documentación oficial para migrar WordPress con controles para sitios que reciben pedidos, formularios, altas o cambios de contenido.

“Sin downtime” no significa que todo sitio pueda moverse sin una interrupción perceptible. Una web principalmente informativa puede acercarse mucho; WooCommerce, Easy Digital Downloads, membresías y comunidades necesitan una breve ventana de solo lectura, sincronización específica o una arquitectura capaz de replicar escrituras. La meta honesta es downtime mínimo y ninguna escritura ignorada, no una garantía universal de cero segundos.

Elige el método antes de copiar nada

Métodos para mover WordPress a otro hosting

Elige la ruta más simple que permita controlar las escrituras y volver atrás. Un plugin no elimina el problema de consistencia: si el origen acepta un pedido después de empaquetar la base, ese pedido no aparecerá mágicamente en el destino. De igual forma, una copia completa del panel no demuestra que la aplicación funcione.

Si el destino todavía no existe, revisa cómo elegir un hosting web y cómo instalar WordPress en un hosting o VPS. Confirma primero que el plan admite el tamaño, el tráfico y las versiones que necesita tu sitio.

Haz un inventario y fija criterios de go/no-go

La migración empieza con una fotografía operativa. Registra el responsable de cada comprobación y no pases al corte si falta un dato crítico:

• Aplicación: versión de WordPress, PHP y motor de base de datos; plugins, tema, mu-plugins, multisite, domain mapping, caché persistente y código personalizado.
• Capacidad: tamaño de archivos y base, inodos, espacio temporal y libre en destino, límites de subida, memoria y tiempo de ejecución.
• Servidor: document root, propietario, permisos, extensiones PHP, reglas Apache/Nginx, tareas cron, colas y procesos auxiliares.
• Integraciones: SMTP, pasarela de pago, webhooks entrantes y salientes, formularios, CRM, almacenamiento externo, búsqueda, licencias ligadas a IP o dominio y API allowlists.
• Red y nombres: zona DNS completa, A, AAAA, CNAME, MX, TXT, nameservers, proveedor autoritativo, TTL, CDN/proxy, certificado y estado DNSSEC/DS.
• Datos que cambian: pedidos, descargas, usuarios, comentarios, sesiones, reservas, leads, uploads y cualquier sistema externo que vuelva a escribir en WordPress.

Este inventario de solo lectura ofrece una base reproducible para la ruta WP-CLI. Ejecútalo como el usuario propietario del sitio, no como root, y sustituye los valores reservados:

Guarda también capturas o exportaciones de la configuración que no vive en WordPress. No copies secretos a las notas. Multisite, domain mapping, clústeres, bases externas y sitios de alta escritura deben tener un runbook específico; el procedimiento genérico de esta guía no basta.

Define el go/no-go antes de la ventana: espacio libre suficiente, backup restaurable, versiones compatibles, barrera durable elegida y ensayada con bypass de operador, pruebas externas de rechazo, monitor independiente, TLS válido, checkout y formularios aprobados, logs sin errores nuevos, responsable del DNS presente y tiempo reservado para revertir. Define también un límite: si una prueba crítica no se corrige antes de una hora acordada, no se corta.

Crea un backup restaurable, no solo un archivo

Un sitio WordPress completo requiere archivos y base de datos. La guía oficial de backups de WordPress explica por qué son conjuntos distintos. Almacena la copia fuera del document root y, si es posible, fuera del servidor de origen. Una captura del panel o un snapshot puede complementar el backup, pero no sustituye una exportación portable ni una prueba de restauración.

Fija un MIGRATION_ID UTC único e inmutable para toda la corrida y no reutilices una ruta parcial. Antes de cada export o tar, test ! -e impide sobrescribir la única copia buena. Además, wp db export exporta todas las tablas de DB_NAME si omites --tables. El ejemplo obtiene con wp db tables --all-tables-with-prefix una lista CSV, la muestra para revisión y la pasa entre comillas a --tables, sin word splitting:

Si el origen comparte DB_NAME, esta lista explícita evita exportar por defecto tablas ajenas, pero debes comprobar tablas de plugins que no sigan el prefijo. Multisite, tablas compartidas o personalizadas y domain mapping requieren un runbook propio que enumere todas las dependencias; no amplíes el alcance a ciegas.

Conserva los checksums, el MIGRATION_ID, prefijo, lista aprobada, fecha, versiones y alcance. La prueba fuerte consiste en restaurar los artefactos en un entorno aislado, abrir el sitio y documentar duración y resultado. Un código de salida cero no demuestra por sí solo que el backup sea utilizable.

Prepara el destino y realiza la copia inicial

Configura en el destino el virtual host, PHP, una base de datos dedicada, usuario de base, TLS, propietarios, tareas y espacio. Reproduce las constantes necesarias de wp-config.php sin copiar credenciales a tickets. Si cambia PHP, la base o el servidor web, prueba compatibilidad antes de combinar ese cambio con el corte.

Verifica la huella SSH del destino por un canal independiente —consola del proveedor, inventario firmado o responsable autorizado— antes de aceptar la primera conexión; no confíes en una huella obtenida por la misma ruta que intentas autenticar. Si origen y destino usan Redis, Memcached u otra caché persistente, asigna al clon credenciales o namespace aislado antes de probarlo. No ejecutes un flush mientras ambos sitios compartan el mismo namespace.

Mantén desactivados en el destino cron, workers, webhooks y correo entrante/saliente hasta la activación coordinada; pagos y mensajes de prueba deben usar sandbox o destinatarios controlados. Así el clon no ejecuta trabajos duplicados antes de recibir tráfico real.

WP-CLI, rsync del document root y el dump de WordPress no migran buzones, aliases, forwarders ni historial de mensajes. Si el correo vive en el hosting anterior, crea un runbook paralelo: inventaría y provisiona cuentas/aliases/reenviadores, sincroniza mensajes con el método admitido por el servicio, valida SMTP, IMAP y entrega real, y reproduce SPF, DKIM, DMARC, PTR y allowlists donde corresponda. No cambies MX ni apagues el correo antiguo hasta completar esas pruebas. La ejecución depende de los servicios implicados; no hay un comando universal seguro.

La primera sincronización ocurre mientras el origen sigue activo. Se ejecuta como propietario del sitio, usa SSH ya verificado y no incluye --delete:

Revisa el listado y reconcilia las constantes personalizadas. La ausencia de --delete protege archivos del destino, pero también conserva archivos eliminados en el origen. Antes de go-live compara ambos árboles y borra solo una lista aprobada. Si el equipo decide usar rsync --delete, debe tener backup del destino, las mismas exclusiones, un --dry-run --itemize-changes revisado y un gate explícito antes de la ejecución; el bloque genérico no lo hace.

La importación inicial con wp db import fija el mismo MIGRATION_ID, exporta solo la lista de tablas revisada y transfiere dump, manifest y prefijo. Antes del import compara $table_prefix con wp config get table_prefix --type=variable, muestra todas las tablas existentes en destino y exige que la base sea dedicada, vacía o expresamente aprobada:

--add-drop-table solo añade DROP TABLE para las tablas incluidas en el dump; wp db import no limpia tablas extra. Por eso el destino debe ser una DB dedicada vacía/aprobada, o tener un inventario y una limpieza separados con backup y gate. La comparación posterior exige exactamente las tablas prefijadas esperadas y valida home/siteurl. Si falla copia, backup, prefijo, alcance, import o verificación, DNS no cambia.

Usa search-replace solo cuando cambie una URL

Si dominio y protocolo finales no cambian, normalmente no necesitas reemplazar URLs. Si usaste una URL temporal, wp search-replace procesa datos serializados, a diferencia de un REPLACE() SQL indiscriminado. Excluye guid, revisa --dry-run y crea un backup nuevo, no sobrescribible, antes de aplicar:

Revisa tablas de plugins fuera del prefijo antes de ampliar el alcance. No sustituyas cadenas que no comprendes ni cambies dominios de correo, claves o datos externos por coincidencia accidental.

Prueba el destino antes de cambiar DNS

curl --resolve conecta el nombre real a una IP elegida sin modificar DNS. Así pruebas virtual host y certificado con la URL canónica. --fail-with-body requiere curl 7.76 o posterior; en una versión anterior usa --fail y conserva el resto de controles. No añadas -k: un fallo TLS debe detener el corte.

Para una prueba de navegador puedes añadir temporalmente el nombre al archivo hosts de tu equipo, pero documenta y retira esa entrada después. Prueba en el destino:

• Portada, páginas, búsquedas, redirecciones, 404 y área administrativa.
• Login y cierre de sesión, roles, creación controlada de contenido y subida de una imagen desechable.
• Formulario, carrito, checkout en modo de prueba, impuestos, descarga, membresía o reserva según el negocio.
• Correo recibido —no solo “enviado”—, webhooks en ambos sentidos, cron, colas y callbacks de pago.
• HTTPS, contenido mixto, cabeceras, caché de página/objeto, CDN y purga.
• Logs PHP, web y base de datos; consumo de CPU, memoria, disco e inodos.

Comprueba también que las URLs, canonical, robots, sitemap, datos estructurados, analítica y códigos de estado coinciden con el origen. Un hosting nuevo no debería convertir una migración sin cambio de URL en un rediseño o reestructuración simultáneos.

Controla las escrituras y aplica el delta final

La copia inicial queda obsoleta en cuanto llega un pedido o upload. Enumera visitantes, administradores, WP-Cron, cron del sistema, workers, colas, webhooks, importadores y APIs; pausa cada escritor de forma reversible y registra cómo demostrarás que dejó de cambiar datos.

El modo estándar basado en .maintenance no es una barrera durable. El core, mediante wp_is_maintenance_mode(), lee el timestamp y deja de considerar activo el modo estándar tras aproximadamente diez minutos. WP-CLI puede gestionarlo como UX, pero no debe proteger pedidos o formularios durante una migración larga.

Antes de la ventana, elige y ensaya una barrera de escritura no expirable que permanezca hasta una retirada explícita en edge/CDN, webserver, aplicación o control del proveedor. Debe cubrir origen y destino; rechazar checkout, formularios, altas, comentarios, escrituras de wp-admin y REST/API; y permitir acceso de operador con bypass autenticado o allowlist controlada. No existe un comando universal seguro.

Desde una red externa sin bypass, ejecuta pruebas negativas y confirma que ninguna ruta crea registros. Mantén un monitor independiente durante delta, export, import y DNS. Si una escritura deja de rechazarse o se pierde señal, aborta, restablece la barrera, contabiliza cambios desde el último checkpoint y repite delta/import.

Este bloque exige barrera y writers pausados, reconcilia explícitamente archivos eliminados y exporta exactamente la lista de tablas revisada. El MIGRATION_ID debe coincidir con el resto de la corrida:

Transfiere dump y manifests. Compara SHA-256 antes de cualquier gate de import; compara prefijos, inventaría todas las tablas del destino y exige su aprobación. El flush de caché solo queda autorizado tras confirmar un namespace aislado:

--add-drop-table no elimina tablas extra: solo sustituye las incluidas. No cambies DNS si checksum, backup nuevo, prefijo, inventario de tablas, URLs, caché aislada, reconciliación de archivos eliminados o monitor de barrera fallan. Repite las pruebas críticas con bypass controlado; la barrera durable sigue cubriendo ambos servidores.

Reduce el riesgo del corte DNS

Baja el TTL antes de la migración y espera al menos el TTL anterior para que el cambio tenga efecto en cachés nuevas. La guía de preparación DNS de Cloudflare describe este principio. Un TTL bajo acorta la vigencia de respuestas futuras; no borra respuestas ya almacenadas ni garantiza un instante de cambio global.

Si conservas el mismo DNS autoritativo, normalmente basta con cambiar A y, si existe, AAAA. Un AAAA antiguo puede enviar usuarios IPv6 al servidor anterior aunque A ya apunte al nuevo. Cambiar nameservers implica reproducir toda la zona —incluidos MX, TXT y validaciones— y coordinar DNSSEC: un registro DS en el registrador que no corresponda con las claves de la nueva zona puede producir SERVFAIL. Consulta cómo funcionan DNS, registros y TTL antes de cambiar delegación.

El corte es go solo si: backup y rollback están disponibles; la barrera durable cubre origen y destino y su monitor está sano; todos los writers están pausados; checksum e import son válidos; destino, TLS e integraciones críticas están aprobados; A y AAAA están definidos; TTL preparado; DNSSEC y correo inventariados; y responsables presentes. Cambia únicamente los registros previstos, guarda su valor anterior y anota la hora.

Haz las consultas desde varios resolvers y redes. El resultado de tu equipo no representa a todos los visitantes. Mantén la barrera en ambos servidores mientras las cachés mezclan respuestas; una solicitud que alcance el origen no debe poder crear una rama de datos.

Activa los procesos del destino exactamente una vez

Cuando DNS y el tráfico observado ya correspondan al destino, mantén todavía cerradas las escrituras públicas. Con el runbook ensayado del stack, activa una sola instancia de cron, workers, consumidores de colas, webhooks y correo entrante/saliente en el destino. Comprueba heartbeat del scheduler, propietario del lock, consumo de una cola de prueba, un webhook idempotente y entrega controlada de correo; confirma a la vez que esos procesos siguen detenidos en el origen.

Solo después de esa verificación retira la barrera del destino mediante el control aprobado, conserva la del origen y ejecuta un canary transaccional trazable. Este bloque coordina gates; no pretende conocer los comandos de tu proveedor, supervisor o aplicación:

Monitoriza la migración y valida SEO

Durante el periodo de observación, compara tráfico y logs del origen y destino, tasa de 5xx, latencia, errores PHP, conexiones de base, colas, cron, webhooks, correos, pedidos y formularios. Conserva una forma inequívoca de saber qué servidor respondió, por ejemplo mediante logs o una cabecera interna no cacheada; no muestres detalles sensibles al público.

La guía de Google para cambiar de hosting sin cambiar URLs recomienda preparar y probar el nuevo alojamiento, actualizar DNS y monitorizar el tráfico. Comprueba que las URLs mantienen sus códigos, canonical, robots y sitemap, que no apareció un noindex del staging y que CDN/caché no sirven errores. No uses la herramienta de cambio de dirección si el dominio no cambió.

Después de estabilizar, mide rendimiento y capacidad contra la línea base. Si hay regresiones, sigue una revisión ordenada como estas comprobaciones para acelerar un WordPress lento. Evita activar varias optimizaciones durante el corte: dificultan atribuir un fallo y volver atrás.

Define un rollback que preserve las escrituras

Activa rollback por criterios acordados: checkout/login inoperable, 5xx sostenidos, corrupción o conexión de base, TLS inválido, integraciones críticas caídas o una desviación de datos que no pueda corregirse dentro del límite.

Siempre, incluso si crees que el destino no recibió escrituras, aplica o confirma primero su barrera durable y pausa todos sus writers antes de evaluar logs, capturar delta o revertir DNS. Conserva el destino cerrado para clientes con DNS cacheado. Si sí recibió pedidos, usuarios o formularios, captura y reconcilia ese delta con un procedimiento probado antes de devolver DNS; apuntar atrás sin reconciliar perdería datos.

Recoge evidencia fechada del bloqueo del destino, writers detenidos, rango de IDs/logs revisado, reconciliación y DNS restaurado. SOURCE_DATA_SAFE solo es válido cuando esos artefactos existen y fueron revisados. Con la barrera del origen aún activa, valida base y aplicación por bypass; reactiva exactamente una instancia de cron, workers, colas, webhooks y correo entrante/saliente en origen, comprueba cero en destino y solo entonces abre el origen. Mantén el destino bloqueado hasta cerrar la incidencia.

Documenta quién autorizó la vuelta, datos reconciliados, evidencia, canaries y clientes que pudieron ver cada origen. Mantén backups, logs y destino fallido para análisis; no sobrescribas evidencia.

Troubleshooting después de mover WordPress

Diagnóstico de fallos frecuentes tras una migración

Cuándo retirar el hosting anterior

No elimines el origen cuando veas la primera respuesta correcta del destino. Espera a que venza el periodo de observación definido según el TTL anterior, el ciclo de negocio y las integraciones demoradas. Confirma que el origen ya no recibe tráfico útil ni webhooks, que los backups nuevos se completan, que una restauración del destino está programada o probada y que métricas y SEO permanecen estables.

Después, revoca accesos temporales, elimina entradas del archivo hosts, actualiza allowlists y documentación, reanuda cron/colas en un solo sitio, restaura el TTL operativo mediante un cambio controlado y verificado, y conserva respaldos según la política. Retira el origen únicamente con autorización y evidencia de que no contiene la única copia de un dato reciente.

Preguntas frecuentes

¿Cuánto tarda migrar WordPress a otro hosting?

Depende del tamaño, velocidad entre servidores, prueba y ventana de escritura. La copia inicial puede ejecutarse sin interrumpir el sitio; el tiempo sensible es el delta, la validación y el corte. Mídelo con un ensayo, no con una promesa genérica.

¿Un plugin evita perder pedidos?

No por sí solo. El paquete refleja un momento. Debes impedir o sincronizar los pedidos creados después, verificar el último identificador y probar pagos, webhooks y correo antes de abrir el destino.

¿Tengo que cambiar los nameservers?

No si mantienes el proveedor DNS actual: suele bastar A/AAAA. Cambiar nameservers amplía el riesgo porque debes reconstruir la zona, correo y DNSSEC.

¿Puedo migrar un multisite con este procedimiento?

Úsalo solo como marco. Multisite, subdominios, domain mapping, redes grandes y tablas personalizadas necesitan inventario, reemplazos y pruebas específicos. Escala la ejecución a un runbook propio.

Una migración segura termina después del corte

Migrar WordPress sin perder datos consiste en controlar el estado, no solo en copiar carpetas. Elige el método, inventaría los escritores, prueba un restore, prepara el destino, ejecuta copia inicial y delta bajo una ventana controlada, valida por hostname, corta DNS y observa. Mantén el origen hasta demostrar que la web, las integraciones, los backups y el SEO funcionan en el nuevo hosting.