Recientemente estuve trabajando con una empresa de servicios financieros en un proyecto de migración a la nube. El alcance era significativo: más de 180 servidores, múltiples aplicaciones críticas para el negocio y requisitos regulatorios estrictos. Sobre el papel, parece una migración empresarial estándar.

Pero había un problema, uno que ya había visto demasiadas veces antes.

El cliente no se ha preparado para lo que viene después de la migración. No existía ninguna práctica de Infraestructura como Código (IaC). No hay cultura DevOps ni DevSecOps. No hay un marco de Operaciones como Código. Y, lo más importante, no existe un modelo de Gobernanza en la Nube que guíe decisiones, gestione riesgos o controle costes.

Planeaban trasladar 180+ servidores a la nube, pero intentaban traer el mismo modelo operativo que les ha frenado durante años.

Esto no es solo una laguna técnica. Es un punto ciego estratégico que les costaría dinero, tiempo, seguridad y oportunidad.

La ilusión de «simplemente migrar»

Cuando las organizaciones piensan en la migración a la nube, el foco suele estar en el propio movimiento: qué cargas de trabajo migrar, qué proveedor de nube elegir, cómo minimizar el tiempo de inactividad durante el cambio de posición.

Son preguntas importantes. Pero no son los más importantes.

La verdadera pregunta es: ¿Qué ocurre el segundo día?

Una vez que los servidores están funcionando en la nube, ¿quién los gestiona? ¿Cómo se implementan los cambios? ¿Cómo aseguráis la coherencia entre entornos? ¿Cómo se controlan los costes? ¿Cómo respondes a los incidentes de seguridad? ¿Cómo escalas cuando la demanda se dispara?

Sin la base operativa adecuada, la nube se convierte en otro centro de datos, excepto que ahora lo pagas por horas y la factura puede descontrolarse más rápido de lo que crees.

He visto empresas migrar con éxito solo para enfrentarse a una dura realidad seis meses después:

• Los costes de la nube son un 40% superiores a lo previsto porque nadie gestiona la optimización de recursos.
• Los ciclos de despliegue siguen midiéndose en semanas porque los procesos manuales no han cambiado.
• Los incidentes de seguridad aumentan porque se levantaron y reajustaron los controles de acceso sin replantearse los modelos de identidad.
• Los equipos están quemados porque gestionan la infraestructura en la nube de la misma manera que gestionaban los servidores locales: manualmente, de forma reactiva y sin automatización.

La migración tuvo éxito. La transformación fracasó.

Lo que falta: La Fundación Operativa

Permítanme dejar claro a qué me refiero con «base operativa». No es una sola herramienta o plataforma. Es un conjunto de prácticas y disciplinas que te permiten operar la nube de forma eficaz, segura y sostenible.

1. Infraestructura como código (IaC)

En la informática tradicional, la infraestructura se construye manualmente: alguien inicia sesión en una consola, navega por asistentes y proporciona recursos. Ese enfoque no escala en la nube.

IaC trata la infraestructura de la misma manera que los desarrolladores tratan el código de la aplicación: versionado, probado y automatizado. Cada recurso: redes, servidores, bases de datos, políticas de seguridad, está definido en código y desplegado a través de canales.

Por qué es importante: Sin IaC, todos los entornos se convierten en un copo de nieve. Reproducirse configuraciones es propenso a errores. Auditar los cambios es casi imposible. Y cuando algo falla, la solución de problemas se convierte en una conjetura.

El coste de saltársela: El aprovisionamiento manual conduce a deriva en la configuración, brechas de seguridad e ineficiencia operativa. En el contexto de los servicios financieros, también genera un riesgo de cumplimiento.

2. DevOps y DevSecOps

DevOps consiste en romper los compartimentos entre desarrollo y operaciones para que los equipos puedan ofrecer valor más rápido y de forma más fiable. DevSecOps amplía eso integrando la seguridad en cada etapa de la cadena de entrega.

En la práctica, esto significa:

• Canalizaciones automatizadas de pruebas y despliegue (CI/CD).
• Propiedad compartida de la salud y el rendimiento de la aplicación.
• Controles de seguridad integrados en revisiones de código, compilaciones y despliegues, no añadidos al final.

Por qué es importante: La nube recompensa la velocidad, pero la velocidad sin control es caos. DevOps y DevSecOps crean la disciplina para avanzar rápido sin romper nada.

