Migración y Cambio de Hosting o Agencia en WordPress

Cambiar de hosting o de agencia genera el mismo vértigo que mudarse de casa: sabes que a largo plazo puede ser mejor, pero el proceso en sí da miedo. ¿Y si se pierde el posicionamiento ganado? ¿Y si la web se cae durante horas? ¿Y si algo se rompe y nadie sabe cómo arreglarlo?

En Avantys hemos migrado cientos de webs WordPress, tanto por decisión proactiva del cliente como por emergencias donde el proveedor anterior desapareció sin previo aviso. Esta guía cubre ambos escenarios: la migración planificada y bien hecha, y la migración forzada por una situación que ya no da más de sí. Es la guía-paraguas de la rama de migración: cada apartado enlaza a la pieza que lo desarrolla en detalle.

Si vienes buscando el panorama general del clúster, el punto de partida es Por Qué WordPress Va Lento (y Cómo Gestionarlo Bien).

Por qué una migración mal hecha puede costarte el posicionamiento

Cuando cambias de hosting o de estructura de URLs sin cuidado, Google puede interpretar la nueva ubicación como contenido distinto en lugar de el mismo contenido movido de sitio. Esto puede traducirse en una caída temporal (o no tan temporal si se hace realmente mal) de tu posicionamiento en buscadores.

El mecanismo importa para entender por qué pasa. Google mantiene un mapa de tu web (qué URLs existen y cuánta autoridad ha acumulado cada página) que reconstruye cada vez que rastrea. Si al volver encuentra errores 404 donde antes había contenido, redirecciones mal encadenadas o páginas lentas, esa autoridad acumulada no se transfiere sola.

Los errores más comunes que provocan esta pérdida:

• Cambiar las URLs sin dejar redirecciones 301 (permanentes) desde las antiguas hacia las nuevas. Una 302 (temporal) no transmite autoridad igual: para una migración definitiva, la redirección correcta es 301.
• Un periodo de indisponibilidad prolongado durante la migración, que Google puede interpretar como una señal negativa si se repite o se extiende demasiado.
• Perder metadatos SEO (títulos, descripciones, datos estructurados) durante el traslado de contenido, algo típico cuando se copia el contenido a mano en vez de mover la base de datos entera.
• No actualizar el archivo sitemap.xml ni notificar a Google Search Console del cambio.
• Dejar el nuevo entorno abierto a indexación mientras se prueba: si Google rastrea la URL temporal de pruebas, puedes acabar con contenido duplicado compitiendo contra tu propio dominio.

En la mayoría de migraciones bien hechas el dominio no cambia y las URLs se conservan tal cual, y entonces el riesgo SEO es mínimo. El problema aparece cuando se aprovecha la mudanza para “rehacer” también la estructura de enlaces sin un plan de redirecciones. Nuestro consejo: una cosa cada vez. Primero muevas la web idéntica, verificas que todo funciona, y solo después (si hace falta) rediseñas URLs con su mapa de redirecciones.

El proceso técnico correcto de migración

Antes de mover nada

1. Haz un backup completo y verificado de la web actual (archivos y base de datos). “Verificado” significa que lo has descargado y abierto, no solo que el plugin dijo “hecho”. La mecánica de copiar y restaurar bien está en Backups de WordPress: qué copiar y con qué frecuencia.
2. Documenta la estructura completa de URLs existente, necesitarás esta lista para configurar redirecciones si algo cambia. Un rastreo con cualquier herramienta tipo crawler te da el listado en minutos.
3. Prepara el nuevo entorno de destino (hosting, dominio) sin apuntar aún el tráfico real ahí.
4. Anota las versiones del entorno actual: versión de PHP, de MySQL/MariaDB y de WordPress. Migrar a un PHP más moderno suele ser bueno, pero conviene saber de dónde partes para no llevarte sorpresas con un plugin viejo.

Durante la migración

