En mi publicación anterior, El coste oculto de la falta de preparación, describí el desafío que enfrenta una empresa de servicios financieros al migrar 180+ servidores sin la base operativa necesaria para tener éxito. Los riesgos son reales: sobrecostes, lagunas de seguridad, fallos de cumplimiento y equipos quemados.

Pero aquí está la pregunta que sigo escuchando: «Si necesitamos construir esta base, ¿cuánto tiempo llevará? Ahora estamos bajo presión para movernos.»

La buena noticia: no necesitas años. Ni siquiera necesitas seis meses.

Por mi experiencia trabajando con bancos, fintechs y compañías de seguros en toda América Latina, he visto a organizaciones establecer la preparación operativa en la nube en 90 días, lo suficiente para migrar con confianza y operar de forma sostenible.

Esto no va de perfección. Se trata de construir la base mínima viable que te permita moverte rápido sin romper cosas. Y en los servicios financieros, donde el escrutinio regulatorio es alto y el tiempo de inactividad costoso, esa base es innegociable.

Déjame explicarte cómo hacerlo.

¿Por qué 90 días?

Noventa días es suficiente para establecer una capacidad real, pero lo bastante corto para mantener el impulso y el apoyo ejecutivo.

También es un marco temporal que se alinea con el funcionamiento de las instituciones financieras: ciclos de planificación trimestral, ventanas de auditoría y ritmos de informes en los consejos de administración.

Pero quiero ser claro: esto no va de precipitarse. Se trata de ser deliberado y centrado. No estás construyendo todo, estás construyendo lo que más importa para operar la nube de forma segura y eficaz.

El marco que comparto proviene de proyectos reales. Se ha probado en bancos regionales, grupos financieros multinacionales y fintechs de rápido crecimiento. El contexto varía, pero el patrón se mantiene. En cualquier caso, este enfoque requiere un compromiso real, no intenciones poco claras.

El Marco de 90 Días

El marco está estructurado en tres sprints de 30 días, cada uno con un resultado claro. Piénsalo como construir en capas: base, validación y escala.

Sprint 1 (Días 1-30): Establecer la Fundación

Gol: Define estándares, desarrolla capacidades básicas y alinea equipos.

Este sprint consiste en crear el andamiaje sobre el que se construirá todo lo demás. Aún no estás migrando cargas de trabajo, te estás preparando bien para migrar.

Semana 1: Definir el Marco de Gobernanza de la Nube

Empieza por la gobernanza. Como escribí en El poder silencioso de la gobernanza en la nube, la gobernanza es libertad a través de la estructura. Sin ella, la adopción de la nube se convierte en un caos.

Actividades clave:

• Define la estructura de la cuenta (estrategia multicuenta para desarrollo, prueba, producción).
• Establecer políticas de gestión de identidad y acceso (IAM) basadas en el privilegio mínimo.
• Configura etiquetas de asignación de costes y alertas presupuestarias.
• Define líneas base de seguridad (cifrado, registro, segmentación de red).
• Procesa los flujos de trabajo de aprobación de documentos para excepciones.

Resultado: Un manual de gobernanza que responde: ¿Quién es dueño de qué? ¿Quién puede cambiarlo? ¿Cómo se controlan los costes? ¿Qué políticas de seguridad se aplican?

Consejo profesional: No busques la perfección. Empieza con un framework ligero e itera. El objetivo es la claridad, no la burocracia.

Semana 2: Plantillas de Construir Infraestructura como Código (IaC)

IaC es la columna vertebral de las operaciones en la nube. Cada recurso: redes, computación, almacenamiento, grupos de seguridad, debe estar definido en código, versionado y repetible.

Actividades clave:

• Elige una herramienta IaC (Terraform, AWS CloudFormation, Azure ARM, Biceps o similar).
• Crea plantillas para patrones comunes: VPCs, subredes, grupos de seguridad, instancias de cómputo, bases de datos.
• Establecer convenciones de nombres y estándares de etiquetado.
• Guardar plantillas en el control de versiones (Git).

Resultado: Una biblioteca de plantillas IaC reutilizables que hacen cumplir las políticas de gobernanza por defecto.

