Estrategia de migración web: cómo planificar sin interrumpir el negocio

Migrar una web genera más miedo del necesario. El negocio sigue funcionando, los clientes siguen entrando, y la idea de tocar algo que “más o menos funciona” paraliza decisiones que llevan meses pendientes. El problema no es la migración en sí: es hacerla sin un plan que separe las fases de riesgo real de las que simplemente dan vértigo.

Este post detalla una estrategia pragmática para migrar o reconstruir una web con impacto mínimo en el negocio: cómo evaluar si conviene migrar o reconstruir, qué pasos técnicos controlan el riesgo, cómo comunicar el proceso y qué métricas confirman que ha salido bien.

1. Primero: ¿migrar o reconstruir?

No toda situación requiere lo mismo. Confundir los dos escenarios es el primer error que dispara el presupuesto y los plazos.

Migrar implica mover el contenido y la estructura existente a otro servidor, plataforma o dominio, manteniendo en lo posible las URLs, el diseño y el comportamiento actuales. El objetivo es preservar lo que funciona mientras se cambia la infraestructura.

Reconstruir implica partir de cero o de una base nueva: cambiar el stack, el diseño, la arquitectura de información o todo a la vez. El riesgo es mayor porque hay más variables que pueden salir mal simultáneamente.

Señales de que conviene migrar:

• El contenido tiene valor SEO acumulado (posicionamiento, backlinks).
• La estructura de URLs es sana y no necesita cambios.
• El problema es técnico: lentitud, proveedor de hosting, plataforma obsoleta.

Señales de que conviene reconstruir:

• La web ya no representa al negocio ni en diseño ni en mensajes.
• La arquitectura de información está rota y no hay forma de arreglarla por partes.
• El coste de mantener el sistema actual supera el de sustituirlo.

Cuando el diagnóstico no es claro, una auditoría técnica previa permite tomar esa decisión con datos, no con intuición.

2. Evaluación previa: el trabajo que evita sorpresas

Antes de mover una sola línea de código, hace falta una foto completa del estado actual.

Inventario de URLs. Exporta todas las URLs indexadas desde Google Search Console o con un crawler (Screaming Frog, por ejemplo). Identifica qué páginas generan tráfico orgánico, cuáles tienen backlinks externos relevantes y cuáles son simplemente páginas de relleno. Esas son las páginas que no pueden quedar rotas.

Baseline de métricas. Registra los valores actuales de tráfico orgánico, conversión, Core Web Vitals y posicionamiento por keyword. Sin este punto de partida, no hay forma de distinguir después si un bajón de tráfico es consecuencia de la migración o de otro factor.

Mapa de redirects. Para cada URL que vaya a cambiar, necesitas una correspondencia exacta con la nueva URL. Este mapeo uno a uno es el trabajo más tedioso de una migración, pero es también el que más protege el SEO acumulado.

3. DNS: el punto de control más infravalorado

El DNS decide cuándo los usuarios empiezan a ver la nueva web. Gestionarlo bien es lo que separa un corte limpio de horas de caos.

El parámetro clave es el TTL (Time to Live): el tiempo durante el que los servidores intermedios guardan en caché la dirección IP de tu dominio. Si tu TTL está a 24 horas y cambias el servidor, algunos usuarios verán la web antigua durante todo ese día.

La secuencia correcta es escalonada:

• 7 días antes: audita los registros DNS actuales (A, MX, CNAME). Anótalos todos.
• 3 días antes: baja el TTL de los registros A a 3.600 segundos (1 hora).
• 24-48 horas antes: baja el TTL a 300 segundos (5 minutos). A partir de ahí, cualquier cambio propagará en minutos en lugar de horas.
• En el momento del corte: actualiza los registros A al nuevo servidor.
• Después de verificar estabilidad: sube el TTL de vuelta a un valor normal (3.600 o 86.400 segundos).

Mantén el servidor antiguo operativo al menos 24-48 horas después del corte. Una pequeña fracción de resolvers DNS no respeta los TTL correctamente y puede seguir enviando tráfico a la IP antigua durante ese período.

4. Redirects: la arquitectura SEO de la migración

Los redirects 301 son el mecanismo que comunica a Google y a los usuarios que una URL ha cambiado de forma permanente. Sin ellos, cada URL que desaparece es un agujero en el que se pierde autoridad de dominio acumulada durante meses o años.

Reglas operativas:

• Siempre 301, nunca 302 para cambios permanentes. El 302 indica temporalidad y los buscadores retienen la autoridad en la URL antigua.
• Sin cadenas de redirección. Si /pagina-a redirige a /pagina-b que redirige a /pagina-c, el crawl budget se malgasta y la transferencia de autoridad se degrada. Cada redirect apunta directamente al destino final.
• Actualiza los enlaces internos tras la migración. Que los redirects funcionen no significa que sea óptimo depender de ellos para la navegación interna.
• Mantén los redirects activos al menos 12 meses. Es el plazo mínimo recomendado para que Google complete la transferencia de autoridad e indexe correctamente las nuevas URLs.

El error más frecuente no es olvidarse de los redirects, sino olvidarse de las URLs de segundo nivel: páginas de categorías, posts antiguos, páginas de servicios descatalogadas. Son fáciles de pasar por alto y son exactamente donde están los backlinks más valiosos.

5. Entorno de staging y ventana de corte

