Hace unos años, una empresa de servicios financieros nos pidió que les ayudáramos a revertir una migración a la nube. No pausarlo. No optimizarlo. Vuelve a hacerlo.

Esta no era una empresa nueva en la nube. Llevaban años ejecutando cargas de trabajo nativas en la nube en AWS: nuevas aplicaciones, proyectos de innovación, servicios empresariales críticos construidos desde cero sobre arquitecturas modernas. Esa parte de su camino por la nube estaba funcionando bien.

El problema comenzó cuando decidieron migrar sus entornos de desarrollo y pruebas, docenas de servidores basados en IaaS que llevaban años funcionando on-premises. Contrataron a un socio diferente para la migración. Las cargas de trabajo se aliviaron y se trasladaron con éxito. Los servidores funcionaban en AWS. Por cualquier métrica migratoria, el proyecto fue un éxito.

Luego las operaciones tomaron el control.

El equipo responsable de gestionar esos entornos nunca había recibido formación en operaciones en la nube. Aplicaron las mismas prácticas locales que siempre habían utilizado: ciclos manuales de parcheo, solicitudes de cambio basadas en tickets, paneles de monitorización diseñados para infraestructura estática. Nadie había definido cómo debían cambiar los roles. Nadie había replanteado la respuesta a incidentes para un contexto de nube. Nadie había abordado la cuestión fundamental de quién posee qué cuando la infraestructura ya no está en tu centro de datos.

Ocho meses después, tras persistentes fricciones operativas, costes crecientes, brechas de seguridad que no podían cerrar y un equipo frustrado y abrumado, tomaron la decisión: devolverlo a las instalaciones.

Ese retroceso no fue un fallo tecnológico. La migración había funcionado. Fue un fallo de preparación operativa, y les costó más de un año de esfuerzo y presupuesto sin nada que mostrar.

El punto ciego del segundo día

Este patrón se manifiesta de forma consistente entre interacciones, y no solo afecta a las organizaciones que tienen dificultades con la migración. He visto empresas que ejecutaron migraciones técnicamente sólidas, oleadas bien planificadas, cortes limpios, zonas de aterrizaje que cumplen con la normativa, solo para descubrir seis meses después que los costes de la nube estaban subiendo más allá de las previsiones, la respuesta a incidentes implicaba demasiadas entregas y la postura de seguridad se estaba desviando porque nadie la poseía como práctica continua.

Las organizaciones invierten meses de planificación, un presupuesto significativo y atención ejecutiva en la migración en sí. Organizan talleres de descubrimiento, elaboran casos de negocio, ejecutan evaluaciones de preparación y planifican oleada tras oleada de movimientos de carga de trabajo. El programa de migración cuenta con un equipo dedicado, una estructura de gobernanza y revisiones semanales de comités directivos.

Entonces la migración termina. El equipo del programa se disuelve. El comité directivo pasa a la siguiente iniciativa. Y las cargas de trabajo que fueron cuidadosamente planificadas, probadas y migradas se entregan a un equipo de operaciones que nunca estuvo preparado para ejecutarlas en la nube.

La suposición, a veces explícita pero más a menudo no dicha, es que operar en la nube es como operar en las instalaciones, salvo que los servidores están en otro lugar. Esa suposición es donde comienza el fallo.

Escribí sobre el coste de migrar sin una base en una publicación anterior. Pero este es otro problema. Esa publicación trataba sobre organizaciones que no estaban listas para migrar. Este trata sobre organizaciones que migraron bien y que aún no estaban listas para operar.

La migración tuvo éxito. Las operaciones no. Y la brecha entre esas dos realidades es donde las organizaciones pierden el valor que esperaban que la nube ofreciera.

Cinco músculos operativos que la migración no desarrolla

Las operaciones en la nube requieren capacidades que los programas de migración rara vez desarrollan. No porque los equipos de migración sean negligentes, sino porque las habilidades, procesos y estructuras organizativas necesarias para operar en la nube son fundamentalmente diferentes de las necesarias para llegar allí.

1. Monitorización que entiende el comportamiento nativo de la nube

La mayoría de las organizaciones migran su enfoque de monitorización actual junto con sus cargas de trabajo. Configuraron paneles de CloudWatch que reflejan lo que tenían en Datadog o Nagios. Crean alarmas basándose en los mismos umbrales que usaron en las instalaciones: CPU por encima del 80%, disco por encima del 90%, memoria por encima del 85%.

El problema es que el comportamiento nativo de la nube no sigue patrones locales. Se supone que los grupos de escalado automático deben hacer que la CPU se dispare. Las funciones serverless no tienen memoria persistente que monitorizar. Las bases de datos gestionadas gestionan el almacenamiento de forma diferente a las autoalojadas. La orquestación en contenedores crea y destruye instancias constantemente.

Cuando la monitorización no entiende la plataforma, genera ruido en lugar de señal. Los equipos o bien se ahogan en falsas alarmas y empiezan a ignorarlas, o ponen umbrales tan altos que los problemas reales pasan desapercibidos. Ambos resultados son fallos operativos ocultos tras un panel de control que parece activo.

