4 errores comunes al migrar al Cloud

Spain, May 7, 2025

Observamos a diario muchos errores que las organizaciones cometen al tratar de migrar a la nube de AWS. Equivocaciones que se repiten constantemente y que desencadenan en fracasos bastante notorios. A lo largo de este blog comentamos qué errores debes evitar para tener éxito en la migración. ¡Sigue leyendo para saber más información!

  1. AWS no es On-Prem

Este suele ser el error más habitual, AWS probablemente sea el cloud más orientado a la infraestructura y esto hace que en muchos casos tendamos a pensar que AWS funciona igual que On-Prem.

Hay muchos elementos en AWS que son muy similares a lo que ya existe en nuestro On-Prem y podemos tener la tentación de hacer una translación 1 a 1 y montar las mismas arquitecturas que ya tenemos desplegadas. En cierta medida es posible, pero cada servicio de AWS es más que un solo elemento en On-Prem. Tienen más capacidades y son bastante complejos.

Por ejemplo, un S3 en AWS no es un servicio que tenga un par de cabinas que permitan presentar el almacenamiento como objetos, sino que es un servicio formado por más de 300 microservicios interconectados entre sí.

Esto en la práctica implica que en muchas ocasiones utilicemos mal los servicios de AWS por intentar igualarlos a On-Prem.

  1. Lift, Shift and Run Away

El Segundo error es pensar que con hacer un Lift and Shift ya has terminado la migración a la nube. AWS propone 7 estrategias para migrar al cloud, conocidas como las 7Rs, pero en la mayoría de los casos solo se usa una: Re-hosting, también llamada Lift and Shift. Es decir, mover tus aplicaciones tal cual están a la nube, sin cambiar nada. 

Es una estrategia válida y de entrada puede parecer que todo son ventajas: costes competitivos, más elasticidad, mayor disponibilidad y facilidad para evolucionar.

Sin embargo, estos beneficios iniciales se van diluyendo con el paso del tiempo debido a que estás trasladando a la nube los mismos sistemas que tenías on-premise. Algunos de los problemas con los que te puedes encontrar son:

  • Estrategias de backup poco eficientes que disparan el coste
  • Tráfico innecesario entre zonas o regiones
  • Aplicaciones que no escalan bien o dependen de procesos manuales.

Así pues, la estrategia Lift and Shift necesita ir acompañada de un plan de modernización como por ejemplo el programa MAP (Migration Acceleration Program) de AWS.

Image

 

  1. Gestión de costes

Otro error habitual es cómo se gestionan los costes en AWS. En muchas migraciones a la nube se repite el modelo On-prem, dejando la responsabilidad de los costes al departamento financiero. En AWS, los costes están ligados al uso técnico de los servicios, y una mala configuración puede dispararlos.

Si los equipos técnicos no tienen visibilidad ni responsabilidad sobre esos costes, no pueden optimizarlos. Es común encontrar recursos como notebooks de SageMaker encendidos sin uso, generando gastos innecesarios.

La solución: dar visibilidad y responsabilidad de costes a los equipos técnicos. Solo así podrán detectar y corregir ineficiencias, muchas veces con ajustes simples en la arquitectura.

Image
  1. Mala optimización de costes

En la misma línea nos podemos encontrar problemas de eficiencia por un uso excesivo de EC2 Instance Savings Plans.

Los EC2 Instance Savings Plans o las reservas de instancias (en la práctica son muy similares) son bastante habituales y se parecen mucho a una amortización de Hardware.

Podemos comprar a 3 años, pero podemos cometer el error de reservar una infraestructura a 3 años que no vamos a usar.

Muchas veces se enfoca como un problema financiero, pero imaginémonos que vamos a refactorizar nuestras cargas para que sean serverless, pero tenemos una reserva a 3 años, de forma que, aunque hemos realizado un trabajo para reducir el coste, no lo podemos aplicar porque tenemos una reserva a largo plazo.

Es importante que las reservas se realicen sabiendo el ciclo de vida de nuestras aplicaciones, así como las posibles optimizaciones que podemos tener.

En la mayoría de ocasiones tendemos a utilizar los EC2 Instance Savings Plans que nos dan más descuento que un Compute Savings Plan, pero son más inflexibles.

Migrar a la nube de AWS no es solo un cambio tecnológico, es un cambio de mentalidad. Repetir modelos heredados, ignorar la modernización o desvincular los costes del uso técnico puede salir caro.

La nube ofrece muchas ventajas, pero solo si sabemos cómo aprovecharlas. Apostar por la formación, la planificación y una buena colaboración entre equipos técnicos y financieros es el primer paso para que una migración a AWS no sea solo un traslado… sino modernizar y adaptar nuestra forma de trabajar.

Artículo redactado por Miguel Ángel Muñoz, Cloud Architect and AWS Ambassador.

Topic

Related Insights