La migración a AWS dejó de ser una decisión técnica. Hoy es una decisión financiera. En los últimos dos años hemos visto a empresas peruanas mover cargas críticas a la nube esperando reducir costos y terminar pagando 30% a 50% más que en su data center original durante los primeros seis meses.
¿La razón? Casi nunca es AWS. Es el approach con el que se entró a la migración. Estos son los 7 errores más caros que vemos en migraciones AWS en empresas peruanas — y cómo evitarlos antes de firmar tu primer MAP.
1. Lift-and-shift puro sin assessment
El primer impulso es “subimos todo tal cual y después optimizamos”. Suena rápido. En la práctica, cargas mal dimensionadas en EC2 cuestan 2-3x más que en on-premise porque pagas por uso 24×7 sin que el rightsizing haya pasado.
Cómo evitarlo: assessment de 2-3 semanas antes de mover una sola carga. Discovery, dimensionamiento real, identificación de cargas que NO deberían migrar, y plan de modernización progresiva.
2. No aprovechar AWS Migration Acceleration Program (MAP)
El MAP financia con créditos AWS hasta 25-40% de tu migración si la ejecutas con un partner certificado. Muchas empresas peruanas migran sin acceder a estos créditos porque no saben que existen o no tienen el partner.
Cómo evitarlo: trabaja con un AWS Migration Competency Partner desde el día 1. Caleidos tiene esta competency y opera el MAP como sistema repetible.
3. No diseñar la landing zone primero
Saltar al “vamos migrando” sin AWS Control Tower, multi-cuenta organizada, IAM con principio de menor privilegio y tagging policy es una bomba de tiempo. Tres meses después tienes 50 recursos sin tag, no sabes qué cuenta es de qué unidad de negocio, y la factura es un misterio.
Cómo evitarlo: invertir 1-2 semanas en setup de landing zone antes de la primera carga. AWS Control Tower + Organizations + tagging strategy + cost allocation tags.
4. Subestimar la transferencia de datos
Los costos de egress (sacar data de AWS hacia internet o entre regiones) suelen sorprender. Una arquitectura mal diseñada con servicios en regiones distintas o llamadas constantes a APIs externas puede sumar miles de dólares mensuales en transfer.
Cómo evitarlo: diseñar la arquitectura considerando ubicación de servicios, VPC peering vs internet gateway, y CDN para contenido estático. Lo modelamos en el assessment inicial.
5. No implementar FinOps desde el día 1
FinOps no es un proyecto post-migración. Es un sistema operativo continuo: visibilidad → optimización → governance. Si arrancas la migración sin FinOps, en 6 meses tienes una factura sin control y un equipo sin herramientas para entenderla.
Cómo evitarlo: implementar AWS Cost Explorer + Budgets + Anomaly Detection + tags rigurosos desde el primer día. Considerar herramientas como CAST.ai para optimización autónoma a partir del segundo mes.
6. Ignorar la modernización progresiva
Lift-and-shift puro deja la mayoría de la deuda técnica intacta. Una vez en AWS, modernizar progresivamente (refactor a containers, serverless, microservicios donde aplique) reduce TCO sustancialmente.
Caso real en producción: una fintech peruana migró a AWS y en paralelo construyó su Data Lake con AWS Glue + Athena + Redshift. Hoy operan más eficientemente que pre-migración. Los detalles están en la sección de casos de éxito.
Cómo evitarlo: plan de modernización por wave, post-migración. No esperar a tener todo en AWS para empezar.
7. No tener plan de operación post-migración
La migración no termina con el go-live. Termina cuando tu equipo opera la nueva plataforma con confianza, o cuando un partner especializado lo hace por ti con SLA. Sin plan de operación, lo que migraste se degrada en meses.
Cómo evitarlo: definir desde el plan inicial cómo se va a operar lo migrado. Caleidos Lens© 24×7 cubre este gap para muchos clientes — opera tu plataforma AWS post-migración con FinOps + DevOps + AIOps + SecOps + Arquitectura integrados.
El patrón que se repite
Los 7 errores tienen algo en común: vienen de tratar la migración como evento puntual y no como sistema. AWS premia a las empresas que entienden que estar en la nube es una práctica continua, no un proyecto que termina.
¿Estás planificando una migración AWS en tu empresa? Conversemos antes de que empiece. Un assessment temprano cuesta menos que arreglar errores ya cometidos.