La monitorización eficaz de la nube comienza con la observabilidad: entender cómo es la «normalidad» para cada carga de trabajo en su contexto nativo de la nube, y luego instrumentar las desviaciones que realmente importan. Eso requiere conocimientos operativos que los proyectos de migración no construyen.

2. Respuesta a incidentes sin la cadena de traspaso

La respuesta a incidentes en las instalaciones suele seguir un modelo escalonado: el NOC detecta el problema, escala al equipo de infraestructura, que escala al equipo de aplicaciones y que escala al proveedor. Cada traspaso añade tiempo, pierde contexto y diluye la responsabilidad.

Las organizaciones que migran sin replantearse la respuesta a incidentes llevan esta cadena de transferencia a la nube. El resultado es lo que describí al principio: una interrupción de cuatro horas por un problema que debería haberse resuelto en treinta minutos, porque las personas más cercanas a la carga de trabajo no tenían la autoridad, el acceso ni la alfabetización operativa para actuar.

La respuesta a incidentes en la nube funciona cuando el equipo que construye el servicio es el responsable de su postura operativa. Eso significa desarrolladores que entiendan la monitorización, rotaciones de guardia que incluyan a las personas que escribieron el código y libros de ejecución que mantienen los equipos que los utilizan. Como exploré en una publicación reciente sobre la cultura DevOps, cambiar de nombre a los equipos no cambia la forma en que responden al fracaso. La propiedad sí.

3. Gestión de Costes como Disciplina Operativa

En entornos locales, los costes de infraestructura son gastos de capital: compras servidores, los deprecias, el equipo financiero entiende el modelo. En la nube, los costes de infraestructura son gastos operativos que cambian cada hora según el uso, la configuración y las decisiones tomadas por los ingenieros individuales.

La mayoría de los programas de migración incluyen un análisis de TCO que proyecta los costes en la nube según la utilización actual. Esa proyección casi siempre es errónea, no porque el análisis fuera malo, sino porque asume un comportamiento estático en un entorno dinámico. En cuanto las cargas de trabajo están activas, los ingenieros empiezan a experimentar, escalar, provisionar nuevos recursos y olvidar limpiar los que ya no necesitan.

Sin FinOps como disciplina operativa, los costes en la nube se desplazan. Las reservas expiran sin renovación. Los entornos de desarrollo funcionan 24/7 cuando se usan 8 horas al día. El almacenamiento se acumula porque nadie es dueño de la póliza del ciclo de vida. La factura crece no porque la nube sea cara, sino porque nadie la gestiona como el sistema vivo y dinámico que es.

Trabajando en organizaciones que van desde startups hasta instituciones financieras reguladas, el patrón es notablemente consistente: las que controlan los costes en la nube son las que tratan la gestión de costes como una práctica operativa continua, no como una revisión trimestral.

4. Postura de seguridad que no se desvía

Los programas de migración suelen incluir un flujo de trabajo de seguridad: diseño de zonas de aterrizaje, segmentación de red, políticas IAM, estándares de cifrado. La postura de seguridad en el momento de la migración suele ser sólida.

Luego se desvanece.

Los ingenieros crean reglas de grupo de seguridad para solucionar problemas de conectividad y se olvidan de eliminarlas. Las políticas de IAM acumulan permisos con el tiempo porque es más fácil añadirlas que auditarlas. No se aplican parches de líneas base definidas durante la migración porque el equipo de operaciones no tiene la automatización implementada. Los nuevos servicios se despliegan sin pasar por la revisión de seguridad que recibieron las cargas de trabajo originales.

La seguridad en la nube no es un estado; Es una práctica. Requiere una evaluación continua de la postura, controles automáticos de cumplimiento y un equipo que trate los hallazgos de seguridad como trabajo operativo, no como preparación para auditorías. Las organizaciones que obtuvieron una postura de seguridad fuerte durante la migración y la perdieron en menos de un año no tuvieron problemas de seguridad. Tenían un problema de disciplina operativa.

5. Gestión de cambios que iguale la velocidad de la nube

La gestión del cambio en las instalaciones fue diseñada para un mundo donde los cambios eran poco frecuentes, de alto riesgo y requerían ventanas de mantenimiento. Las reuniones del CAB, los congelamientos de cambios y las cadenas de aprobación manual tenían sentido cuando un solo despliegue podía afectar a todo el centro de datos.

En la nube, el modelo de despliegue es fundamentalmente diferente. Los cambios en la infraestructura pueden probarse, desplegarse y revertirse en cuestión de minutos. Los servicios pueden actualizarse de forma independiente. Los despliegues azul-verdes y las liberaciones de canarios reducen el riesgo de cambios individuales a casi cero.

