¿Qué evaluar antes de migrar cargas de Retail a AWS?

Antes de migrar cargas Retail a AWS, debes evaluar 6 aspectos: infraestructura, aplicaciones, dependencias, criticidad, RTO/RPO y costos. Este análisis permite priorizar cargas, reducir riesgos y construir una estrategia de migración alineada con las necesidades de la operación. 

Una migración a AWS no debería comenzar moviendo servidores. Debería comenzar entendiendo qué existe, cómo funciona y qué impacto tiene cada carga en la operación. 

En Retail esto cobra especial importancia. Un mismo entorno puede integrar POS, ERP, inventarios, ecommerce, CRM, bases de datos, sistemas logísticos y aplicaciones desarrolladas internamente. Algunas funcionan de manera independiente; otras mantienen decenas de conexiones que no siempre están documentadas. 

AWS define la evaluación del portafolio de aplicaciones como un proceso para recopilar información de aplicaciones, infraestructura y contexto de negocio con el objetivo de descubrir, analizar y planificar el movimiento hacia cloud. La evaluación ayuda además a reducir riesgos y costos y a construir planes de migración respaldados por datos. 

Por eso, para un responsable de infraestructura, la pregunta inicial no debería ser: 

“¿Qué servidores vamos a migrar?” 

Sino: 

“¿Qué necesitamos conocer de nuestras cargas antes de decidir cómo y cuándo migrarlas?” 

Estos son seis aspectos que conviene evaluar:

1. Infraestructura 

¿Qué debemos conocer de la infraestructura antes de migrar a AWS? 

Antes de migrar es necesario construir un inventario de servidores, cómputo, memoria, almacenamiento, redes, sistemas operativos y utilización real. Conocer únicamente la capacidad instalada no es suficiente: medir el consumo de CPU, memoria, disco y red permite dimensionar mejor el entorno objetivo en AWS y evitar trasladar el sobreaprovisionamiento existente a cloud. 

El primer paso consiste en entender qué infraestructura soporta realmente las cargas de Retail. 

Esto parece sencillo cuando existe un CMDB actualizado. En la práctica, pueden aparecer servidores heredados, máquinas virtuales con propietarios poco claros, ambientes de desarrollo que permanecieron activos, almacenamiento sobredimensionado o aplicaciones que utilizan infraestructura compartida. 

AWS recomienda establecer una línea base del portafolio donde la infraestructura asociada —incluidos cómputo, almacenamiento y redes— esté identificada y relacionada con las aplicaciones correspondientes. 

Pero hacer un inventario no significa solamente contar servidores. 

Para dimensionar una arquitectura objetivo también es necesario conocer cómo se utilizan. 

Para una operación Retail conviene documentar, entre otros: 

• servidores físicos y virtuales; 

• CPU y memoria asignada frente a utilizada; 

• almacenamiento utilizado y crecimiento; 

• sistemas operativos y versiones; 

• bases de datos; 

• interfaces y componentes de red; 

• licenciamiento; 

• ambientes productivos, desarrollo y pruebas; 

• patrones de demanda; 

• picos por horario, temporada o promoción. 

También es importante observar cuándo aumenta el consumo. Un promedio mensual puede ocultar lo que sucede durante Buen Fin, Navidad o una campaña de alto tráfico.

El objetivo del assessment no es replicar exactamente el data center en AWS, sino entender qué recursos necesita realmente cada workload y determinar la arquitectura más adecuada. Este análisis también ayuda a definir si conviene renovar la infraestructura actual o migrar a cloud, considerando capacidad, escalabilidad, disponibilidad, costos y crecimiento del negocio.

 2. Aplicaciones 

¿Qué debemos analizar de las aplicaciones antes de migrarlas a AWS?

Cada aplicación debe evaluarse por arquitectura, tecnología, ciclo de vida, rendimiento, propietarios, bases de datos y necesidades de negocio. Este análisis permite determinar si conviene migrarla sin cambios, realizar ajustes, modernizarla, sustituirla, mantenerla temporalmente en la infraestructura actual o incluso retirarla. 

