Cómo migrar a AWS sin detener tu operación

Cuando le preguntamos a los gerentes de tecnología qué los detiene de migrar a la nube, la respuesta más frecuente no es el costo ni la complejidad técnica. Es el miedo a que algo salga mal durante el proceso y la operación del negocio se paralice. “No puedo darme el lujo de quedarme sin sistema un día entero”, nos dijo el gerente de TI de una empresa logística de Concepción con 80 empleados. Tenía razón: no puede. Y por eso existe el método paralelo.

Una migración bien planificada a AWS no requiere apagar el sistema actual. Se construye el nuevo ambiente en paralelo, se valida que funciona correctamente, y solo entonces se hace el corte. Ese corte, si se planifica bien, puede durar entre 15 minutos y 2 horas, idealmente en horario de baja actividad. No días, no semanas: horas.

El método paralelo: construir mientras el sistema actual sigue

La lógica es simple: no se apaga el sistema viejo hasta que el sistema nuevo esté listo y validado. Durante el período de migración, ambos ambientes coexisten. El sistema actual sigue operando normalmente. En paralelo, se construye el nuevo ambiente en AWS, se migran los datos, se prueban las aplicaciones y se verifica que todo funciona.

Este enfoque tiene dos ventajas clave. Primero, elimina la presión del tiempo: si algo no funciona en el ambiente nuevo durante las pruebas, no pasa nada porque el sistema actual sigue en pie. Segundo, permite hacer pruebas reales con datos reales, lo que reduce drásticamente las sorpresas durante el corte final.

El único período de riesgo real es la ventana de corte: ese momento en que se apunta el tráfico y los usuarios al nuevo sistema. Esa ventana se puede planificar para un sábado en la noche o un día feriado, y si algo sale mal durante la primera hora, la opción de rollback (volver al sistema anterior) sigue disponible mientras no se apague el sistema antiguo.

Las 4 fases de una migración sin downtime

En Lumus, estructuramos las migraciones a AWS en cuatro fases. El tiempo total varía según la complejidad de la empresa, pero para una pyme mediana (2-5 aplicaciones, base de datos de hasta 100 GB), el proceso completo suele tomar entre 4 y 10 semanas.

• →Fase 1 — Inventario y arquitectura (1-2 semanas): se documenta todo lo que existe: servidores, aplicaciones, bases de datos, dependencias entre sistemas, volumetría de datos, requisitos de disponibilidad. Con eso se diseña la arquitectura en AWS que replica y mejora lo que hay. Esta fase define el costo final y el plan de contingencia.
• →Fase 2 — Construcción del ambiente AWS (1-3 semanas): se crean los recursos en la nube: instancias EC2, bases de datos RDS, redes VPC, grupos de seguridad, roles IAM. Se configura el monitoreo y las alertas. Al final de esta fase, tienes un ambiente nuevo vacío pero funcionando y asegurado.
• →Fase 3 — Migración de datos y pruebas (1-3 semanas): se migran los datos al nuevo ambiente usando herramientas como AWS Database Migration Service o rsync para archivos. Se instalan y configuran las aplicaciones. Luego se hacen pruebas exhaustivas: funcionales (¿hace lo que debe hacer?), de rendimiento (¿responde con la velocidad esperada?) y de seguridad (¿solo accede quien debe acceder?). Si algo falla, se corrige sin prisa porque el sistema actual sigue operando.
• →Fase 4 — Corte y validación (horas): se agenda la ventana de corte, se hace una última sincronización de datos para capturar los cambios más recientes, se apunta el DNS y el tráfico al nuevo sistema y se verifica que todo funciona con usuarios reales. El sistema anterior se mantiene disponible pero inactivo durante 24-48 horas más, como red de seguridad. Si algo sale mal en las primeras horas, el rollback es rápido.

Qué hacer cuando algo sale mal

Ninguna migración está exenta de imprevistos. La diferencia entre una migración bien planificada y una que se improvisa es que en la primera, los imprevistos tienen respuesta predefinida antes de que ocurran.

Los problemas más comunes que encontramos durante el corte son:

• →Datos que cambiaron en las últimas horas antes del corte: entre la última sincronización de prueba y el corte real, los usuarios siguieron trabajando en el sistema antiguo. Si la ventana de corte es corta, esto es manejable: se hace una sincronización incremental de los últimos cambios justo antes de apagar el sistema viejo.
• →Aplicaciones que tienen configuraciones hardcodeadas con la IP del servidor antiguo: esto se descubre en las pruebas, no en el corte. Por eso la fase 3 es tan importante. Si aparece en el corte, el rollback es la respuesta correcta mientras se corrige.
• →Rendimiento distinto al esperado: el ambiente nuevo puede comportarse diferente al antiguo si los recursos no están bien calibrados. El monitoreo en tiempo real durante las primeras horas post-corte permite detectar y corregir esto rápidamente ajustando el tamaño de las instancias.

La regla de oro es tener definido el criterio de rollback antes de empezar: si X problema ocurre en las primeras Y horas, se vuelve al sistema anterior. Con esa decisión tomada de antemano, el equipo actúa rápido y sin parálisis de decisión si algo sale mal.

Qué preguntarle a tu consultora antes de empezar

No todas las consultoras que ofrecen migración a AWS tienen la misma metodología ni el mismo nivel de rigor. Antes de contratar, hay preguntas concretas que te ayudan a evaluar si estás hablando con alguien que realmente sabe lo que hace:

• →¿Cómo manejan el rollback si algo sale mal durante el corte? Si la respuesta es vaga o no incluye un criterio de tiempo definido, es señal de que el plan de contingencia no está trabajado.
• →¿Cuánto tiempo estima que estará el sistema fuera de línea durante el corte? Una respuesta de “depende” sin dar un rango es preocupante. Con una buena planificación, se puede dar un estimado bastante preciso antes de hacer nada.
• →¿Qué herramientas usan para la migración de datos y cómo verifican la integridad? Copiar datos es fácil. Verificar que los datos copiados son idénticos a los originales requiere un proceso explícito. Pregunta cómo lo hacen.
• →¿El precio incluye el soporte post-migración o termina con el corte? Los primeros 30 días después de una migración son los más críticos. Un buen servicio incluye acompañamiento activo en ese período para resolver los problemas que surgen cuando los usuarios reales empiezan a usar el sistema nuevo.
• →¿Pueden hablar con un cliente anterior que haya hecho una migración similar? Una referencia directa de alguien que pasó por el proceso es la mejor forma de validar que la consultora cumple lo que promete.

Migrar a AWS es una de las decisiones de infraestructura más inteligentes que puede tomar una pyme hoy. El método paralelo elimina el riesgo operacional que más asusta. Lo que queda es elegir bien al equipo que lo va a ejecutar.