1. Copia archivos y base de datos al nuevo entorno.
2. Actualiza las referencias de URL en la base de datos si el dominio cambia. Aquí está el gotcha que rompe más migraciones caseras: WordPress guarda muchos datos serializados (arrays de PHP con la longitud de cada cadena embebida). Un buscar-y-reemplazar a lo bruto sobre el volcado SQL corrompe esos datos porque cambia el texto pero no el contador de longitud. La forma segura es una herramienta consciente de la serialización, como WP-CLI:

wp search-replace 'https://dominioviejo.com' 'https://dominionuevo.com' --all-tables --precise

3. Prueba la web completa en el nuevo entorno usando una URL temporal o modificando temporalmente tu archivo hosts local, sin afectar aún al tráfico real de visitantes. En Linux o macOS es una línea en /etc/hosts:

203.0.113.10   dominio.com www.dominio.com

Así solo tu ordenador ve el nuevo servidor mientras el resto del mundo sigue en el viejo. Recuerda quitar esa línea al terminar.

4. Verifica exhaustivamente: contenido, formularios, checkout si hay tienda, correos de contacto, y velocidad de carga en el nuevo entorno.
5. Bloquea la indexación del entorno de pruebas mientras lo validas (con protección por contraseña o un noindex temporal) para que Google no rastree la URL provisional.

El cambio de DNS: el momento de mayor riesgo

Cuando apuntas el dominio al nuevo servidor, existe un periodo de propagación DNS (generalmente de minutos a horas) durante el cual distintos visitantes pueden ver la versión antigua o la nueva según la configuración de caché DNS de su proveedor. Para minimizar el impacto:

• Reduce el TTL (tiempo de vida) de los registros DNS con antelación (normalmente uno o dos días antes), bajándolo a un valor pequeño para que la propagación sea casi inmediata cuando llegue el momento. Si lo bajas justo al cambiar, no sirve: los resolvers ya tienen cacheado el TTL antiguo.
• Programa el cambio en horas de bajo tráfico.
• Mantén el entorno antiguo encendido y sincronizado durante todo el periodo de propagación, para que quien todavía resuelva la IP vieja siga viendo una web funcional y no pierdas ningún pedido o formulario enviado en ese margen.
• Comprueba la propagación real desde tu máquina antes de cantar victoria:

dig +short dominio.com

Si devuelve la IP nueva, tu resolver ya ha propagado.

Migrar de hosting compartido a gestionado: la transición más habitual

Esta es la migración más común entre nuestros clientes: pasar de un hosting compartido genérico a un hosting administrado o a gestión profesional de WordPress. Las diferencias técnicas a anticipar:

• Versión de PHP posiblemente distinta, que puede requerir verificar compatibilidad de plugins antes del cambio.
• Configuración de caché diferente (muchos hostings administrados usan LiteSpeed con LSCache, que requiere desactivar cualquier plugin de caché anterior para evitar conflictos).
• Límites de recursos distintos (memoria PHP, tiempo de ejecución) que pueden requerir ajustes si el hosting anterior tenía configuraciones muy permisivas.
• Reglas de reescritura y .htaccess: si vienes de Apache y aterrizas en un stack distinto, algunas reglas personalizadas pueden necesitar traducción.

Elegir bien el destino es la mitad del trabajo: los criterios están en Cómo elegir el hosting adecuado para que WordPress no vaya lento.

Casos límite que complican una migración

No todas las webs se mueven igual de fácil. Los escenarios donde conviene extremar el cuidado:

• Tiendas WooCommerce en activo. El riesgo no es solo SEO, son los pedidos. Si alguien compra durante la ventana de migración, ese pedido puede quedar registrado en el entorno viejo y perderse al cambiar el DNS. La forma limpia es congelar la tienda unos minutos (modo mantenimiento) durante el corte final, o migrar en la franja de menos ventas y reconciliar pedidos después.
• Bases de datos grandes. Millones de filas (histórico de pedidos, revisiones acumuladas, logs de plugins) hacen que el volcado tarde y a veces supere límites de importación. Limpiar la base de datos antes de migrar reduce mucho el tiempo de corte.
• Bibliotecas de medios enormes. Miles de imágenes tardan en transferirse. Conviene sincronizar la carpeta uploads por adelantado y hacer solo una sincronización incremental en el momento del corte.
• Multisite. Una red multisitio guarda las URLs de cada subsitio en varias tablas; el reemplazo debe abarcarlas todas o algún subsitio quedará apuntando al dominio viejo.
• Correo en el mismo servidor. Si el hosting de origen también gestiona el correo del dominio, mover el registro MX sin plan puede dejarte sin recibir emails. Trátalo como una migración aparte, no como un daño colateral del cambio de hosting.