Un error frecuente consiste en pensar la migración únicamente en términos de servidores. 

Para el negocio, sin embargo, lo importante son las aplicaciones y servicios que esos servidores hacen posibles. 

Un Retail puede tener un ERP instalado sobre varias máquinas virtuales, un POS conectado con bases de datos centrales, integraciones de inventario, middleware, aplicaciones web, servicios de autenticación y procesos batch que se ejecutan durante la noche. 

Por eso AWS recomienda realizar un assessment detallado que permita comprender tanto la aplicación como la infraestructura asociada de cómputo, almacenamiento y red. 

Este análisis ayuda además a evitar la idea de que migrar significa necesariamente mover todo sin modificaciones. 

AWS utiliza estrategias de migración conocidas como las 7R.Recomienda combinar estas decisiones con información sobre dependencias y complejidad técnica para construir el plan de migración de cada aplicación. 

Esto es especialmente útil en Retail porque no todas las cargas tienen el mismo perfil. 

Un ecommerce que enfrenta cambios fuertes de demanda puede tener necesidades distintas a una aplicación interna con utilización estable. Un ERP heredado puede requerir un tratamiento diferente al de una aplicación web desarrollada recientemente. 

La pregunta, por tanto, no es solamente “¿podemos migrar esta aplicación?”, sino: 

“¿Qué estrategia tiene más sentido para esta aplicación?”

3. Dependencias 

¿Por qué debemos identificar las dependencias antes de migrar cargas de Retail? 

Las dependencias muestran qué aplicaciones, servidores, bases de datos, redes y servicios necesitan comunicarse entre sí. Identificarlas antes de migrar permite agrupar cargas relacionadas, establecer el orden de las olas de migración y reducir el riesgo de interrumpir una integración crítica al mover un componente sin los sistemas de los que depende. 

Este es uno de los puntos que más fácilmente puede subestimarse. 

Imaginemos que TI decide migrar una aplicación de inventarios porque parece sencilla. 

El servidor está identificado, su utilización es conocida y existe una ventana disponible para realizar el cambio. 

Sin embargo, durante la migración aparece algo que no estaba documentado: la aplicación intercambia información con el ERP, consulta una base de datos instalada en otro servidor, utiliza Active Directory y entrega información a una integración logística. 

De pronto, una migración que parecía aislada afecta varios sistemas. 

AWS señala que disponer de información de alta confianza sobre las dependencias es clave para construir las olas de migración. Esa información debe considerar comunicaciones entre sistemas y también dependencias operativas. 

Para Retail, conviene mapear relaciones como: 

• POS ↔ inventarios; 

• ecommerce ↔ inventarios; 

• ERP ↔ bases de datos; 

• ERP ↔ proveedores; 

• CRM ↔ ecommerce; 

• aplicaciones ↔ autenticación; 

• sistemas centrales ↔ sucursales; 

• plataformas ↔ servicios externos; 

• procesos batch ↔ bases de datos y almacenamiento. 

Además de saber qué sistemas se comunican, es importante conocer frecuencia, volumen, protocolos y sensibilidad a latencia para identificar y gestionar dependencias antes de migrar a la nube. 

El resultado debería ser un mapa de dependencias que ayude a construir grupos u olas de migración. 

 4. Criticidad 

¿Cómo determinar qué cargas de Retail son más críticas para la migración? 

La criticidad debe evaluarse según el impacto que tendría una interrupción sobre ventas, tiendas, clientes y procesos internos. POS, ecommerce, inventarios o ERP pueden requerir tratamientos distintos. Clasificar las cargas por impacto permite definir prioridades, ventanas de migración, pruebas, mecanismos de reversión y controles adecuados para cada aplicación. 

No todas las aplicaciones deberían migrarse con el mismo nivel de urgencia ni con el mismo procedimiento. 

Una herramienta interna utilizada por diez personas puede admitir varias horas de indisponibilidad. Un sistema POS que conecta decenas de tiendas probablemente tenga tolerancias muy diferentes. 

