7 preguntas que deberías hacerle a un partner antes de migrar a AWS

Antes de elegir un partner para migrar a AWS, pregunta cómo identificará dependencias, priorizará cargas, minimizará el downtime, estimará costos, qué experiencia tiene, cómo medirá el éxito y qué soporte brindará después de la migración. Sus respuestas permiten evaluar metodología, experiencia y capacidad de acompañamiento. 

Elegir un partner para una migración a AWS no debería depender únicamente de una propuesta económica o de cuántos servicios cloud conoce su equipo. 

Para una empresa Retail, el partner participará en decisiones que pueden afectar aplicaciones críticas, bases de datos, POS, ecommerce, ERP, inventarios y otros sistemas que sostienen la operación diaria. 

Por eso, antes de elegirlo, es importante entender cómo piensa ejecutar la migración.

AWS señala que una planificación de migración efectiva requiere una visión del portafolio de aplicaciones, infraestructura asociada, dependencias y estrategia para cada aplicación. Esta información permite organizar las cargas en olas de migración y reducir riesgos durante el proceso.

Además, AWS recomienda considerar especialistas de AWS Migration Competency Partners para apoyar este tipo de procesos. La competencia identifica partners cuyas capacidades de migración y modernización han sido validadas. 

Antes de seleccionar quién acompañará tu proyecto, estas son siete preguntas que vale la pena poner sobre la mesa. 

 1. ¿Cómo identificarán mis dependencias? 

Un partner debería explicar cómo identificará las relaciones entre aplicaciones, servidores, bases de datos, APIs, redes y servicios antes de mover una carga. La respuesta debe incluir inventario, descubrimiento técnico y validación con los equipos internos, porque una dependencia no detectada puede generar problemas de conectividad, rendimiento o disponibilidad durante la migración. 

Imagina que decides migrar el sistema de inventarios de tu operación Retail. 

A primera vista puede parecer una aplicación independiente. Sin embargo, podría intercambiar información con el ERP, ecommerce, POS, proveedores, servicios de autenticación y bases de datos alojadas en otros servidores. 

Mover solamente una parte sin entender esas conexiones puede generar problemas después del corte. 

Por eso una buena respuesta a esta pregunta no debería ser simplemente: 

“Revisaremos la infraestructura”. 

El partner debería explicar qué información recopilará y cómo comprobará las relaciones entre sistemas. 

AWS recomienda considerar dependencias de infraestructura, aplicaciones, negocio y operación al construir los grupos de migración. También señala que las herramientas de descubrimiento pueden complementar el conocimiento de los responsables de aplicaciones y equipos técnicos. 

La evaluación puede considerar: 

• aplicaciones y servidores

• bases de datos compartidas

• APIs e integraciones

• puertos y protocolos

• frecuencia de comunicación

• transferencia de datos

• sensibilidad a latencia 

• autenticación y servicios compartidos

• ventanas operativas

El objetivo es construir un mapa de dependencias que permita saber qué componentes pueden migrarse de forma independiente y cuáles deberían permanecer juntos dentro de una misma ola. 

Si quieres profundizar en este punto, consulta nuestra guía sobre cómo identificar y gestionar dependencias antes de migrar a la nube. 

Una señal positiva es que el partner pueda explicar claramente cómo descubrirá, documentará y validará las dependencias antes de definir el orden de migración. 

2. ¿Qué cargas recomiendan migrar primero? 

Un partner debería priorizar las cargas según complejidad, criticidad, dependencias, riesgo y objetivos de negocio. Migrar primero la aplicación más importante no siempre es la mejor decisión. Las primeras olas pueden utilizar cargas menos complejas para validar herramientas, procedimientos y responsabilidades antes de abordar sistemas críticos para la operación Retail. 

Supongamos que tu infraestructura incluye POS, ERP, inventarios, ecommerce, CRM, bases de datos y aplicaciones internas. 

¿Por dónde comenzar? 

