Migraciones AWS
Migración a AWS: guía completa de fases, coste y riesgos
Cómo migrar a AWS paso a paso: fases Assess, Mobilize y Migrate, las 7 Rs, landing zone, corte con rollback probado y cuánto cuesta (desde 15.000 €).
En resumen
Una migración a AWS bien hecha pasa por tres fases —evaluar, preparar y migrar— y mueve las cargas por oleadas, con un plan de rollback probado antes de cada corte. La estrategia de cada aplicación (retirar, mover tal cual, replataformar…) se decide en la evaluación, no antes. En SysCu es un proyecto cerrado de 15.000 a 40.000 € (sin IVA) que suele durar 3–4 meses, según el número de cargas y su complejidad.
¿Cuáles son las fases de una migración a AWS?
Trabajamos con las tres fases que también usa AWS en su programa de migraciones: Assess, Mobilize y Migrate. Cada fase tiene un entregable y una condición para pasar a la siguiente; si la condición no se cumple, no se avanza.
| Fase | Qué se hace | Entregable | Para pasar a la siguiente |
|---|---|---|---|
| Assess (evaluar) | Inventario de aplicaciones, servidores, bases de datos y dependencias. Coste actual frente a coste estimado en AWS. Estrategia (R) de cada aplicación. | Inventario, análisis de TCO, business case y plan de oleadas. | Cada aplicación tiene estrategia, dueño y orden de migración. |
| Mobilize (preparar) | Landing zone con AWS Control Tower: cuentas, red, identidades, logs y presupuestos. Migración piloto de una carga no crítica. | Landing zone operativa, arquitectura destino validada y runbooks de migración y rollback. | El piloto funciona en AWS y el rollback se ha ensayado. |
| Migrate (migrar) | Replicación de servidores y bases de datos, pruebas en paralelo, corte por oleadas y vigilancia reforzada tras cada corte. | Cargas en producción en AWS, documentación de la arquitectura final y primer ajuste de tamaños y costes. | Cada oleada estable antes de empezar la siguiente. |
Las tres fases suman normalmente 3–4 meses. Cómo se reparte ese plazo y qué lo alarga lo detallamos en cuánto cuesta y cuánto tarda migrar a AWS una pyme.
¿Qué estrategia elegir para cada aplicación? Las 7 Rs
AWS clasifica las opciones en siete estrategias. No se elige una para toda la empresa: se asigna una a cada aplicación durante la evaluación.
| Estrategia | Qué significa | Cuándo encaja |
|---|---|---|
| Retire | Apagar lo que ya no se usa. | Aplicaciones sin usuarios o duplicadas. Es el ahorro más barato: no se migra. |
| Retain | Dejarlo donde está, de momento. | Sistemas con dependencias o licencias que aún no permiten moverlos, o que se van a sustituir pronto. |
| Rehost | Mover el servidor tal cual a Amazon EC2 (lift and shift). | Lo que funciona bien y hay que sacar del CPD con poco riesgo. Suele ser la vía de entrada en una primera migración. |
| Relocate | Trasladar el entorno de virtualización sin tocar las máquinas. | Parques grandes en VMware que se quieren mover sin cambiar la operación. |
| Repurchase | Sustituir la aplicación por un SaaS. | Correo, CRM o herramientas internas que ya existen como servicio. |
| Replatform | Mover con cambios puntuales, sin reescribir. | Base de datos autogestionada a Amazon RDS, contenedores en Amazon ECS. Mejora clara con riesgo moderado. |
| Refactor | Rediseñar la aplicación para servicios nativos de la nube. | Cuando el negocio necesita escalar o cambiar rápido y el código actual lo impide. Es la opción más cara y lenta. |
En una primera migración, lo que más se repite es retirar lo que sobra, mover tal cual lo que funciona y replataformar solo donde la mejora es evidente, normalmente las bases de datos. Reescribir aplicaciones en mitad de la migración mezcla dos proyectos y dos fuentes de riesgo.
¿Qué hay que preparar antes de mover nada?
La landing zone: el entorno de cuentas, red, identidades y controles donde aterrizarán las cargas. Rehacerla con producción dentro es mucho más caro que construirla primero. Estos son los diez puntos que revisamos antes de la primera carga:
- Cuentas separadas por entorno con AWS Organizations y Control Tower
- Acceso con IAM Identity Center, MFA y mínimo privilegio
- Red: VPC, subredes, rutas y conexión con el CPD (VPN o Direct Connect)
- Registro centralizado con CloudTrail y métricas en CloudWatch
- Detección con GuardDuty y hallazgos en Security Hub
- Cifrado con KMS en reposo y TLS en tránsito
- Etiquetado obligatorio por aplicación, entorno y centro de coste
- AWS Budgets y alertas de anomalías de coste activas
- Copias con AWS Backup y RTO/RPO acordados por aplicación
- Plan de corte y de rollback escrito y ensayado
Si los datos deben quedarse en España, AWS tiene región propia en Aragón (Europa, España). Conviene comprobar en la evaluación que los servicios que necesitas están disponibles en la región elegida.
¿Cómo se mueven las cargas sin parar el negocio?
Por oleadas y con el origen en servicio hasta el último momento:
- Piloto: una carga no crítica para validar red, permisos, herramientas y el propio rollback.
- Replicación continua: los servidores con AWS Application Migration Service (MGN) y las bases de datos con AWS Database Migration Service (DMS), que mantiene los cambios sincronizados mientras el origen sigue en uso.
- Pruebas en paralelo: funcionales, de rendimiento y de seguridad sobre la copia en AWS, antes de mover tráfico.
- Corte en ventana acordada: en horario de poco tráfico y con negocio informado. El rollback está documentado, probado y listo para ejecutarse en menos de 30 minutos.
- Vigilancia reforzada: las 72 horas siguientes al corte, con paneles específicos y guardia dedicada hasta que la carga se estabiliza.
¿Cuánto cuesta y cuánto tarda migrar a AWS?
En SysCu la migración se contrata como proyecto cerrado de 15.000 a 40.000 € (sin IVA) y suele durar 3–4 meses, según el número de cargas y su complejidad. El importe queda fijado por escrito antes de empezar. Fuera del proyecto quedan dos partidas que hay que prever: la factura mensual de AWS y los meses en que conviven el entorno antiguo y el nuevo.
Los precios de todos los servicios están en precios, y el desglose de qué hace subir o bajar el importe, en la guía de coste y plazo para pymes.
¿Qué riesgos tiene una migración a AWS y cómo se controlan?
Los errores más frecuentes, y cómo se evitan:
- Migrar sin inventario. Se mueven aplicaciones que podían retirarse y aparecen dependencias el día del corte. El inventario va antes que cualquier presupuesto.
- Migrar sin landing zone. Cuentas, permisos y red improvisados obligan a rehacer trabajo después. Se construye en Mobilize, antes de la primera carga.
- Mover todo de golpe. Un fallo afecta a todo y no se sabe dónde está. Por oleadas, empezando por lo menos crítico.
- Cortar sin camino de vuelta. Rollback documentado y probado antes de cada corte de producción, y el entorno antiguo disponible hasta validar el nuevo.
- Dejar el coste para el final. Etiquetas y presupuestos desde el primer día, y compromisos de ahorro (Savings Plans) solo con métricas reales.
¿Cómo evitar que la factura de AWS se dispare después?
Con hábitos de FinOps desde la primera carga, no al final:
- Etiquetas obligatorias desde el primer día: sin ellas no se puede imputar el coste a nadie.
- Presupuestos y alertas en AWS Budgets por cuenta y por entorno.
- Tamaños según el consumo medido en origen, no «por si acaso».
- Savings Plans o instancias reservadas solo cuando hay métricas reales de AWS, no con estimaciones.
En proyectos anteriores hemos observado reducciones del 20-40% en la factura de AWS. El resultado depende del punto de partida de cada infraestructura. Cifras medidas con AWS Cost Explorer en proyectos reales de clientes. Los resultados dependen del punto de partida de cada infraestructura y no constituyen garantía de resultados.
¿Es seguro migrar a AWS?
AWS responde de la seguridad de su infraestructura y cuenta con certificaciones como ISO 27001, informes SOC y la certificación del Esquema Nacional de Seguridad (ENS). Lo que se configura dentro de tu cuenta es responsabilidad tuya: es el modelo de responsabilidad compartida. Por eso los controles de seguridad y cumplimiento van en la landing zone desde el principio: mínimo privilegio, MFA, políticas de organización (SCP), cifrado con KMS, CloudTrail y GuardDuty.
Un caso real: e-commerce de on-premise a AWS
Una empresa de e-commerce con caídas en campañas y costes de mantenimiento altos. Diseñamos una arquitectura multi-AZ con autoescalado, movimos bases de datos y aplicaciones críticas con lift and shift durante un fin de semana, con rollback probado, y aplicamos Savings Plans y right-sizing tras el primer mes de métricas reales. Resultado publicado: −40 % de coste en AWS en los primeros seis meses y 99,96 % de disponibilidad sostenida. Es un caso, no una garantía: el resultado depende del punto de partida. Ver el caso completo.
¿Cuándo tiene sentido migrar a AWS (y cuándo no)?
Suele compensar cuando se da alguna de estas situaciones:
- Hay que renovar hardware o el contrato del CPD vence pronto.
- Hay picos de demanda que hoy provocan caídas o sobredimensionar todo el año.
- El equipo dedica más tiempo a mantener servidores que a mejorar el producto.
- Se necesita recuperación ante desastres y montarla en local sale caro.
Y conviene esperar o replantearlo si el hardware es reciente y está amortizándose, si la carga es estable y no tiene picos, o si hay licencias que no permiten ejecutarse en la nube sin un coste nuevo. Una evaluación honesta debe poder concluir «aún no».
Preguntas frecuentes
¿Cuáles son las fases de una migración a AWS?
Tres: evaluar (Assess), preparar (Mobilize) y migrar (Migrate). En la evaluación se inventarían aplicaciones y dependencias y se decide la estrategia de cada una; en la preparación se construye la landing zone y se migra un piloto no crítico; en la migración se mueven las cargas por oleadas, cada una con su plan de rollback probado antes del corte.
¿Cuánto cuesta migrar a AWS?
En SysCu la migración es un proyecto cerrado de 15.000 a 40.000 € (sin IVA) y suele durar 3–4 meses, según el número de cargas y su complejidad. Aparte va la factura mensual de AWS, que se estima carga a carga durante la evaluación, y el periodo en que conviven el entorno antiguo y el nuevo.
¿Qué estrategia de migración a AWS conviene elegir?
Se decide aplicación por aplicación con las 7 Rs de AWS: Retire, Retain, Rehost, Relocate, Repurchase, Replatform y Refactor. Lo habitual es retirar lo que no se usa, mover tal cual (Rehost) lo que funciona y replataformar solo donde hay una mejora clara, como pasar una base de datos autogestionada a un servicio gestionado.
¿Se puede migrar a AWS sin parar el negocio?
Se puede reducir la parada a una ventana corta y acordada. Los servidores se replican de forma continua con AWS Application Migration Service y las bases de datos con AWS Database Migration Service, de modo que el origen sigue en servicio hasta el corte. El corte se hace en horario de poco tráfico y con un rollback documentado y probado de antemano.
¿Qué herramientas de AWS se usan en una migración?
Las más habituales son AWS Control Tower para la landing zone, AWS Application Migration Service (MGN) para servidores, AWS Database Migration Service (DMS) para bases de datos, con su conversión de esquemas cuando cambia el motor, y la calculadora de precios de AWS para estimar la factura antes de mover nada.
¿AWS financia parte de la migración?
AWS tiene un programa para migraciones, el Migration Acceleration Program (MAP), que se tramita a través de un partner. Si un proyecto recibe financiación, las condiciones las fija AWS según el caso, así que conviene no presupuestar contando con ella hasta que esté confirmada.
Validación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Definir baseline técnico antes de cambios (rendimiento, coste y fiabilidad).
- Ejecutar pruebas controladas en preproducción con criterios de aceptación explícitos.
- Validar rollback y tiempos de recuperación en un escenario realista.
- Comparar resultados de 2-4 semanas con la línea base y documentar desviaciones.
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Establecer punto de partida comparable | Recolectar 14 días de datos y congelar alcance del cambio | Métricas base validadas por negocio y tecnología |
| Hipótesis | Definir mejora esperada y riesgo aceptable | Redactar hipótesis cuantitativa por métrica | Objetivo numérico y criterio de rollback acordados |
| Validación | Probar en entorno realista sin afectar clientes | Canary o experimento controlado con observación mínima de 7 días | Sin regresiones críticas y mejora en 1-2 KPIs |
| Escalado | Extender cambio a todo el servicio | Despliegue gradual con checkpoints diarios | Resultado estable durante una ventana completa de operación |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Tiempo de respuesta p95 | APM + Synthetic | Diario | Sin regresión > 10% |
| Error rate | Logs + Alerting | Horario | < 1% |
| Tiempo medio de recuperación (MTTR) | Incidentes | Semanal | Tendencia descendente |
| Coste operativo unitario | Cost Explorer / BI | Semanal | Estable o a la baja |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Calidad de despliegue | CI/CD + incidencias | Diario | CFR < 15% y rollback < 5% |
| Fiabilidad servicio | SLI/SLO + alertas | Cada hora | Error budget consumido < 75% |
| Coste operativo | Cost Explorer / CUR | Diario | Desviación mensual < 10% |
| Experiencia usuario | RUM + analytics | Diario | Sin caída en conversión o engagement |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
Línea base y alcance cerrados.
Primeras mejoras medibles sin impacto operativo negativo.
Estabilización y reducción de variabilidad.
Operación repetible con evidencias sostenidas.
Riesgos que invalidan resultados
- Medir solo una semana: la variabilidad puede sesgar el resultado.
- Comparar entornos distintos (staging vs producción) como si fueran equivalentes.
- No separar impacto por tipo de cliente, producto o servicio crítico.
- Cerrar iniciativas sin dejar artefactos verificables (dashboard, runbook y postmortem).
Recomendaciones de implementación real
- Evitar decisiones por intuición: sin baseline, no hay mejora demostrable.
- Definir un owner técnico por cada acción de mejora y fecha de cierre.
- Mantener trazabilidad de cambios (qué se cambió, por qué, impacto esperado).
- No cerrar un hito sin evidencia objetiva de resultado.
Preguntas frecuentes que suele hacer un equipo técnico
¿Cuánto tiempo tarda en verse una mejora real?
En la mayoría de equipos, los primeros resultados fiables aparecen entre 4 y 8 semanas cuando hay métricas base, ownership y disciplina de seguimiento semanal.
¿Qué métrica debería priorizar primero?
La métrica con mayor impacto económico o de riesgo operativo en tu negocio. Normalmente: coste unitario, tasa de error o lead time de cambios.
¿Cómo demostrar que la mejora no fue casualidad?
Con un diseño de experimento simple: baseline estable, hipótesis cuantificada, ventana de validación y comparación con variables controladas.