Cambiar una web no consiste en copiar archivos a otro servidor y cruzar los dedos. Una guía de migración web empresarial debe tratar el proyecto como lo que es: un cambio de infraestructura que puede afectar al posicionamiento, los formularios, las ventas, la analítica y la confianza de quien entra en la web. Si el negocio depende de su canal digital, improvisar sale caro.

La buena noticia es que la mayoría de los problemas evitables tienen un origen bastante conocido: falta de inventario, pruebas hechas a medias y responsabilidades poco claras. Con una planificación realista, una migración puede mejorar rendimiento, seguridad y capacidad de crecimiento sin convertir el lanzamiento en una noche larga.

Qué incluye una migración web empresarial

Una migración puede ser un cambio de hosting, de dominio, de CMS o de plataforma ecommerce. También puede combinar varios de esos cambios a la vez. Cuantos más elementos se mueven, mayor es el riesgo y más importante resulta separar las tareas.

Por ejemplo, trasladar una web corporativa de un servidor antiguo a una infraestructura bien configurada no exige el mismo proceso que pasar una tienda con miles de productos a una nueva plataforma. En ecommerce hay pedidos, clientes, stock, métodos de pago, reglas fiscales, automatizaciones de email y conexiones con logística. Perder una sola pieza puede causar más daño que una página lenta.

También conviene distinguir entre rediseño y migración. A menudo se aprovecha el cambio técnico para modificar contenidos, URLs y estructura. Puede tener sentido, pero juntar demasiadas decisiones hace más difícil detectar qué ha fallado. Si hay presupuesto y tiempo, lo más seguro es conservar lo que ya funciona mientras se introduce el cambio necesario.

Antes de mover nada: definir alcance y responsables

El primer documento no debería ser una lista de plugins ni una fecha de lanzamiento. Debe explicar qué se migra, qué no se migra, por qué se hace y quién valida cada parte. Parece básico, pero evita el clásico mensaje de “pensábamos que eso también entraba”.

Definid el objetivo principal. Puede ser reducir costes de alojamiento, resolver problemas de velocidad, cambiar una plataforma que limita al equipo o preparar la web para crecer en varios mercados. Ese objetivo ayuda a decidir qué concesiones son aceptables. Un cambio urgente de servidor puede requerir conservar el diseño actual; un rediseño completo permite replantear la arquitectura, pero necesita más control SEO.

En una empresa pequeña, una sola persona puede coordinar marketing, contenidos y proveedores. No pasa nada, siempre que haya una persona responsable de aprobar el resultado. El equipo técnico no debería decidir por su cuenta qué páginas comerciales se eliminan, y marketing no debería publicar sin validar los elementos críticos de la plataforma.

Crear un inventario que sirva para tomar decisiones

Antes de construir el entorno nuevo, hay que saber qué existe. No basta con mirar el menú principal. Hay que rastrear las URLs indexables, identificar las páginas con tráfico y conversiones, revisar recursos descargables, formularios, integraciones y cuentas de correo relacionadas.

El inventario debería recoger al menos la URL actual, su destino futuro, el título y la descripción SEO, el estado de indexación, el tráfico orgánico, los enlaces internos relevantes y si genera contactos o ventas. Para una tienda, añadid categorías, productos, variantes, imágenes, cuentas de cliente, cupones, pedidos e impuestos.

Este trabajo revela páginas olvidadas que siguen captando tráfico o landings de campañas que no aparecen en la navegación. Eliminarlas sin alternativa puede borrar resultados de meses de trabajo. Si una página deja de tener sentido, se redirige a la opción más cercana. Redirigir todo a la página de inicio no arregla el problema: solo lo disimula.

Proteger SEO, medición y datos desde el inicio

El posicionamiento no se conserva por arte de magia al publicar una web nueva. Los buscadores necesitan entender que una URL anterior tiene una equivalente nueva, que el contenido relevante continúa disponible y que la estructura sigue siendo coherente.

Preparad un mapa de redirecciones 301 URL por URL. Debe incluir páginas, categorías, fichas de producto y recursos que hayan recibido enlaces o visitas. Una redirección correcta lleva a una página que responde a la misma intención. Si una categoría de zapatillas desaparece, enviar al usuario a la categoría deportiva correspondiente suele ser razonable; enviarlo a la portada, no tanto.

Mantened, cuando sea posible, las URLs que ya funcionan. Cambiarlas solo para que parezcan más bonitas suele generar trabajo extra y riesgo innecesario. Si la nueva plataforma obliga a otra estructura, el mapa de redirecciones pasa a ser una pieza central del proyecto.

La medición merece el mismo cuidado. Verificad que las etiquetas de analítica, conversiones publicitarias, consentimiento de cookies, píxeles y eventos de ecommerce estén instalados en el entorno de pruebas. Si se publican sin medir compras, formularios o llamadas, el equipo pierde visibilidad justo cuando necesita detectar anomalías.

