Llevamos varios años haciendo migraciones de MPLS a SD-WAN sobre Fortinet. El patrón es repetible cuando se respeta una secuencia ordenada y deja de serlo cuando se intenta acortar pasos. Este es el playbook que usamos hoy en clientes con 50 a 200+ sucursales.
1. Inventario, no diseño
Antes de decidir topología hay que tener un inventario verificado: enlaces contratados, anchos de banda reales (no facturados), latencia y pérdida medidas, dispositivos legacy, servicios críticos por sitio y ventanas operacionales aceptables.
El error común: empezar a diseñar la solución antes de saber qué hay realmente en piso. El inventario suele tomar 2 a 4 semanas si se hace bien.
2. Diseño orientado a aplicación
SD-WAN sólo es útil si las decisiones de ruteo se basan en la aplicación, no en el subnet. Eso requiere clasificación clara: ¿qué aplicaciones son críticas, cuáles toleran latencia, cuáles requieren retorno por data center por compliance?
En FortiGate esto se traduce en internet-service-id y políticas de
priorización. Se documenta antes de tocar producción.
3. Lab y validación
Cada cliente tiene su propio combo de aplicaciones, idiosincrasias de proveedor y dependencias legacy. Lab pre-producción con FortiManager mock, plantillas de configuración y simulación de cutover usando un sitio piloto.
Cualquier cambio que vaya a producción primero pasa por lab. Si no se puede reproducir, no se aprueba.
4. Cutover por sitio, no big bang
Migrar 50 sitios el mismo fin de semana es una mala idea. La cadencia que nos funciona: 2-5 sitios por semana, con ventana coordinada por sitio y un plan de rollback validado en lab.
Sitios piloto primero (con tráfico bajo y operación tolerante), luego sitios medios, luego corporativo. Si en algún paso aparece un problema imprevisto, se pausa la cadencia y se diagnostica antes de continuar.
5. Visibilidad desde el día uno
FortiManager y FortiAnalyzer en cliente desde el primer cutover. Nada de "ya en producción miramos cómo se comporta". Si el primer sitio migrado no tiene visibilidad continua, el segundo se va a ciegas.
6. Hand-off operacional
La migración no termina en el último sitio. Termina cuando el equipo de operación (interno o BITS NOC) tiene runbooks por aplicación, contactos del cliente, criterio de escalación y un mes de operación sin sorpresas.
Ese mes es parte del proyecto, no un costo escondido posterior.
Lo que típicamente se rompe
- DNS interno con dependencias entre sitios.
- Aplicaciones que asumen latencia MPLS y fallan en RTT vía Internet.
- Reglas de firewall heredadas con direcciones IP cableadas.
- Aplicaciones de voz que requieren QoS específico no traducido al nuevo diseño.
Detectarlo en lab cuesta horas; detectarlo en producción cuesta días y crisis.
Para terminar
SD-WAN no es magia. Es disciplina de proyecto sobre una herramienta que permite hacer cosas que MPLS no permitía. La migración bien hecha mejora la operación; la migración apresurada agrega complejidad sin beneficio.