Consejo profesional: Empieza con una arquitectura de referencia, una pila de aplicaciones estándar de tres niveles. Demuestra que funciona y luego amplía.

Semana 3: Establecer las Líneas CI/CD

La automatización es lo que separa las operaciones en la nube de las TI tradicionales. Las canalizaciones CI/CD permiten desplegar infraestructura y aplicaciones de forma consistente, con pruebas y controles de seguridad integrados.

Actividades clave:

• Configura una plataforma CI/CD (GitLab, GitHub Actions, Jenkins, AWS CodePipeline, Azure DevOps o similar).
• Construir una canalización para el despliegue de IaC: revisión de código → pruebas automatizadas → despliegue a la puerta de aprobación de desarrollo → → despliegue a producción.
• Integra escaneos de seguridad (análisis estático, comprobaciones de vulnerabilidades).
• Documenta el proceso de despliegue.

Resultado: Una tubería operativa que despliega infraestructura a partir de código, con puertas automatizadas de validación y aprobación.

Consejo profesional: Mantenlo sencillo. Un pipeline básico que funciona es mejor que uno complejo que no.

Semana 4: Entrenar y alinear equipos

La tecnología sin personas es simplemente una infraestructura cara. Esta semana se trata de mejorar las habilidades de los equipos y alinearlos con el nuevo modelo operativo.

Actividades clave:

• Realizar talleres sobre IaC, CI/CD y gobernanza en la nube.
• Asigna roles y responsabilidades (quién posee qué en el nuevo modelo).
• Establece canales de comunicación (Slack, Teams o similares para la colaboración multifuncional).
• Crea una hoja de ruta compartida que vincule los objetivos empresariales con hitos técnicos (como expliqué en Estrategia y Ejecución de Puentes).

Resultado: Los equipos comprenden el nuevo modelo operativo y su papel en él. La resistencia se convierte en compromiso.

Consejo profesional: No subestimes el cambio cultural. Invierte tiempo en explicar el «por qué», no solo el «cómo».

Sprint 2 (Días 31-60): Validar con un piloto

Gol: Demuestra que el modelo operativo funciona migrando una carga de trabajo real.

Este sprint es donde la teoría se encuentra con la realidad. Estás probando tus plantillas IaC, pipelines CI/CD y políticas de gobernanza con una carga de trabajo en tiempo real.

Semana 5: Seleccionar y preparar la carga de trabajo del piloto

Elige una carga de trabajo que sea significativa pero que no sea crítica para la misión. Quieres algo lo suficientemente real para sacar a la luz problemas, pero lo bastante bajo como para que el fracaso no cause una crisis.

Actividades clave:

• Selecciona una aplicación piloto (idealmente una aplicación web de tres niveles con base de datos).
• Documenta la arquitectura y dependencias actuales.
• Define los criterios de éxito: tiempo de activación, rendimiento, coste, postura de seguridad.

Resultado: Una carga de trabajo piloto seleccionada y documentada, con métricas de éxito claras.

Consejo profesional: Evita la tentación de elegir la carga de trabajo más fácil. Elige uno que represente lo que migrarás a gran escala.

Semana 6: Migrar el piloto usando IaC y CI/CD

Este es el momento de la verdad. Despliega la carga de trabajo del piloto usando las plantillas IaC y las canalizaciones CI/CD que construiste en Sprint 1.

Actividades clave:

• Aprovisiona infraestructura usando IaC.
• Despliega la aplicación a través de la tubería CI/CD.
• Configura la monitorización y el registro.
• Validar los controles de seguridad (cifrado, políticas de acceso, segmentación de red).

Resultado: La carga de trabajo del piloto se ejecuta en la nube, desplegada íntegramente mediante código y automatización.

Consejo profesional: Espera problemas. Ese es el punto. Documenta cada problema y cómo lo has resuelto.

Semana 7: Operar y optimizar el piloto

Ahora que el piloto está en marcha, operarlo como si fuera una carga de trabajo de producción. Esta semana consiste en validar que tu modelo operativo escala más allá del despliegue.

Actividades clave:

• Monitoriza el rendimiento, la disponibilidad y los costes.
• Prueba los procedimientos de respuesta a incidentes.
• Optimiza el tamaño de los recursos en función del uso real.
• Validar el cumplimiento de las políticas de gobernanza.