El coste de saltársela: Sin DevOps, los ciclos de despliegue siguen siendo lentos y propensos a errores. Sin DevSecOps, las vulnerabilidades se deslizan hacia la producción y el cumplimiento se convierte en un proceso reactivo.

3. Operaciones como código

Operaciones como Código extiende la filosofía IaC a tareas operativas: monitorización, respuesta a incidentes, políticas de escalado, procedimientos de respaldo. En lugar de depender del conocimiento tribal y de manuales, la lógica operativa se codifica, automatiza y mejora continuamente.

Por qué es importante: Los entornos en la nube son dinámicos. Las operaciones manuales no pueden seguir el ritmo. Operaciones como Código garantiza la coherencia, reduce el error humano y permite a los equipos escalar su capacidad operativa sin escalar el personal de personal.

El coste de saltársela: El trabajo operativo aumenta. Los incidentes tardan más en resolverse. Los equipos dedican más tiempo a la extinción de bomberos y menos a innovar.

4. Gobernanza de la Nube

He escrito antes sobre el poder silencioso de la Gobernanza de la Nube, y merece la pena repetirlo aquí: la gobernanza no es burocracia. Es libertad a través de la estructura.

La gobernanza de la nube define:

• Quién posee qué y quién puede cambiarlo.
• Cómo se controlan y controlan los costes.
• ¿Qué políticas de seguridad y cumplimiento se aplican?
• Cómo se detectan y corrigen las desviaciones de las mejores prácticas.

Por qué es importante: Sin gobernanza, la adopción de la nube se convierte en un caos total. Los costes se disparan. La postura de seguridad se debilita. Surgen brechas de cumplimiento. Y cuando algo sale mal, nadie sabe quién es responsable.

El coste de saltársela: He visto organizaciones enfrentarse a sobrecostes presupuestarios del 40% o más en los primeros meses tras la migración. He visto incidentes de seguridad que podrían haberse evitado con controles de acceso básicos. Y he visto cómo los líderes pierden la confianza en la nube porque los beneficios prometidos nunca se materializaron.

S no es solo una laguna técnica. Es un punto ciego estratégico que les costaría dinero, tiempo, seguridad y oportunidad.

El verdadero impacto: un estudio de caso

Permítanme compartir una historia que ilustra lo que está en juego.

Hace unos años, un banco regional que migró 80+ aplicaciones a la nube en menos de un año me llamó para consultarme sobre los problemas que estaban enfrentando. . La migración en sí fue técnicamente exitosa: las cargas de trabajo se movieron, los sistemas se pusieron en marcha y la huella del centro de datos se redujo.

Pero en seis meses aparecieron grietas:

• Los costes se dispararon. Sin gobernanza ni visibilidad de costes, los equipos sobreaprovisionaban recursos «solo por precaución». Las facturas mensuales de la nube fueron un 35% superiores a lo previsto.
• Los despliegues se ralentizaron. Sin pipelines CI/CD, cada cambio requería coordinación manual entre equipos. Lo que debería haber tomado horas duró días.
• Los incidentes de seguridad aumentaron. Los controles de acceso eran inconsistentes. Los desarrolladores tenían más permisos de los que necesitaban. Una auditoría reveló decenas de lagunas de cumplimiento.
• La moral del equipo cayó. Los equipos de operaciones estaban desbordados, trabajando por las noches y fines de semana para cumplir con tareas manuales que deberían haber sido automatizadas.

El banco se había trasladado a la nube, pero no habían transformado su forma de operar. El resultado fueron mayores costes, entrega más lenta y mayor riesgo.

Hicieron falta otros 18 meses, y una inversión significativa, para construir la base operativa que deberían haber establecido antes de la migración.

Compáralo con otra empresa de servicios financieros con la que trabajé. Antes de migrar una sola carga de trabajo, invirtieron en:

• Plantillas y estándares de IaC.
• Canalizaciones CI/CD para el despliegue de aplicaciones e infraestructura.
• Un marco de gobernanza en la nube con barreras de seguridad automatizadas.
• Formación y mejora de habilidades para equipos técnicos.

La migración duró un poco más, pero los resultados fueron transformadores:

• Los ciclos de despliegue se redujeron de semanas a días.
• Los costes en la nube quedaron un 20% por debajo del presupuesto gracias a la optimización proactiva.
• La postura de seguridad mejoró, sin ningún hallazgo crítico de cumplimiento.
• Los equipos estaban llenos de energía, no quemados.