Pero las organizaciones que llevan su proceso de gestión del cambio local a la nube crean un cuello de botella que anula una de las principales ventajas de la nube. Reuniones semanales del CAB para cambios que pudieran desplegarse de forma segura en actas. Cadenas de aprobación manuales para cambios de infraestructura como código que ya han sido validados mediante pruebas automatizadas. El cambio congela que bloquea toda la organización porque un equipo tiene un plazo de cumplimiento.

El resultado es que los equipos siguen el proceso y pierden agilidad, o lo evitan y pierden la gobernanza. Ninguno de los dos resultados es aceptable. La gestión del cambio en la nube debe ser automatizada, basada en políticas y lo suficientemente rápida para igualar las capacidades de la plataforma. Eso requiere inversión en Infraestructura como Código, pruebas automatizadas y pipelines de despliegue, capacidades que nuestra experiencia entregando implementaciones de AWS CloudFormation y Control Tower ha demostrado que están consistentemente infrainvertidas durante los programas de migración.

Por qué esto sigue ocurriendo

La razón estructural es sencilla: los programas de migración y los programas de operaciones tienen patrocinadores diferentes, equipos distintos, métricas de éxito distintas y plazos distintos.

El éxito de la migración se mide por las cargas de trabajo trasladadas, los tiempos de inactividad evitados y el cumplimiento del presupuesto. Esas son métricas de proyecto. Tienen una fecha de inicio y otra de finalización. Cuando el proyecto termina, se declara el éxito.

El éxito operativo se mide por la disponibilidad, el tiempo de respuesta a incidentes, la eficiencia de costes, la postura de seguridad y la velocidad de cambio. Esas son métricas continuas. No tienen fecha de finalización. Y requieren una inversión sostenida en personas, procesos y automatización que los presupuestos de migración rara vez incluyen.

Habiendo obtenido tanto la Competencia AWS Cloud Operations como la AWS Migration & Modernization Competency, operamos cada día en ambos lados de esta brecha. El lado migratorio está bien comprendido: existen marcos, herramientas, incentivos financieros y un ecosistema maduro de socios que lo apoyan. El lado operativo es donde las organizaciones se ven obligadas a resolver las cosas por sí mismas, a menudo después de que se gasta el presupuesto de migración y la atención ejecutiva se ha desplazado a otro lugar.

La brecha no es técnica. La nube te proporciona todas las herramientas necesarias para funcionar bien: CloudWatch, Config, Security Hub, Cost Explorer, Systems Manager, EventBridge. La brecha es organizativa. Es la ausencia de una transición deliberada de «nos hemos trasladado a la nube» a «operamos en la nube», con las personas, procesos y prácticas que requiere la transición.

Lo que realmente requiere la preparación operativa

En una publicación anterior esbocé un marco de 90 días para construir la preparación operativa en la nube . Los detalles importan, pero el principio es sencillo: la preparación operativa no es una fase que ocurra después de la migración. Es una capacidad que debe construirse junto a ella.

Eso significa:

Monitorización y observabilidad diseñadas para comportamientos nativos en la nube desde el primer día, no adaptadas tras la primera interrupción. Procesos de respuesta a incidentes que otorgan a los equipos de carga de trabajo propiedad y autoridad, no solo vías de escalada. FinOps se integra como una práctica continua con clara rendición de cuentas, no una revisión trimestral de costes. La gestión de la postura de seguridad es automatizada y continua, no una evaluación puntual. Gestión del cambio que aproveche Infraestructura como Código y pipelines automatizados, no cadenas de aprobación manuales diseñadas para otra época.

Y debajo de todo eso, la dimensión de las personas. La capacidad operativa no es un problema de herramientas. Es un problema de habilidades, un problema cultural y un problema de liderazgo. Las cualidades que hacen que los equipos de operaciones sean efectivos, la disciplina para mantener estándares, la adaptabilidad para aprender una nueva plataforma, la capacidad de actuar sin esperar a la escalada, son las mismas cualidades que definen a los equipos efectivos en todos los contextos. No puedes automatizar el juicio. No puedes migrar de cultura. Tienes que construirlo.

La pregunta que merece la pena hacer

Si tu organización ha completado una migración a la nube, o está en medio de una, aquí está la pregunta que más importa:

Cuando termine el programa de migración, ¿quién será el dueño de la postura operativa de vuestro entorno en la nube? No quién supervisa los paneles. No quién responde a los tickets. ¿Quién es el dueño de la mejora continua de cómo operas, aseguras y optimizas tu nube?

Si la respuesta no está clara, o si la respuesta es «el mismo equipo que gestionó nuestro centro de datos», entonces tu migración puede haber tenido éxito, pero tu camino hacia la nube acaba de comenzar.

Y cuanto más tiempo esperes para desarrollar ese músculo operativo, más difícil se vuelve. Porque, a diferencia de la migración, que es un proyecto con un alcance definido, las operaciones son una disciplina que mejora continuamente o se degrada silenciosamente.

La nube no recompensa a las organizaciones que llegan. Premia a las organizaciones que operan.

Ricardo