El cliente llegó con la decisión ya tomada. Quería migrar toda su infraestructura a AWS. El argumento era sencillo: “ya no queremos preocuparnos de servidores, de actualizaciones, de hardware que se rompe. Queremos que cloud lo resuelva todo”.
Nuestra primera tarea no fue preparar una propuesta de migración. Fue hacer las preguntas que el cliente no se había hecho todavía.
El análisis que cambió la decisión
El entorno del cliente tenía tres sistemas principales con perfiles de uso completamente distintos.
El primero era su ERP: accedido por 80 personas durante el horario laboral, con carga estable y predecible durante todo el año. Sin picos, sin variaciones estacionales, con un patrón de consumo que no cambiaba significativamente de un mes al siguiente.
El segundo era un sistema de reportes operacionales que ejecutaba procesos batch los lunes y viernes, con ejecuciones de dos a tres horas, y permanecía inactivo el resto del tiempo. Carga altamente variable: activo el 15% del tiempo, ocioso el 85%.
El tercero eran herramientas de comunicación interna y gestión de documentos, ya operando en modalidad SaaS sin infraestructura propia que gestionar.
La propuesta de migración total a cloud habría aplicado el mismo enfoque a los tres. El resultado, al modelar los costos con los datos de consumo reales: el ERP en cloud costaría entre dos y tres veces lo que costaba en infraestructura propia bien gestionada, sin ninguna ventaja operacional a cambio. El sistema de reportes, en cambio, era exactamente el tipo de carga para la que el modelo de pago por uso tiene sentido real: paga durante las dos horas que procesa, no por las veintidós restantes.
La conversación difícil
Le dijimos al cliente que migrar el ERP a cloud no tenía justificación técnica ni económica para su volumen y perfil de uso. Que el sistema de reportes era un candidato natural para AWS. Que las herramientas SaaS ya estaban donde debían estar y no requerían intervención.
La recomendación final fue un modelo híbrido: ERP en infraestructura propia con soporte gestionado, sistema de reportes en AWS con arquitectura de costo optimizado, herramientas SaaS sin cambios. El costo total proyectado a 24 meses era significativamente menor que la migración completa. Y el nivel de dependencia de un solo proveedor quedaba distribuido.
Eso no era lo que el cliente esperaba escuchar cuando llegó. Esperaba una propuesta de migración, no un análisis que cuestionara la premisa.
Lo que aprendimos
“Resolver TI de una vez” no es una especificación técnica. Es una emoción. El cliente estaba cansado de lidiar con problemas de infraestructura, con incidentes no resueltos a tiempo, con la sensación de que nadie se hacía responsable de que los sistemas funcionaran. Eso no se resuelve con cloud. Se resuelve con un partner que se hace responsable de la operación.
Esta distinción es importante porque la propuesta fácil habría sido aceptar la premisa del cliente, preparar una migración completa a AWS y ejecutarla. Eso habría generado ingresos a corto plazo. También habría generado un cliente con costos más altos de lo necesario, mayor complejidad operacional y, eventualmente, la percepción de que la decisión no fue bien asesorada.
Preferimos la conversación difícil antes del proyecto a la conversación difícil después. No siempre es cómoda. Siempre es más honesta.
El criterio que aplicamos en este tipo de decisiones
Antes de cualquier recomendación de infraestructura, mapeamos las cargas de trabajo con datos reales de consumo, modelamos el costo total a 24 o 36 meses en cada escenario, y evaluamos el riesgo de dependencia de proveedor. Solo después de eso hay una recomendación.
En este caso, la recomendación fue híbrida. En otros ha sido migración completa a cloud, o consolidación total en on-premise, o mantener el estado actual mientras se resuelven primero problemas de documentación y gestión. Depende del análisis, no de la posición de partida.
Hoy el cliente opera hace más de 6 meses con el modelo híbrido recomendado, con costos dentro del rango proyectado y una operación más clara para el equipo técnico.