La diferencia no era la capacidad técnica. Era preparación.

Por qué las organizaciones evitan la Fundación

Si el valor de estas prácticas es tan evidente, ¿por qué tantas organizaciones las omiten?

Por mi experiencia, las razones son predecibles:

1. Presión para moverse rápido. Los directivos establecen plazos muy exigentes y los equipos se centran en la migración en sí, no en lo que viene después.
2. Subestimar el cambio cultural. IaC, DevOps y gobernanza no son solo cambios técnicos, requieren nuevas formas de trabajar, y eso lleva tiempo.
3. Tratar la nube como una estrategia de ahorro. Si el objetivo es simplemente reducir los costes del centro de datos, la base operativa parece un gasto innecesario. (Spoiler: no lo es.)
4. Falta de conciencia. Muchas organizaciones simplemente no saben lo que no saben. Asumen que las operaciones en la nube serán «más fáciles» sin darse cuenta de la disciplina necesaria.

Como escribí en De palabras de moda a valor empresarial, La transformación en la nube nunca se trata de la nube. Se trata del valor empresarial. Y no puedes aportar valor empresarial si tu modelo operativo está atascado en el pasado.

El camino a seguir

En la empresa de servicios financieros en la que trabajaba recientemente, adoptamos un enfoque diferente. En lugar de acelerar la migración, primero construimos la base:

Fase 1: Establecer el modelo operativo

• Define los estándares y plantillas de IaC.
• Construir pipelines CI/CD para el despliegue de infraestructura y aplicaciones.
• Implementa un marco de Gobernanza en la Nube con aplicación automatizada de políticas.
• Formar equipos en prácticas de DevOps y DevSecOps.

Fase 2: Piloto y validación

• Migra una carga de trabajo pequeña y no crítica usando el nuevo modelo operativo.
• Valida que IaC, CI/CD y gobernanza funcionen como se espera.
• Recoge opiniones y perfecciona el enfoque.

Fase 3: Escalar la migración

• Migra las cargas de trabajo en oleadas, aplicando las lecciones aprendidas del piloto.
• Optimiza continuamente los costes, la seguridad y el rendimiento.
• Mide el éxito no por cuántos servidores se han movido, sino por los resultados empresariales: entrega más rápida, menor riesgo, mejor resiliencia.

Este enfoque tarda más en el principio, pero evita la costosa reestructuración y el caos operativo que conlleva migrar sin una base.

Lecciones para líderes tecnológicos

Si lideras una migración a la nube, aquí tienes las lecciones que destacaría:

1. No confundas migración con transformación. Mover la carga de trabajo es la parte fácil. Cambiar tu forma de actuar es la parte difícil y la parte valiosa.

2. Invierte en la base antes de la migración. IaC, DevOps, DevSecOps, Operaciones como Código y Gobernanza en la Nube no son cosas buenas de tener. Son requisitos previos para tener éxito.

3. Mide el éxito por resultados, no por actividad. «Migramos 180 servidores» no es un éxito. «Reducimos el tiempo de despliegue en un 60% y mejoramos la postura de seguridad» es un éxito.

4. Trata la nube como una capacidad, no como un destino. Como he escrito antes en Puente de Estrategia y Ejecución, la transformación solo ocurre cuando la estrategia se traduce en claridad, se alinea a través de hojas de ruta y se refuerza con bucles de retroalimentación.

5. Prepárate para el cambio cultural. La tecnología es la parte fácil. Las personas y los procesos son donde vive o muere la transformación.

Reflexiones finales

La migración a la nube sin preparación operativa es como construir una casa sin cimientos. Puede que dure un tiempo, pero con el tiempo, las grietas aparecerán.

Las organizaciones que tienen éxito en la nube no son las que se mueven más rápido. Son quienes se mueven con deliberación, construyendo la base operativa que les permite operar con rapidez, seguridad y sostenibilidad.

Para la empresa de servicios financieros en la que trabajaba recientemente, los resultados se hicieron visibles muy pronto; al invertir en IaC, DevOps, DevSecOps, Operations as Code y Cloud Governance, ahora los estamos preparando no solo para migrar, sino para transformar.

Porque al final, La nube no trata de dónde funcionan tus servidores. Se trata de cómo operas, cómo innovas y cómo aportas valor.

Y eso requiere una base.

Ricardo