Una migración técnicamente impecable puede percibirse como un retroceso si el enlace no acompaña. Cuando la aplicación deja de estar en el mismo edificio que el usuario, la red pasa de ser infraestructura invisible a ser parte de la experiencia.
A continuación: por qué la percepción empeora, qué medir antes de mover, qué exige criterio y cómo se dimensiona el enlace.
El patrón es reconocible. La migración termina en plazo, los sistemas responden bien en las pruebas técnicas y aun así los usuarios reportan que "va más lento que antes".
Casi siempre tienen razón, y casi nunca el problema está en la nube: está en el camino que ahora recorren los datos entre el usuario y la aplicación.
Por qué cambia la percepción
Antes, la aplicación y el usuario compartían la red local. La latencia era de microsegundos y el ancho de banda, prácticamente ilimitado para el uso interno.
Después, cada interacción atraviesa el enlace de salida de la organización. Ese enlace se dimensionó para navegación y correo, no para que toda la operación pase por él.
Además, muchas aplicaciones antiguas fueron diseñadas suponiendo una red rápida: hacen muchas llamadas pequeñas en lugar de pocas grandes. Ese diseño era irrelevante en la red local y se vuelve determinante cuando cada llamada cuesta latencia.
Qué medir antes de mover
Latencia hasta la región elegida. No la teórica sino la real, medida desde las sedes donde están los usuarios. La distancia geográfica orienta pero no decide: la ruta del proveedor de internet pesa igual o más.
Volumen de tráfico por aplicación. Cuánto transfiere realmente en un día típico. Es el dato que dice si el enlace actual alcanza o si hará falta ampliarlo antes de mover.
Patrón de conversación de la aplicación. Cuántas llamadas hace para completar una operación de negocio. Una aplicación conversadora sufre con la latencia mucho más de lo que su volumen de datos sugiere.
Dependencias que se quedan. Si la aplicación migrada sigue consultando una base que permanece en el centro de datos, cada operación cruza el enlace dos veces. Ese ida y vuelta es la causa más común de degradación tras una migración parcial.
Lo que exige criterio
La decisión entre salir por internet o contratar una conexión dedicada depende de cuánto importe la previsibilidad. Internet es más económico y su desempeño varía; una conexión dedicada cuesta más y entrega latencia estable.
Para cargas internas de uso constante, la estabilidad suele justificar el costo. Para acceso ocasional o para usuarios remotos dispersos, montar una conexión dedicada resuelve un problema que esos usuarios no tienen.
También hay que decidir sobre la redundancia. Cuando toda la operación depende del enlace, ese enlace se convierte en un punto único de falla, y conviene tratarlo con el mismo criterio que se aplicaría a cualquier otro componente crítico.
Qué cambia con el trabajo distribuido
Cuando los usuarios trabajan desde varias sedes o desde casa, hacer pasar todo el tráfico por la oficina central para salir desde ahí añade un rodeo que la nube no necesita.
La alternativa es permitir la salida directa hacia los servicios en nube desde cada punto, con los controles de seguridad aplicados en el camino en lugar de en la sede.
Es un cambio de arquitectura de red, no un ajuste, y conviene planearlo junto con la migración y no como corrección posterior, porque afecta también dónde se aplican las políticas de seguridad.
Cómo se dimensiona el enlace
Parta del tráfico medido, no del número de usuarios. Dos organizaciones del mismo tamaño pueden tener perfiles de consumo muy distintos según qué aplicaciones usen.
Considere el pico, no el promedio. Un enlace dimensionado al promedio funciona bien la mayor parte del día y se satura exactamente cuando más se necesita, que suele ser el cierre o el inicio de jornada.
Y prevea crecimiento. Cada carga que se migra después suma tráfico al mismo enlace, así que el dimensionamiento debería contemplar el plan completo de migración y no sólo la primera ola.
Qué se necesita antes
Mediciones reales de latencia y volumen desde las sedes de usuarios, un inventario de dependencias entre aplicaciones y claridad sobre el orden de migración.
La segunda es la que más sorpresas produce. El mapa de qué habla con qué rara vez está documentado, y es justamente el que determina si una migración por partes va a funcionar o a degradarse.
Qué hacer cuando ya ocurrió
Si la migración ya se hizo y la percepción es de lentitud, conviene resistir la reacción inmediata de ampliar el enlace. A veces es la respuesta correcta y a menudo es cara e insuficiente.
El primer paso es separar latencia de saturación. Si el enlace está lejos de su capacidad y aun así la experiencia es mala, el problema es de latencia y de diseño de la aplicación, no de ancho de banda: ampliar no cambiará nada.
Si en cambio el enlace se satura en franjas concretas, el diagnóstico es de capacidad y admite dos caminos: ampliar o mover tráfico fuera del pico, empezando por los procesos por lotes que pueden ejecutarse de madrugada.
¿Por qué los usuarios perciben lentitud tras migrar?
Porque el tráfico que antes viajaba por la red local ahora atraviesa el enlace de salida, dimensionado para navegación y correo. Las aplicaciones que hacen muchas llamadas pequeñas lo notan más.
¿Cuándo se justifica una conexión dedicada?
Cuando la previsibilidad importa: cargas internas de uso constante y sostenido. Para acceso ocasional o usuarios dispersos suele resolver un problema que no existe.
¿Qué causa la degradación en migraciones por partes?
Las dependencias que se quedan atrás. Si la aplicación migrada consulta una base que permanece en el centro de datos, cada operación cruza el enlace dos veces.
¿Sobre qué cifra conviene dimensionar?
Sobre el pico medido, no el promedio, y contemplando el plan completo de migración. Un enlace ajustado al promedio se satura justo cuando más se necesita.