Por ello, antes de construir las olas de migración conviene clasificar cada aplicación según su nivel de criticidad y el impacto que tendría una interrupción. 

Crítica: incluye aplicaciones como POS, ecommerce y sistemas de pagos. Una interrupción puede detener ventas o afectar directamente la operación del negocio. 

Alta: considera sistemas como ERP, inventarios y logística. Su indisponibilidad puede afectar procesos centrales y generar retrasos operativos importantes. 

Media: puede incluir CRM, plataformas de analítica y herramientas de reporteo. Una falla afecta la productividad y la toma de decisiones, aunque no necesariamente detiene la operación. 

Baja: abarca ambientes de desarrollo o herramientas internas con impacto limitado. Generalmente pueden tolerar mayores tiempos de recuperación sin comprometer procesos críticos del negocio.

Esta clasificación es ilustrativa: cada empresa debe definirla según su operación. 

AWS recomienda documentar la criticidad, ciclo de vida y ciclo de negocio de las aplicaciones durante el descubrimiento detallado del portafolio. 

Por ello, clasificar criticidad no sirve únicamente para determinar qué es importante. 

Sirve para decidir cómo, cuándo y con qué nivel de control migrarlo. 

Una estrategia responsable puede comenzar con cargas menos críticas, validar procedimientos y automatizaciones y, con esa experiencia, avanzar hacia sistemas centrales.  

5. RTO/RPO 

¿Qué son RTO y RPO y por qué deben definirse antes de migrar a AWS? 

RTO define cuánto tiempo puede permanecer indisponible una aplicación antes de afectar al negocio; RPO establece cuánta información puede perderse como máximo después de una interrupción. Definir ambos antes de migrar ayuda a diseñar respaldos, recuperación ante desastres y arquitectura de disponibilidad según la criticidad real de cada carga. 

Mover una aplicación a cloud no determina automáticamente cuánto tiempo puede tardar en recuperarse. 

Eso debe establecerlo el negocio junto con TI. 

En lugar de preguntar: 

“¿Queremos alta disponibilidad?” 

conviene preguntar: 

“¿Cuánto tiempo puede estar fuera de operación el POS sin generar un impacto inaceptable?” 

Y después: 

“¿Cuántas transacciones podríamos permitirnos perder?” 

Con esas respuestas, los arquitectos pueden evaluar alternativas de respaldo, replicación, recuperación y disponibilidad sobre AWS. 

También ayuda a evitar el sobrediseño. 

Un RTO extremadamente bajo y un RPO cercano a cero pueden requerir arquitecturas más complejas y costosas. No todas las aplicaciones necesitan ese nivel de resiliencia. 

Por eso criticidad, RTO, RPO y costos deben analizarse juntos. 

6. Costos 

¿Qué costos deben evaluarse antes de migrar cargas de Retail a AWS? 

Antes de migrar deben compararse los costos actuales de infraestructura y operación con el escenario objetivo en AWS, incluyendo cómputo, almacenamiento, transferencia, licencias, respaldos, soporte, migración y crecimiento.

El objetivo no es trasladar el costo actual a cloud, sino construir un caso de negocio basado en utilización real y arquitectura adecuada. 

El análisis financiero no debería comenzar preguntando cuánto costaría ejecutar en AWS un servidor idéntico al que existe actualmente. 

Primero hay que entender cuánto cuesta realmente la carga hoy y cuántos recursos utiliza. 

La infraestructura on-premises puede involucrar hardware, almacenamiento, licenciamiento, garantías, soporte, energía, instalaciones, redes, respaldos y tiempo del personal. A esto se suma la capacidad comprada que permanece sin utilizar. 

Después debe modelarse el escenario AWS. 

Aquí el assessment de infraestructura vuelve a ser importante: AWS recomienda utilizar métricas reales de CPU, memoria y disco para realizar right-sizing, en lugar de dimensionar el entorno cloud únicamente según la capacidad asignada actualmente. 

Un caso reciente dentro de Retail muestra la importancia de construir primero el caso de negocio. 