Una respuesta como “primero migremos todo lo que sea fácil” es insuficiente. Pero también lo sería comenzar automáticamente por la aplicación que genera mayor valor. 

AWS recomienda utilizar las primeras olas para adquirir experiencia. Su guía de planificación propone comenzar con pocas aplicaciones y servidores de menor complejidad, incorporando progresivamente cargas más complejas conforme el equipo aprende del proceso. 

El partner debería poder construir una priorización considerando factores como: 

• criticidad para el negocio

• complejidad técnica

• dependencias

• facilidad de migración

• requisitos de disponibilidad

• ventanas permitidas

• estrategia de migración

• riesgo operativo 

En Retail existe además un elemento que no puede ignorarse: el calendario comercial. 

Migrar una aplicación crítica cerca de Buen Fin, Navidad, cierres de inventario o una campaña importante puede introducir riesgos que podrían evitarse mediante una mejor planificación.

Las olas deben considerar tanto las dependencias técnicas como restricciones operativas, fechas de negocio y disponibilidad de los responsables de las aplicaciones. 

Esto significa que el partner debería ser capaz de explicar no solamente qué migraría primero, sino por qué, cuándo y qué aprendizaje espera obtener de esa primera ola. 

Una estrategia sólida transforma el portafolio completo en grupos manejables y permite aplicar las lecciones de las primeras migraciones en las siguientes.  

3. ¿Cómo se minimizará el downtime? 

Un partner debería explicar qué ventana de interrupción requiere cada carga y cómo planea reducirla mediante replicación, pruebas, runbooks, sincronización, validación y planes de rollback. No todas las aplicaciones pueden migrarse sin interrupciones, por lo que una respuesta responsable debe definir el downtime esperado y cómo se protegerá la continuidad del negocio. 

Esta pregunta es especialmente importante cuando hablamos de POS, ecommerce, ERP, pagos o inventarios. 

En estos sistemas, una interrupción puede afectar directamente la operación. 

Pero existe una diferencia importante entre preguntar “¿habrá downtime?” y preguntar “¿cómo lo van a minimizar y controlar?” 

AWS identifica el cutover como una de las etapas más críticas de una migración, porque es cuando el tráfico pasa del entorno existente a los nuevos recursos en AWS. El tiempo y la complejidad del proceso dependen de la arquitectura, criticidad, tecnología y requerimientos del negocio. 

Antes del corte, AWS recomienda definir elementos como: 

• downtime requerido

• impacto de exceder la ventana

• sincronización de datos

• pruebas funcionales

• pruebas de rendimiento

• validación de integraciones

• responsables de cada actividad

• procedimiento de rollback

• contingencias ante fallas. 

Un partner también debería preguntar por tus objetivos RTO y RPO, especialmente para cargas críticas. 

Estos indicadores ayudan a establecer cuánto tiempo puede tolerar el negocio una interrupción y cuánta pérdida de información sería aceptable. 

Una promesa de “cero downtime” sin analizar primero la aplicación, la base de datos y sus dependencias aporta poca información. 

Una respuesta más útil debería explicar qué interrupción se espera, cómo se probará el procedimiento y qué ocurrirá si el cutover no sale según lo planeado. 

 4. ¿Cómo se estimarán los costos? 

Un partner debería estimar costos a partir del consumo real, arquitectura objetivo, almacenamiento, transferencia, licencias y estrategia de migración. También debería comparar el escenario AWS con el costo actual y considerar los gastos del propio proyecto. Replicar en cloud el tamaño de los servidores actuales puede trasladar a AWS un sobreaprovisionamiento existente. 

Preguntar “¿cuánto me costará AWS?” parece sencillo. 

En realidad, detrás de esa cifra hay varias decisiones.

Una estimación confiable requiere entender cuánto consume cada carga, qué servicios utilizará, cómo crecerá y qué estrategia de migración necesita. 

AWS indica que un business case puede comparar el TCO de la infraestructura actual frente a la arquitectura posterior a la migración. Para análisis más detallados pueden incorporarse ROI, periodo de recuperación y flujos de efectivo a varios años. 

