Existe una idea extendida en muchas organizaciones: migrar a la nube consiste en mover servidores. Se levanta una copia en el nuevo entorno, se desactiva la anterior, y el proyecto se considera finalizado.
Sin embargo, si esa premisa fuera correcta, la migración concluiría el día del corte. En la práctica, ese es el momento en que comienzan las preguntas de mayor relevancia: ¿quién tiene permisos para crear recursos y bajo qué límites? ¿qué ocurre si una región completa presenta una falla? ¿cómo se detecta un incidente antes de que impacte al cliente?
Una institución financiera panameña, con más de tres décadas de trayectoria, abordó su migración de servidores hacia la nube invirtiendo el orden habitual de prioridades: primero se diseñó el entorno de destino y, posteriormente, se ejecutó la migración. El proyecto se llevó a cabo junto a IVCISA, partner Advanced de AWS.
Diseño del entorno de destino
Antes de migrar un solo servidor, se diseñó el entorno que los recibiría: una estructura de cuentas segregadas por propósito, con gobernanza centralizada y control de acceso basado en identidad, en lugar de credenciales compartidas.
Sobre esa base se implementó una capa de seguridad integral, trazabilidad de cada cambio, registro de actividad, cifrado de datos y una visión centralizada de la postura de seguridad, antes de recibir la primera carga de trabajo. De esta forma, los servidores se incorporaron a un entorno ya preparado para auditarse a sí mismo.
La conectividad de red se centralizó para evitar la complejidad de múltiples enlaces independientes, que suele dificultar el crecimiento posterior, integrando la nube con la seguridad perimetral que el equipo ya operaba.
Ejecución de la migración
Una vez definido el entorno de destino, se ejecutó la migración mediante replicación continua desde el entorno local, manteniendo los sistemas en operación, con una ventana de corte breve y monitoreo constante hasta validar cada servidor en su nuevo entorno. Las prioridades del proyecto fueron minimizar el tiempo de inactividad y garantizar la integridad de los datos.
Continuidad y resiliencia
En muchos proyectos de migración, una vez que el servidor opera en la nube, el proyecto se considera concluido.
En este caso se incorporó, además, una estrategia de recuperación ante desastres para las aplicaciones críticas, con réplica continua lista para activarse ante un escenario adverso, junto con copias de seguridad bajo políticas de retención y alarmas de monitoreo, incluyendo alertas de presupuesto como indicador operativo adicional.
La capa expuesta a internet también fue considerada dentro del diseño: entrega de contenido optimizada, balanceo de carga y un firewall de aplicaciones web protegiendo los servicios públicos.
El resultado es una infraestructura segura, gobernada y escalable: segura, porque cada capa se diseñó considerando primero el riesgo; gobernada, porque los procesos no dependen de la disponibilidad de una sola persona; y escalable, porque el crecimiento no implica rediseñar la arquitectura.
Aprendizajes del proyecto
El orden de ejecución influye directamente en el resultado. Definir gobernanza, seguridad y conectividad de red antes de migrar las cargas de trabajo evita rediseños posteriores, que en producción resultan considerablemente más costosos.
Una migración sin una estrategia de recuperación validada queda incompleta. Si una aplicación crítica no cuenta con una respuesta probada ante el peor escenario, el riesgo no se elimina: únicamente cambia de ubicación.
La migración también constituye una decisión de cumplimiento normativo. En el sector bancario, la capacidad de responder a un auditor sin reconstruir evidencia manualmente no es un beneficio adicional, sino un estándar esperado.
La medida más relevante de una migración exitosa no es la cantidad de servidores trasladados, sino el grado en que las operaciones posteriores se simplifican. Esa base segura, gobernada y escalable es, en definitiva, el resultado que IVCISA desarrolla junto a cada institución financiera que decide migrar hacia la nube.