En febrero de 2026, AWS documentó el proyecto de migración de Fanatics Commerce, que contempla aproximadamente 1,800 servidores distribuidos en cinco centros de datos. El programa utilizó assessment, análisis de costos y planificación por olas antes de ejecutar la migración. AWS reporta una proyección de 48% de ahorro en infraestructura, pero es importante precisar que se trata de un ahorro proyectado y no de un resultado final, porque la migración continúa en ejecución. 

Para una empresa Retail de 300 a 500 empleados, el tamaño será diferente, pero el principio es el mismo: 

Primero medir, después modelar y finalmente decidir. 

El análisis también debe contemplar el costo de la propia migración, capacitación, conectividad, operación y posibles cambios de licenciamiento. 

AWS recomienda que el assessment produzca tanto una estrategia de migración por aplicación como un business case detallado y un plan de olas de migración de alta confianza. 

Compucloud, como partner oficial de AWS, puede acompañar esta evaluación para relacionar infraestructura, aplicaciones, dependencias y costos antes de definir la arquitectura objetivo.  

Preguntas frecuentes (FAQ) 

¿Qué debo evaluar primero antes de migrar a AWS? 

Comienza por inventariar aplicaciones e infraestructura y recopilar datos de utilización. Después identifica dependencias, criticidad, RTO/RPO y costos. Esta información permite priorizar workloads y construir las primeras olas de migración. 

¿Cómo puedo identificar dependencias entre aplicaciones? 

Combina documentación y conocimiento de los equipos con herramientas de descubrimiento y monitoreo que permitan observar comunicaciones reales entre componentes. AWS recomienda utilizar datos programáticos para validar las dependencias siempre que sea posible. 

¿Todas las aplicaciones necesitan el mismo RTO y RPO? 

No. Los objetivos deben definirse según criticidad e impacto de negocio. Una aplicación interna puede tolerar tiempos de recuperación mayores que POS, pagos, ecommerce u otros sistemas esenciales. 

¿Cómo saber cuánto costará migrar a AWS? 

Necesitas conocer utilización actual, licencias, almacenamiento, red y costos operativos para después modelar el entorno AWS. El right-sizing evita estimar costos únicamente replicando la capacidad instalada actualmente. 

Conclusión

Una estrategia de migración comienza antes de mover la primera carga

Migrar a AWS no consiste simplemente en trasladar servidores de un lugar a otro. 

Antes de decidir qué migrar, necesitas conocer qué infraestructura tienes, qué aplicaciones soporta, cómo se relacionan, qué tan críticas son, cuánto tiempo pueden permanecer indisponibles y cuánto cuesta operarlas actualmente. 

Ese conocimiento permite construir un roadmap de migración basado en prioridades reales y reducir decisiones improvisadas durante el proceso. 

Como partner oficial de AWS, Compucloud puede ayudarte a evaluar tu entorno y definir una estrategia de migración orientada a seguridad, escalabilidad, resiliencia y optimización de costos. 

👉 Conoce cómo construir una estrategia de migración 

Referencias:

1. AWS Prescriptive Guidance. Application portfolio assessment guide for AWS Cloud migration. 
   Guía para evaluar aplicaciones e infraestructura durante las etapas de descubrimiento, análisis y planificación. 
   https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/introduction.html

2. AWS Prescriptive Guidance. Portfolio analysis and migration planning. 
   Guía sobre inventario, dependencias, estrategias por aplicación, business case y planificación de olas. 
   https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/portfolio-analysis-migration-planning.html 

3. AWS Prescriptive Guidance. Detailed portfolio discovery. 
   Orientación sobre las estrategias 7R, criticidad, dependencias y construcción de grupos de migración. 
   https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/detailed-portfolio-discovery.html

4. Amazon Web Services. Migration at Scale: The Fanatics Commerce AWS Journey. 
   Caso de Retail sobre assessment, planificación y migración a escala de infraestructura hacia AWS. 
   https://aws.amazon.com/blogs/migration-and-modernization/migration-at-scale-the-fanatics-commerce-aws-journey/