Cuándo la migración no es una decisión, sino una emergencia

No todas las migraciones se planifican con calma. A veces el motivo es que tu agencia o desarrollador ha dejado de responder, ha cerrado, o simplemente ya no puedes contar con ellos. Este escenario tiene sus propios retos:

• Puede que no tengas acceso completo (credenciales de hosting, dominio, panel de WordPress) si dependías completamente de esa agencia.
• El conocimiento sobre personalizaciones específicas de tu web puede perderse si nadie documentó cómo se construyó.
• La urgencia suele ser mayor, dejando menos margen para una migración cuidadosa paso a paso.

Profundizamos en cómo actuar en este escenario concreto en Qué Hacer Cuando tu Agencia WordPress Desaparece, incluyendo cómo recuperar el control de tu propia web cuando dependías completamente de un tercero.

Señales de que necesitas cambiar de proveedor antes de que sea una emergencia

Mejor anticiparse que esperar a la crisis. Señales que conviene tomar en serio:

• Tiempos de respuesta de soporte cada vez más largos o inexistentes.
• Incrementos de precio sin mejora correspondiente de servicio.
• Incidencias técnicas recurrentes sin explicación clara ni solución definitiva.
• Falta de transparencia sobre qué se hace realmente con tu web (actualizaciones, backups, seguridad).

Hemos desarrollado cada una de estas banderas rojas, con cómo distinguir un bache puntual de un patrón de fondo, en Señales de que necesitas cambiar de agencia o proveedor de WordPress.

Qué preguntar antes de elegir el nuevo destino

Antes de migrar, verifica con el nuevo proveedor de hosting o gestión:

• ¿Ofrecen ayuda o incluyen el proceso de migración en el servicio, o es responsabilidad exclusiva del cliente?
• ¿Qué garantías dan sobre tiempo de inactividad durante el cambio?
• ¿Cómo gestionan la portabilidad si en el futuro decides cambiar de nuevo?
• ¿Tienes acceso real (SSH, gestor de archivos, phpMyAdmin) o dependes de pedirles todo por ticket?

La lista completa de preguntas (y qué respuesta debería encender una alarma) está en Qué preguntar antes de migrar tu WordPress a un hosting gestionado.

Hacerlo tú mismo o delegar: comparativa honesta

Aspecto	Migración por tu cuenta	Migración gestionada
Coste directo	Bajo o nulo	Incluido o de pago
Riesgo de datos serializados corruptos	Alto si no usas WP-CLI	Bajo
Tiempo de inactividad	Variable, depende de tu soltura	Minimizado con pruebas previas
Manejo de casos límite (tienda, multisite)	Complejo sin experiencia	Cubierto
A quién reclamas si algo sale mal	A ti mismo	Al proveedor
Ideal para	Webs sencillas, sin tienda, dominio que no cambia	Webs con tráfico, ventas o alto valor

No hay una respuesta única: una web informativa pequeña, con el mismo dominio y sin tienda, es perfectamente migrable por su dueño; una tienda con pedidos entrando cada hora es otra historia.

Cuándo esta guía se queda corta

Migrar no siempre es la respuesta. Antes de mover nada, conviene descartar que el problema esté en la propia web y no en el servidor: si tu WordPress va lento por plugins mal optimizados o una base de datos hinchada, migrarlo a otro hosting solo cambia de sitio el problema. Y si el motivo para migrar es un conflicto de acceso con tu proveedor actual, la parte técnica es la fácil, lo difícil es recuperar el control, y eso lo tratamos en la guía del WordPress huérfano.

Checklist completo de migración