Ninguna migración debería ejecutarse directamente en producción. El entorno de staging permite detectar problemas antes de que afecten al negocio.

Qué validar en staging antes del corte:

• Que todos los redirects del mapa devuelven 301 y apuntan a la URL correcta.
• Que las páginas principales cargan sin errores JavaScript o de renderizado.
• Que los metadatos (title, description, canonical, schema) son correctos.
• Que el fichero robots.txt y el sitemap XML están listos para producción.
• Que no hay bloques noindex activos que puedan dejar la web invisible tras el lanzamiento.

Cuándo hacer el corte: elige siempre el momento de menor tráfico. Para la mayoría de negocios locales o B2B, eso es entre las 2:00 y las 6:00 de la mañana de un martes o miércoles, lejos de los picos de la semana y de períodos de alta demanda estacional.

6. Plan de roll-back: el botón de emergencia

El roll-back no es una señal de fracaso. Es una decisión de negocio racional cuando la nueva versión introduce un problema que no se detectó en staging.

Un plan de roll-back operativo requiere:

1. Backup completo del sitio antiguo: ficheros, base de datos y configuración del servidor.
2. DNS en TTL bajo antes del corte (el paso que preparaste antes), para poder revertir el apuntamiento en minutos en lugar de horas.
3. Criterios de activación definidos antes del lanzamiento: ¿a partir de qué umbral de errores 500, qué caída de conversión o qué pérdida de tráfico activas el roll-back?
4. Responsable claro con acceso al panel de DNS y al servidor para ejecutarlo sin depender de cadenas de aprobación.

Tener este plan no ralentiza la migración. Al contrario: saber que existe la red de seguridad permite moverse con más velocidad y menos parálisis en el momento del corte.

7. Comunicación con clientes durante el proceso

Una migración bien ejecutada debería ser invisible para los usuarios. Pero conviene comunicarla igualmente, especialmente si hay algún período de mantenimiento planificado.

Lo que funciona:

• Aviso previo breve (24-48 horas antes): “Vamos a actualizar la web esta noche. Si encuentras algún problema puntual, escríbenos a [dirección].”
• Sin exagerar el alcance. No hace falta anunciar “renovación completa” si los cambios no son visibles para el usuario final.
• Página de mantenimiento opcional para el período de corte, con tiempo estimado de vuelta a la normalidad.
• Confirmación posterior si hay cambios visibles en el diseño o la navegación: “Hemos actualizado la web. Todo lo que buscabas sigue en el mismo sitio.”

Lo que genera más fricción que la propia migración es la ausencia de comunicación cuando algo no funciona como se esperaba. Un mensaje rápido vale más que el silencio.

8. Métricas para validar el éxito

El éxito de una migración no se valida el día del corte. Se valida en las semanas siguientes, comparando contra el baseline que registraste antes.

Métricas prioritarias (primera semana):

Indicador	Qué medir	Herramienta
Cobertura de indexación	Páginas indexadas vs. páginas previas	Google Search Console
Errores de rastreo	404s y 500s nuevos	Google Search Console → Cobertura
Tráfico orgánico	Sesiones orgánicas vs. período equivalente	GA4
Core Web Vitals	LCP, CLS, INP en las páginas principales	Search Console → Experiencia
Conversión	Formularios, llamadas, compras	GA4 → Eventos clave

Señales de alerta que requieren acción inmediata:

• Caída de tráfico orgánico superior al 20% sin causa externa identificable.
• Aumento significativo de errores 404 en URLs de alta autoridad.
• Core Web Vitals que empeoran respecto al baseline (especialmente LCP e INP).
• Páginas del sitemap antiguo que no están siendo rastreadas en el nuevo.

Una caída leve de tráfico en las primeras dos semanas es normal durante la re-indexación. Lo que no es normal es una caída sostenida que no se recupera.

Checklist operativo

Antes del corte:

• Inventario completo de URLs con tráfico y backlinks
• Baseline de métricas registrado (tráfico, conversión, CWV, rankings)
• Mapa de redirects 1:1 completado y revisado
• TTL bajado a 300 segundos con 24-48 horas de antelación
• Staging validado: redirects, metadatos, robots.txt, sitemap, noindex
• Plan de roll-back documentado con criterios de activación

En el momento del corte:

• Corte en ventana de bajo tráfico
• Actualización de registros DNS al nuevo servidor
• Verificación inmediata de las páginas principales
• Sitemap actualizado enviado a Google Search Console

Primeras 48 horas:

• Monitorización de errores de rastreo en Search Console
• Verificación de tráfico orgánico en GA4
• Comprobación de que los redirects funcionan en producción
• Servidor antiguo aún activo como red de seguridad

Primera semana:

• Comparativa de Core Web Vitals vs. baseline
• Revisión de conversión en los puntos clave del embudo
• Actualización de enlaces internos para eliminar dependencia de redirects
• TTL DNS restaurado a valor estable (3.600 o 86.400 segundos)

---

Una migración bien planificada no interrumpe el negocio porque el riesgo se distribuye en el tiempo: la preparación lleva semanas, el corte dura horas y el seguimiento asegura que los problemas se detectan antes de que sean costosos. Si estás evaluando si tu web necesita este proceso, puedo revisar el estado técnico actual y darte un diagnóstico claro antes de decidir nada. Puedes escribirme desde aquí.