Resultado: Confianza en que el modelo operativo funciona en la práctica, no solo en teoría.

Consejo profesional: Involucra a los equipos de operaciones desde el principio. Su feedback es fundamental para perfeccionar los libros de operaciones y la automatización.

Semana 8: Retrospectiva y refinamiento

Haz una pausa y reflexiona. ¿Qué funcionó? ¿Qué no? ¿Qué hay que cambiar antes de escalar?

Actividades clave:

• Realiza una retrospectiva con todos los equipos implicados.
• Documenta las lecciones aprendidas.
• Actualizar las plantillas, pipelines y políticas de gobernanza de IaC basándose en la retroalimentación.
• Refina el manual de migración.

Resultado: Un modelo operativo validado y refinado, listo para escalar.

Consejo profesional: Celebra las victorias. Los pilotos son un trabajo duro, y los equipos necesitan ver que su esfuerzo ha importado.

Sprint 3 (Días 61-90): Escala y Operacionalización

Gol: Prepárense para escalar la migración e integrar la excelencia operativa.

Este sprint consiste en tomar lo aprendido del piloto y hacerlo repetible, sostenible y escalable.

Semana 9: Ampliar IaC y Automatización

Basándote en las lecciones del piloto, amplía tu biblioteca IaC y tus capacidades de automatización.

Actividades clave:

• Construye plantillas IaC adicionales para otros tipos de carga de trabajo (procesamiento por lotes, pipelines de datos, etc.).
• Automatiza tareas operativas: copias de seguridad, parcheos, escalado de políticas.
• Integrar la monitorización y la alerta en la cadena CI/CD.

Resultado: Una biblioteca IaC completa y un marco de automatización listos para escalar.

Consejo profesional: Prioriza la automatización para tareas repetitivas y propensas a errores. Ahí es donde verás el mayor retorno de inversión.

Semana 10: Establecer operaciones como código

Operaciones como Código extiende IaC a los procedimientos operativos: respuesta a incidentes, políticas de escalado, recuperación ante desastres.

Actividades clave:

• Codificar los libros de procedimientos para tareas operativas comunes.
• Automatizar la detección y respuesta de incidentes (auto-escalado, auto-reparación).
• Define los procedimientos de recuperación ante desastres y pruébalos.

Resultado: Resiliencia operativa incorporada en la plataforma, no dependiente de heroísmo.

Consejo profesional: Empieza por los incidentes más comunes. Automatiza eso primero.

Semana 11: Fortalecer la gobernanza de la nube

Con el piloto validado, fortalece la gobernanza para prepararte para la escala.

Actividades clave:

• Implementa la aplicación automatizada de políticas (AWS Config, Azure Policy o similar).
• Establece un seguimiento continuo del cumplimiento.
• Establecer prácticas de optimización de costes (redimensionamiento, instancias reservadas, instancias spot).
• Crea paneles de control para tener visibilidad sobre costes, seguridad y cumplimiento.

Resultado: Gobernanza que escale sin añadir sobrecarga manual.

Consejo profesional: Haz que la gobernanza sea visible. Los paneles de control y las alertas mantienen a los equipos responsables sin micromanagement.

Semana 12: Prepárate para la escala

La última semana se trata de estar preparados: asegurarse de que los equipos, procesos y tecnología estén alineados para la migración completa.

Actividades clave:

• Finaliza la hoja de ruta de migración (qué cargas de trabajo, en qué orden).
• Realiza una revisión de preparación con la dirección.
• Establece bucles de retroalimentación para la mejora continua (como expliqué en Estrategia y Ejecución de Puentes).
• Comunica el plan a la organización en general.

Resultado: Un camino claro y seguro para escalar la migración.

Consejo profesional: No esperes a la perfección. Si has validado el modelo con un piloto, estás listo para escalar.

Cómo se ve el éxito después de 90 días

Al final de los 90 días, no habrás migrado los 130 servidores. Pero tendrás algo más valioso: la preparación operativa.

Así es como se ve eso:

• Gobernanza en vigor: Políticas claras, aplicación automatizada y visibilidad de costes.
• IaC y CI/CD funcionando: Infraestructura desplegada a partir de código, con pruebas automatizadas y comprobaciones de seguridad.
• Piloto validado: Una carga de trabajo real corriendo en la nube, demostrando que el modelo funciona.
• Equipos alineados: Roles definidos, habilidades desarrolladas y resistencia cultural abordada.
• Resiliencia operativa: Se probaron y automatizaron procedimientos de monitorización, respuesta a incidentes y recuperación ante desastres.

No has terminado. Pero estás listo para escalar con confianza.

Por qué funciona esto en los servicios financieros

Las instituciones financieras se enfrentan a limitaciones únicas: escrutinio regulatorio, aversión al riesgo, sistemas heredados y complejos procesos de aprobación. El marco de 90 días tiene en cuenta estas realidades.

Cumplimiento normativo: Al integrar la gobernanza y la seguridad desde el primer día, estás integrando el cumplimiento en la base, no la adaptas después.

Gestión de riesgos: El enfoque piloto permite validar el modelo con cargas de trabajo de bajo riesgo antes de tocar sistemas críticos para la misión.

Cambio cultural: Noventa días son tiempo suficiente para cambiar mentalidades sin perder el impulso. Los equipos ven resultados rápidamente, lo que genera confianza.

Alineación ejecutiva: Los ciclos trimestrales coinciden con la forma en que las instituciones financieras planifican e informan. Un sprint de 90 días encaja de forma natural en los ritmos existentes.

Trampas comunes que hay que evitar

Incluso con un marco claro, he visto a organizaciones tropezar. Aquí están los errores más comunes:

1. Saltarse la gobernanza. Los equipos se apresuran a construir IaC y CI/CD sin definir políticas. Resultado: automatización que escala el caos.

2. Elegir al piloto equivocado. Elegir una carga de trabajo demasiado sencilla (que no plantea problemas reales) o demasiado compleja (demasiado arriesgada). Elige algo representativo.

3. Invertir poco en formación. La tecnología es fácil. La gente es difícil. Si los equipos no entienden el «por qué», resistirán el «cómo».

4. Tratando al piloto como un caso aislado. El piloto no es un experimento científico, es un ensayo para medir la escala. Tómalo en serio.

5. Ignorar los bucles de retroalimentación. Como escribí en Puente de Estrategia y Ejecución, estrategia y ejecución deben coevolucionar. Crea bucles de retroalimentación desde el primer día.

Ejemplo real: un banco regional

Déjame compartir un caso real. Un banco regional en América Latina estaba bajo presión para migrar a la nube en menos de un año. Tenían 90+ aplicaciones, poca experiencia en la nube y una cultura de riesgo averso.

Implementamos el marco de 90 días:

• Sprint 1: Definía la gobernanza, construía plantillas de IaC, establecía pipelines CI/CD, formaba equipos.
• Sprint 2: Migré una aplicación web orientada al cliente como piloto. Validé el modelo. Refinado en función de las lecciones aprendidas.
• Sprint 3: Amplió la automatización, reforzó la gobernanza y preparó la hoja de ruta migratoria.

Después de 90 días, no habían migrado todo. Pero tenían:

• Reducción del tiempo de despliegue de semanas a horas.
• Se estableció la monitorización automatizada del cumplimiento.
• Han generado confianza entre los equipos técnicos y de liderazgo.
• Creé un manual repetible para escalar la migración.

Durante los siguientes nueve meses, migraron el 80% de sus cargas de trabajo: a tiempo, por debajo del presupuesto, sin incidentes críticos de seguridad.

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

Reflexiones finales

La migración a la nube sin preparación operativa es una apuesta. Puede que tengas suerte, pero las probabilidades no están a tu favor.

El marco de 90 días no trata de la perfección. Se trata de construir la base mínima viable que te permita migrar con confianza, operar de forma sostenible y ofrecer el valor empresarial que promete la nube.

Para las instituciones financieras, donde el riesgo es alto y la confianza lo es todo, esa base no es opcional. Es la diferencia entre transformación y caos.

Como escribí en De palabras de moda a valor empresarial, La nube no es un destino. Es la base para la transformación continua.

Y la transformación comienza con la preparación.

Ricardo