Migración a AWS: cuánto tiempo toma realmente y qué esperar
La respuesta que más escucho cuando pregunto cuánto esperan que tome su migración a AWS es “dos o tres semanas”. La realidad casi siempre es entre 6 y 12 semanas — y no porque el trabajo sea difícil, sino porque hay dependencias, aprobaciones y pruebas que no se pueden comprimir sin arriesgar la operación.
Por qué “dos semanas” casi nunca es suficiente
Una migración a AWS no es mover archivos de un servidor a otro. Implica rediseñar la arquitectura objetivo, configurar la red (VPC, subnets, security groups), migrar datos con replicación continua para no perder transacciones, validar que todo funciona en el nuevo entorno, y ejecutar un cutover controlado con plan de rollback si algo falla.
Cada una de esas etapas tiene sus propios tiempos — y muchas de ellas dependen de que el equipo de la empresa provea acceso, contexto o aprobaciones que no siempre están disponibles en el momento en que se necesitan.
Las fases reales de una migración
Migration Readiness Assessment (MRA) — 1 a 2 semanas
Inventario de lo que tienes: servidores, bases de datos, dependencias entre sistemas, tráfico promedio, SLAs actuales. Esta fase descubre las sorpresas — el servidor que nadie sabe para qué sirve pero “no se puede apagar”, la base de datos que tiene 5 aplicaciones dependientes que nadie documentó, la licencia de software que no es transferible a la nube.
Diseño de arquitectura objetivo — 1 semana
Definir qué va a dónde: qué instancias EC2, qué tamaños, en qué subnets, cómo se conectan los componentes, qué se usa para alta disponibilidad. Este diseño debe ser aprobado por quien toma decisiones técnicas en la empresa antes de avanzar. Sin aprobación, cualquier avance puede tener que rehacerse.
Migración por olas — 2 a 6 semanas
Se migra sistema por sistema, empezando por los menos críticos (entornos de desarrollo o sistemas secundarios) y terminando con producción. Para bases de datos usamos AWS DMS con replicación continua (CDC): el origen sigue activo mientras la réplica en AWS se mantiene sincronizada, lo que permite un cutover con una ventana de corte de minutos, no horas. El número de olas depende de la complejidad: una empresa con 3 aplicaciones puede hacer 2 olas, una empresa con 15 sistemas puede necesitar 6.
Cutover y validación — 1 semana
El momento del cambio real. Se ejecuta el cutover en una ventana de mantenimiento acordada (típicamente fin de semana o madrugada), se valida que todo funciona en AWS, y se mantiene el entorno origen disponible por 48-72 horas como fallback. Si algo falla, se revierte. Si todo funciona, se descomisiona el origen.
Post-migración — 2 semanas
Monitoreo intensivo, ajuste de alertas, primeras optimizaciones de costo, documentación y handover técnico. Esta fase es tan importante como la migración misma — muchos problemas aparecen en la primera semana de producción real en AWS.
Qué puede alargar la migración
En la práctica, estos son los factores que más retrasos generan:
- Documentación incompleta: si nadie sabe exactamente qué está corriendo ni cómo se conectan los sistemas, el MRA puede tomar el doble de lo esperado.
- Dependencias de terceros: proveedores que necesitan actualizar IPs en sus firewalls, integraciones con sistemas externos que requieren pruebas de aceptación, certificados SSL que hay que coordinar.
- Aprobaciones internas lentas: si cada decisión técnica requiere aprobación de un comité, los ciclos se alargan. Nombrar un decisor técnico claro desde el inicio acelera significativamente el proyecto.
- Datos muy grandes: migrar terabytes de datos con replicación continua toma tiempo. Si tienes bases de datos de más de 1 TB, hay que planificar el período de sincronización inicial con anticipación.
Cómo prepararte antes de iniciar
Las migraciones más fluidas que hemos ejecutado tenían estas tres cosas listas antes del día uno:
- Un inventario actualizado de sistemas, bases de datos y dependencias — aunque sea en un Excel.
- Un decisor técnico designado con autoridad para aprobar arquitectura y ventanas de mantenimiento sin escalar a un comité.
- Claridad sobre las ventanas de mantenimiento disponibles — cuándo se puede hacer downtime sin impacto al negocio.
¿Hay downtime obligatorio?
Para la mayoría de aplicaciones web y bases de datos relacionales, el downtime puede reducirse a minutos usando replicación continua con AWS DMS. El origen sigue activo mientras la réplica en AWS se actualiza en tiempo real, y el cutover es solo cambiar el DNS o el connection string para apuntar al nuevo entorno.
Los casos donde el downtime es más difícil de evitar: aplicaciones legacy que no soportan cambio de conexión sin reinicio, bases de datos NoSQL grandes sin herramienta de replicación nativa, o arquitecturas muy acopladas donde todo tiene que moverse junto. En esos casos, la estrategia es minimizar la ventana con una preparación más cuidadosa, no eliminarla por completo.
¿Estás evaluando migrar a AWS?
Hacemos un Migration Readiness Assessment que toma entre 1 y 2 semanas. El resultado es un inventario de tus sistemas, una arquitectura objetivo y un cronograma realista — antes de comprometer recursos.
Solicitar Migration Readiness Assessment →