Con los datos ocurre algo parecido. Hay que decidir qué se exporta, en qué formato, cómo se valida y qué información no debe trasladarse. En algunos casos, migrar historiales completos de pedidos aporta valor operativo. En otros, basta con conservarlos de forma segura fuera de la nueva plataforma. Depende de las necesidades de atención al cliente, contabilidad y protección de datos.

Construir y probar en un entorno separado

La nueva web debe prepararse en un entorno de staging o preproducción, nunca directamente sobre la versión pública. Ese entorno permite revisar funcionalidades, contenidos y rendimiento sin afectar a clientes ni a la indexación.

No debe ser accesible para buscadores. Se puede proteger con acceso restringido y configurar adecuadamente la no indexación mientras se trabaja. Al publicar, esas restricciones deben retirarse de forma controlada. Dejar un bloqueo activo es una de esas incidencias pequeñas que se convierten en un problema grande unos días después.

Qué validar antes de la publicación

Las pruebas no consisten solo en comprobar que la portada carga. Conviene recorrer los procesos reales del negocio y asignarles una persona responsable. Antes del cambio, verificad como mínimo:

  • Navegación, buscador interno, menús, filtros y enlaces internos.
  • Formularios, recepción de emails, descargas, calendarios y automatizaciones.
  • Registro, recuperación de contraseña, compra, pago, facturas y correos transaccionales.
  • Redirecciones, etiquetas de analítica, consentimiento, sitemap y reglas de indexación.
  • Rendimiento en móvil, certificados SSL, copias de seguridad y acceso al panel de administración.

En ecommerce, realizad pedidos de prueba con los métodos de pago disponibles y revisad el recorrido completo: pedido recibido, descuento aplicado, stock actualizado, email enviado y preparación logística. Una pasarela que funciona en pruebas técnicas pero no confirma el pedido en producción no es un detalle menor.

También es buen momento para probar la carga en móvil con una conexión normal, no solo en la red de oficina. Una web puede parecer rápida al equipo interno y frustrante para un usuario con cobertura irregular. El rendimiento afecta a la conversión, pero también al trabajo diario: una administración lenta acaba costando horas cada semana.

Planificar el día de la migración

El lanzamiento necesita una ventana de trabajo, un plan de reversión y un canal de comunicación claro. Elegid un momento de menor actividad, aunque no os engañéis: para una tienda que vende todos los días nunca habrá una hora completamente inocua. La cuestión es reducir el impacto y preparar una respuesta rápida.

Antes del cambio, bajad el TTL de DNS con antelación si vais a modificar registros. Haced una copia de seguridad verificable de la web, la base de datos, los correos relevantes y la configuración actual. No basta con que exista una copia: hay que saber dónde está y cómo restaurarla.

Durante la publicación, evitad cambios de contenido no esenciales. El equipo debe centrarse en activar la nueva infraestructura, comprobar el certificado, confirmar redirecciones y realizar un recorrido de usuario. Si aparecen errores críticos, el plan de reversión debe ser una decisión operativa, no una discusión improvisada.

Un buen criterio es definir por adelantado qué se considera crítico. Por ejemplo, que no se pueda comprar, que fallen formularios de captación, que la web devuelva errores generalizados o que se pierdan datos. Un pequeño ajuste visual puede esperar. Un checkout roto, evidentemente, no.

Las primeras semanas deciden si la migración ha salido bien

Publicar no cierra el proyecto. Durante los primeros días hay que vigilar errores 404, respuestas del servidor, conversiones, indexación, velocidad y mensajes de usuarios. Comparad las métricas con la línea base tomada antes de migrar, no con una impresión subjetiva de que “parece que todo va bien”.

Es normal que algunas señales SEO fluctúen durante un cambio relevante. Lo que no es normal es una caída sostenida sin investigar causas. Revisad redirecciones, etiquetas canonical, reglas de bloqueo, sitemaps, enlaces internos y cambios accidentales en contenido clave. Cuanto antes se detecte el fallo, menos páginas y ventas quedan afectadas.

También conviene documentar incidencias y mejoras pendientes. La migración suele dejar al descubierto procesos que nadie había revisado: formularios que llegan a un buzón abandonado, permisos excesivos, plugins sin uso o páginas que no aportan nada. Corregirlo convierte el traslado en una mejora de infraestructura, no solo en un cambio de dirección.

Una web empresarial no necesita estar perfecta para evolucionar, pero sí debe estar controlada. Si el proyecto tiene inventario, pruebas reales, responsables definidos y seguimiento posterior, la migración deja de ser un salto de fe. Se convierte en una base técnica desde la que marketing, ventas y operaciones pueden trabajar con menos fricción.