Además, AWS incluye entre los datos relevantes del assessment aspectos como: 

• costo actual

• costo por estrategia de migración

• herramientas

• landing zone

• capacitación

• duración del proyecto

• costos paralelos durante la transición. 

Esto último es fácil de olvidar. 

Durante cierto periodo pueden coexistir costos de la infraestructura actual y del nuevo entorno AWS. 

También hay que considerar licencias, almacenamiento, transferencia de datos, respaldos, soporte y crecimiento esperado. 

Por ello, una buena estimación no debería limitarse a:

Servidor actual = instancia equivalente en AWS. 

El partner debería buscar oportunidades de right-sizing y optimización desde la etapa de evaluación. 

La pregunta clave para el partner es: 

¿Qué datos utilizarán para construir la estimación y qué supuestos están incluidos? 

Cuanto más transparente sea esa respuesta, más útil será el business case para tomar decisiones. 

 5. ¿Qué experiencia tienen en AWS? 

Antes de elegir un partner, conviene revisar su nivel dentro de AWS Partner Network, competencias, certificaciones, casos de éxito y experiencia en proyectos similares. Una designación de AWS aporta evidencia adicional porque determinadas competencias y programas requieren demostrar capacidades técnicas y experiencia; aun así, debe complementarse con referencias relevantes para tu proyecto. 

“Tenemos experiencia en cloud” no responde esta pregunta. 

Tampoco basta con saber que una empresa ha trabajado anteriormente con AWS. 

La pregunta debe llevar a evidencia verificable. 

AWS explica que su Competency Program identifica y valida partners que han demostrado experiencia técnica y éxito con clientes en áreas especializadas. Para Migration and Modernization Competency, las ofertas de los partners se validan frente a prácticas de AWS. 

Por eso conviene preguntar: 

• ¿Qué nivel tienen dentro de AWS Partner Network? 

• ¿Qué competencias AWS poseen? 

• ¿Cuentan con especialistas certificados? 

• ¿Han realizado migraciones de cargas similares? 

• ¿Pueden mostrar casos de éxito? 

• ¿Tienen experiencia con arquitecturas híbridas? 

• ¿Pueden acompañar la operación después de migrar? 

También es importante evaluar si su experiencia corresponde al tipo de proyecto que estás planeando. 

Migrar un sitio web no implica necesariamente la misma complejidad que trasladar ERP, bases de datos, ecommerce, POS y aplicaciones integradas entre sí. 

En el caso de Compucloud, su sitio documenta su participación en el AWS Well-Architected Partner Program y su certificación como Managed Service Provider, orientada a proporcionar servicios AWS durante distintas etapas del proceso cloud. 

Además, Compucloud se presenta como AWS Partner Advanced y Managed Service Provider certificado, con acompañamiento desde la evaluación hasta la optimización del entorno cloud. 

La experiencia debería poder comprobarse, no solamente afirmarse. 

Por eso pide al partner credenciales, metodología, referencias y casos comparables con la complejidad de tu operación.  

6. ¿Cómo medirán el éxito? 

El éxito de una migración no debería medirse únicamente por el número de servidores trasladados. Antes de comenzar, el partner y la empresa deberían acordar indicadores técnicos, operativos y financieros que permitan comprobar disponibilidad, rendimiento, seguridad, costos y cumplimiento de los objetivos que justificaron la migración. 

“Los servidores ya están en AWS”. 

¿Eso significa que la migración fue exitosa? 

Técnicamente puede significar que el traslado terminó, pero no necesariamente que se alcanzaron los resultados esperados. 

Antes de migrar, el partner debería preguntar: 

¿Qué problema queremos resolver? 

Por ejemplo: 

• mejorar disponibilidad

• reducir tiempos de aprovisionamiento

• soportar temporadas pico

• disminuir tareas manuales

• mejorar recuperación ante fallas