• Backup completo y verificado antes de empezar
• Documentación de la estructura de URLs actual
• Versiones de PHP, base de datos y WordPress anotadas
• Entorno de destino preparado y probado antes de apuntar el tráfico real
• Entorno de pruebas bloqueado a la indexación
• TTL de DNS reducido con uno o dos días de antelación
• Reemplazo de URLs hecho con herramienta consciente de la serialización (WP-CLI)
• Verificación exhaustiva en el nuevo entorno antes del cambio de DNS
• Redirecciones 301 configuradas si cambian las URLs
• Entorno antiguo mantenido encendido durante toda la propagación
• Sitemap actualizado y notificado a Google Search Console tras el cambio
• Monitorización del posicionamiento en las semanas posteriores a la migración

Preguntas Frecuentes

¿Cuánto tiempo de inactividad es normal durante una migración bien planificada? Con el proceso correcto (probando en el nuevo entorno antes de cambiar el DNS), el tiempo de inactividad real puede reducirse a minutos o incluso evitarse por completo.

¿Perder posicionamiento tras una migración es inevitable? No, si se mantienen las mismas URLs o se configuran redirecciones adecuadas y no hay un periodo largo de indisponibilidad. Una migración bien hecha no debería afectar significativamente al SEO.

¿Necesito avisar a Google antes de migrar? No es necesario avisar previamente, pero sí actualizar el sitemap y verificar en Search Console tras la migración que todo se ha indexado correctamente en la nueva ubicación.

¿Puedo migrar yo mismo sin ayuda técnica? Es posible con las herramientas adecuadas (plugins de migración, WP-CLI), pero el margen de error aumenta sin experiencia previa, especialmente en el manejo de la base de datos y el cambio de DNS.

¿Qué hago si mi agencia anterior no me da acceso a nada? Contacta directamente con tu proveedor de hosting y con el registrador de tu dominio, como titular del dominio y, normalmente, del contrato de hosting, tienes derecho a recuperar el control, aunque el proceso pueda requerir verificación de identidad.

¿Cuánto tarda una migración completa de principio a fin? Depende del tamaño de la web, pero para una instalación de tamaño medio bien planificada, el proceso técnico suele completarse en unas horas, sin contar el tiempo de verificación previa.

¿Debo migrar en fin de semana para minimizar el impacto? Puede ayudar si tu tráfico es mayoritariamente entre semana, pero lo más importante es elegir un momento de bajo tráfico específico para tu web, no necesariamente el fin de semana en general.

¿Qué pasa con mis backups anteriores tras la migración? Deberían conservarse durante un periodo razonable tras la migración, por si necesitas volver atrás o recuperar algo que no se trasladó correctamente.

¿Los plugins de migración automática valen para cualquier web? Funcionan bien para webs pequeñas y medianas sin demasiada complejidad. En sitios grandes, con tiendas activas o bases de datos muy pesadas, suelen toparse con límites de tamaño de importación o de tiempo de ejecución, y ahí el traslado manual con WP-CLI da más control.

¿Debo cancelar el hosting antiguo justo después de cambiar el DNS? No. Conviene mantenerlo activo al menos hasta que la propagación se haya completado del todo y hayas confirmado durante unos días que la web nueva funciona sin incidencias. Cancelar demasiado pronto es una de las formas más habituales de perder datos.

Conclusión

Migrar WordPress de hosting o de agencia no tiene por qué ser el proceso arriesgado que muchos temen, con preparación, pruebas previas al cambio de DNS, y un checklist claro, el riesgo de perder posicionamiento o sufrir indisponibilidad prolongada se reduce drásticamente. Y si la migración te la impone una emergencia, hay un camino claro para recuperar el control.

Si prefieres no gestionar tú mismo este proceso, en Avantys lo llevamos como parte de Gestión WordPress, coordinando con tu hosting actual o migrando a nuestra infraestructura sin sorpresas.

Artículos relacionados

• Cómo migrar WordPress a otro hosting sin perder SEO ni tiempo de actividad
• Señales de que necesitas cambiar de agencia o proveedor de WordPress
• Qué preguntar antes de migrar tu WordPress a un hosting gestionado
• Qué hacer cuando tu desarrollador o agencia desaparece
• Cómo elegir el hosting adecuado para que WordPress no vaya lento

---