• optimizar costos

• aumentar visibilidad del entorno. 

Después deben definirse indicadores para comprobar esos objetivos. 

AWS recomienda alinear las olas de migración con resultados y business drivers, de modo que completar una ola represente un logro medible. 

Después del cutover, AWS también recomienda establecer dashboards que permitan observar métricas y SLIs relacionados con disponibilidad, seguridad, tráfico y otros parámetros relevantes para validar que la aplicación funciona como se esperaba. 

Para una operación Retail, algunos indicadores podrían incluir: 

Disponibilidad: ¿la aplicación cumple el objetivo definido? 

Rendimiento: ¿cómo se comporta durante horarios y temporadas de mayor demanda? 

Continuidad: ¿se cumplen RTO y RPO? 

Costos: ¿el consumo corresponde al escenario proyectado? 

Operación: ¿disminuyeron determinadas tareas manuales? 

Seguridad: ¿los controles definidos están implementados y monitoreados? 

No todos estos KPIs aplicarán a todas las cargas. 

Lo importante es establecer una línea base antes de migrar para poder comparar después. 

Si un partner no puede explicar cómo comprobará que el nuevo entorno cumple los objetivos del proyecto, será difícil distinguir entre una migración terminada y una migración que realmente generó valor. 

7. ¿Qué sucede después de la migración? 

La migración no termina con el cutover. Después deben validarse aplicaciones, monitorear rendimiento y costos, atender incidentes, documentar el entorno, transferir conocimiento y continuar optimizando. Antes de contratar un partner, pregunta quién será responsable de estas actividades y durante cuánto tiempo acompañará la estabilización y operación del nuevo entorno AWS. 

Esta pregunta ayuda a descubrir algo importante: 

¿El partner está contratado únicamente para mover las cargas o también existe un plan para operarlas después? 

AWS contempla una fase de hypercare o post-migración en la que los equipos de migración permanecen disponibles para apoyar la operación, resolver problemas y aplicar optimizaciones. Después se revisan métricas, aprendizajes y resultados antes de cerrar formalmente la ola. 

AWS también recomienda establecer monitoreo después del cutover para validar que la aplicación mantenga la disponibilidad, seguridad, tráfico y calidad esperados. 

Por eso deberías preguntar quién realizará actividades como: 

• monitoreo

• respuesta a incidentes

• optimización de costos 

• actualizaciones

• seguridad

• respaldos

• documentación

• transferencia de conocimiento

También es importante entender cómo se entregará el proyecto al equipo interno. 

¿Habrá documentación? 

¿Se capacitará al personal? 

¿Existirá un periodo de acompañamiento?

¿Quién atenderá una incidencia semanas después? 

Compucloud plantea la migración como un proceso que incluye evaluación, diseño, implementación y optimización continua después de completar la transición. 

Su condición de Managed Service Provider de AWS también permite extender el acompañamiento hacia la administración y mejora del entorno después de migrar. El partner que elijas debería ayudarte a responder una última pregunta: 

¿Quién se hará responsable de que el entorno siga funcionando, evolucionando y optimizándose después del go-live? 

¿Qué deberías esperar de las respuestas de un partner AWS? 

Las siete preguntas tienen algo en común. 

No buscan una respuesta de sí o no. 

Buscan descubrir la metodología detrás del proyecto. 

Un partner debería poder explicar cómo realizará el assessment, qué datos necesita, cómo construirá las olas, qué riesgos contempla, qué ocurrirá durante el cutover y cómo comprobará los resultados después de la migración. 

Antes de tomar una decisión, busca respuestas concretas sobre: 

Dependencias: cómo serán identificadas y validadas. 

Priorización: qué criterios definirán las primeras cargas. 

Downtime: cuál es la ventana estimada y cómo se reducirá el riesgo. 

Costos: qué información y supuestos sustentan la estimación. 

Experiencia: qué credenciales y proyectos respaldan al equipo. 

Resultados: qué KPIs se medirán antes y después. 

Post-migración: quién operará, monitoreará y optimizará el entorno. 

AWS recomienda que la planificación contemple dependencias, herramientas, olas, responsabilidades, seguridad, conectividad y modelo operativo antes de ejecutar la migración. 

En otras palabras, un buen partner no debería empezar preguntando cuándo quieres mover los servidores. Primero debería entender por qué migras, qué estás moviendo y qué necesita proteger el negocio durante el proceso. 

Preguntas frecuentes (FAQ)

¿Por qué trabajar con un partner para migrar a AWS? 

Un partner especializado puede aportar experiencia, metodología y especialistas para evaluar, diseñar y ejecutar la migración. AWS recomienda considerar Migration Competency Partners cuando se necesita apoyo especializado durante el proceso. 

¿Cómo saber si un partner tiene experiencia real en AWS? 

Revisa su perfil en AWS Partner Network, competencias, programas, certificaciones del equipo, casos de éxito y experiencia con cargas similares a las tuyas. Solicita evidencia verificable en lugar de basarte únicamente en afirmaciones comerciales. 

¿Un partner puede garantizar una migración sin downtime? 

Depende de la arquitectura y los requisitos de cada carga. AWS indica que el downtime y la complejidad del cutover dependen, entre otros factores, de criticidad, tecnología y requerimientos del negocio. 

¿Qué debe incluir una propuesta de migración a AWS? 

Debería explicar alcance, assessment, estrategia por cargas, dependencias, arquitectura objetivo, olas, cutover, responsabilidades, costos, pruebas, rollback y soporte post-migración. El nivel de detalle dependerá de la complejidad del proyecto. 

¿El trabajo del partner termina cuando las cargas están en AWS? 

No necesariamente. Conviene definir desde el contrato quién gestionará hypercare, monitoreo, incidentes, seguridad, costos y optimización. AWS contempla explícitamente actividades de post-migración y estabilización dentro de la planificación de olas. 

Antes de elegir quién migrará tus cargas, conoce cómo trabaja 

Una migración a AWS requiere mucho más que mover infraestructura. 

Requiere entender dependencias, priorizar aplicaciones, controlar el downtime, construir un modelo de costos, establecer métricas y preparar la operación posterior. 

Por eso, antes de elegir un partner, pide que te explique cómo realizará cada una de estas actividades en tu entorno. 

Como partner oficial de AWS, Compucloud acompaña a las organizaciones desde la evaluación y planificación hasta la migración y optimización del entorno, con foco en seguridad, escalabilidad, continuidad y control de costos. 

👉 Conoce cómo trabajamos una migración AWS 

Referencias:

1. AWS Prescriptive Guidance. Wave planning. 
   Buenas prácticas para construir olas de migración a partir de aplicaciones, infraestructura, dependencias y prioridades. 
   https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/wave-planning.html 

2. AWS Prescriptive Guidance. Defining the wave planning process. 
   Orientación sobre dependencias, move groups, priorización y construcción de olas de migración. 
   https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-portfolio-playbook/wave-planning.html 

3. AWS Partner Network. Introducing AWS Migration and Modernization Competency Partners. 
   Información sobre la validación de capacidades técnicas y experiencia de partners especializados en migración y modernización. 
   https://aws.amazon.com/blogs/apn/introducing-aws-migration-and-modernization-competency-partners/ 

4. Compucloud. Migración a AWS en México: la guía central de Compucloud. 
   Contenido sobre evaluación, planificación, ejecución y optimización continua de una migración. 
   https://www.compucloud.com.mx/blog/guia-migracion-aws-mexico/ 

5. Compucloud. ¿Qué es la migración a la nube? Beneficios, estrategias y cómo planificar una migración exitosa. 
   Información sobre el acompañamiento de Compucloud y sus credenciales como AWS Partner Advanced y Managed Service Provider. 
   https://www.compucloud.com.mx/blog/blog-que-es-la-migracion-a-la-nube/