Migración a AWS: plan paso a paso sin downtime

Migrar a AWS no es mover archivos de un servidor a otro. Es rediseñar cómo tu aplicación se ejecuta, escala y se recupera de fallos. Una migración mal planificada resulta en downtime, pérdida de datos o, en el mejor de los casos, una factura de cloud que triplica lo que pagabas en tu infraestructura anterior.

Según un informe de Gartner, el 60% de las organizaciones que migran a la nube experimentan sobrecostes significativos en los primeros 18 meses. La causa principal no es la tecnología: es la planificación insuficiente.

Este artículo detalla un plan de migración paso a paso, con las herramientas que AWS proporciona, los costes reales de cada fase y las decisiones que determinan si tu migración termina en semanas o se arrastra durante meses.

Por qué migrar a AWS

Los motivos reales vs los motivos de marketing

AWS ofrece más de 200 servicios, disponibilidad global en 33 regiones, y una infraestructura que escala desde un prototipo hasta millones de usuarios. Pero esos son argumentos de vendedor. Los motivos reales para migrar son más concretos:

Costes variables vs costes fijos: En infraestructura on-premise, pagas por capacidad máxima. Un servidor que necesitas solo durante picos de Black Friday está encendido todo el año. En AWS, pagas por lo que usas. Si tu tráfico es variable, la diferencia puede ser del 40-70%.

Velocidad de aprovisionamiento: Crear un servidor on-premise toma semanas (pedido, envío, montaje, configuración). En AWS, una instancia EC2 está lista en 90 segundos. Para startups que necesitan iterar rápido, esa diferencia es existencial.

Servicios gestionados: En on-premise, tu equipo gestiona el sistema operativo, los parches de seguridad, las copias de respaldo, la monitorización y el escalado. En AWS, servicios como RDS, Aurora o DynamoDB eliminan esa carga. Tu equipo se centra en la aplicación, no en mantener la infraestructura funcionando.

Cumplimiento normativo: AWS tiene certificaciones SOC 2, ISO 27001, HIPAA, GDPR y PCI DSS, entre otras. Conseguir esas certificaciones para tu propio datacenter cuesta cientos de miles de euros y meses de auditoría.

Cuándo no tiene sentido migrar

La migración a AWS no es la respuesta correcta para todos:

• Cargas de trabajo constantes y predecibles: Si tu aplicación consume exactamente los mismos recursos las 24 horas del día, 365 días al año, un servidor dedicado puede ser más económico.
• Requisitos de latencia extrema: Aplicaciones de trading de alta frecuencia o procesamiento de señales en tiempo real pueden necesitar hardware dedicado en ubicaciones específicas.
• Dependencia de hardware especializado: GPUs específicas, FPGAs o hardware propietario que AWS no ofrece.
• Restricciones regulatorias: Algunos sectores (defensa, gobierno) tienen requisitos de localización de datos que limitan las opciones cloud.

Las 7 estrategias de migración (las 7 Rs)

AWS define siete estrategias de migración. La elección correcta depende de cada aplicación, no de la organización como un todo. Es normal usar diferentes estrategias para diferentes componentes del mismo sistema.

Rehost (lift and shift)

Mover la aplicación tal cual a AWS, sin cambios en el código. Copias la máquina virtual a una instancia EC2, la base de datos a RDS, y los archivos a S3.

Cuándo usarla: Cuando necesitas migrar rápido, tienes decenas de servidores, y no tienes presupuesto para refactorizar.

Herramienta principal: AWS Application Migration Service (MGN). Replica tus servidores en tiempo real a AWS. Cuando estés listo, haces el cutover: el tráfico se redirige a AWS con un downtime mínimo de minutos.

# Instalar el agente de replicación en el servidor origen
wget -O ./aws-replication-installer-init \
  https://aws-application-migration-service-us-east-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init
chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init \
  --region us-east-1 \
  --aws-access-key-id AKIAIOSFODNN7EXAMPLE \
  --aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Ventaja: Velocidad. Puedes migrar cientos de servidores en semanas.

Desventaja: No aprovechas los servicios nativos de AWS. Estás pagando por EC2 lo mismo (o más) que pagabas en tu datacenter.

Replatform (lift, tinker and shift)

Mover la aplicación con ajustes menores para aprovechar servicios gestionados. Por ejemplo: la aplicación se mueve a EC2, pero la base de datos MySQL se migra a RDS MySQL.

Cuándo usarla: Cuando quieres reducir la carga operativa sin reescribir código.

Ejemplo práctico: Tu aplicación usa PostgreSQL en un servidor dedicado. En lugar de instalar PostgreSQL en EC2, usas RDS PostgreSQL. El código de la aplicación no cambia (misma cadena de conexión, mismo driver), pero ahora AWS gestiona los backups, las actualizaciones del motor y la alta disponibilidad con Multi-AZ.

Refactor (re-architect)

Rediseñar la aplicación para aprovechar servicios nativos de AWS. Convertir un monolito en microservicios, migrar de una base de datos relacional a DynamoDB, o reemplazar un servidor de colas por SQS.

Cuándo usarla: Cuando la aplicación tiene problemas de escalabilidad que la arquitectura actual no puede resolver, o cuando los costes de operar la arquitectura actual son insostenibles.

Ejemplo práctico: Una aplicación monolítica en Java que procesa imágenes. En lugar de escalar verticalmente (más CPU, más RAM), extraes el procesamiento de imágenes a funciones Lambda que escalan horizontalmente de forma automática. El coste pasa de una instancia m5.4xlarge (615 dolares/mes) a pagar solo por las invocaciones reales.

Repurchase

Reemplazar la aplicación existente por un producto SaaS. Migrar de un servidor de correo propio a Amazon WorkMail o de un CRM on-premise a Salesforce.

Retire

Identificar aplicaciones que ya no se usan y apagarlas. En auditorías de migración, es habitual encontrar que entre el 10% y el 20% de los servidores ejecutan aplicaciones obsoletas.

Retain

Mantener la aplicación en su ubicación actual. No todo tiene que migrar a AWS. Algunas aplicaciones legacy con dependencias de hardware específico o con planes de decomisionado a corto plazo no justifican el coste de migración.

Relocate

Mover máquinas virtuales de VMware directamente a VMware Cloud on AWS. Útil para organizaciones con grandes inversiones en VMware que quieren los beneficios de AWS sin cambiar la plataforma de virtualización.

Plan de migración paso a paso

Fase 1: Evaluación y descubrimiento (2-4 semanas)

Antes de migrar un solo servidor, necesitas entender qué tienes. En la mayoría de organizaciones, el inventario de servidores está incompleto o desactualizado.

AWS Application Discovery Service escanea tu red y cataloga servidores, aplicaciones, dependencias y patrones de comunicación. Hay dos modos:

• Agent-based: Instala un agente en cada servidor. Captura procesos, conexiones de red, uso de CPU/memoria/disco. Datos más detallados pero requiere acceso a cada máquina.
• Agentless: Escanea la red desde un appliance virtual. Captura información básica de servidores VMware sin instalar nada. Menos detalle, más rápido.

Entregable de esta fase: Un mapa de dependencias que muestre qué aplicaciones se comunican entre sí, qué puertos usan, y qué bases de datos consultan. Sin este mapa, migrarás una aplicación y descubrirás en producción que dependía de un servicio que dejaste en el datacenter.

# Exportar datos de descubrimiento para análisis
aws discovery describe-agents --region us-east-1

# Generar informe de dependencias
aws discovery list-configurations \
  --configuration-type SERVER \
  --region us-east-1

Errores frecuentes en esta fase:

1. Ignorar las dependencias ocultas: Una aplicación que llama a un servicio SOAP interno que nadie documentó.
2. No medir el ancho de banda: Si transfieres 50 TB de datos a AWS por internet, tardarás semanas. Para volúmenes grandes, considera AWS Snowball.
3. Subestimar las licencias: Licencias de Oracle, SQL Server o SAP pueden tener condiciones diferentes en cloud.

Fase 2: Planificación y diseño (2-3 semanas)

Con el inventario completo, clasifica cada aplicación según la estrategia de migración adecuada. Un enfoque práctico:

Diseño de la red: Define la estructura de VPC antes de migrar:

# Terraform: VPC para migración
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "migration-vpc"
    Environment = "production"
  }
}

# Subnets públicas para load balancers
resource "aws_subnet" "public" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "public-${count.index}"
    Tier = "public"
  }
}

# Subnets privadas para aplicaciones
resource "aws_subnet" "private" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "private-${count.index}"
    Tier = "private"
  }
}

Conectividad híbrida: Durante la migración, tu infraestructura estará dividida entre on-premise y AWS. Necesitas conectividad fiable:

• AWS Site-to-Site VPN: Conexión cifrada por internet. Hasta 1.25 Gbps por túnel VPN. Coste: 0,05 dolares/hora por conexión.
• AWS Direct Connect: Conexión dedicada entre tu datacenter y AWS. 1 Gbps o 10 Gbps. Latencia predecible y consistente. Coste: desde 0,30 dolares/hora para 1 Gbps.

Para la mayoría de migraciones, VPN es suficiente. Direct Connect es necesario cuando transfieres grandes volúmenes de datos o necesitas latencia baja y consistente.

Fase 3: Migración piloto (1-2 semanas)

No migres todo de golpe. Selecciona una aplicación no crítica como piloto. Idealmente:

• Una aplicación con pocas dependencias externas
• Que no sea crítica para el negocio
• Que tenga un equipo disponible para validar el resultado
• Que sea representativa de la mayoría de aplicaciones de tu portfolio

Proceso del piloto:

1. Replicación: Configura AWS MGN para replicar el servidor en tiempo real.
2. Testing: Lanza una instancia de test en AWS. Ejecuta pruebas funcionales, de rendimiento y de seguridad.
3. Cutover de prueba: Simula el cutover redirigiendo tráfico de prueba a la instancia en AWS.
4. Validación: Verifica que la aplicación funciona correctamente: respuestas HTTP correctas, tiempos de respuesta aceptables, integraciones operativas.
5. Rollback: Verifica que puedes volver al servidor original en menos de 15 minutos.

Métricas del piloto: El piloto es exitoso si cumple estos criterios:

• Tiempo de cutover inferior a 30 minutos
• Sin pérdida de datos durante la replicación
• Rendimiento igual o superior al original
• Rollback verificado y documentado

Fase 4: Migración por oleadas (4-12 semanas)

Agrupa las aplicaciones en oleadas de 5-15 aplicaciones. Criterios de agrupación:

• Aplicaciones que comparten la misma base de datos migran juntas.
• Aplicaciones con dependencias mutuas migran en la misma oleada.
• Aplicaciones críticas migran en oleadas posteriores, cuando el equipo tiene experiencia.

Patrón de cutover sin downtime:

1. Replicación continua (MGN mantiene la réplica sincronizada)
2. Congelación de cambios (code freeze)
3. Verificación de sincronización (lag de replicación = 0)
4. Cutover DNS (TTL bajo configurado 48h antes)
5. Validación funcional en AWS
6. Monitorización intensiva (24-72 horas)
7. Decomisionado del servidor origen (tras período de gracia)

DNS y zero downtime: El truco para conseguir zero downtime está en el DNS. Antes de la migración:

1. Reduce el TTL de los registros DNS a 60 segundos (hazlo 48 horas antes para que los cachés se actualicen).
2. Durante el cutover, actualiza el registro DNS para apuntar a la nueva IP en AWS.
3. Los clientes que tenían el DNS cacheado seguirán llegando al servidor original durante un máximo de 60 segundos. El servidor original sigue activo y redirige el tráfico o responde normalmente.

# Route 53: actualizar registro con TTL bajo
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.tudominio.com",
        "Type": "A",
        "TTL": 60,
        "ResourceRecords": [{"Value": "3.120.45.67"}]
      }
    }]
  }'

Fase 5: Optimización post-migración (continua)

La migración no termina cuando apagas el último servidor on-premise. Las primeras semanas en AWS son las más caras porque las instancias están sobredimensionadas (nadie quiere que la aplicación falle justo después de migrar).

Right-sizing: Usa AWS Compute Optimizer para analizar el uso real de CPU, memoria y red de tus instancias. Después de 14 días de datos, Compute Optimizer recomienda el tipo de instancia óptimo.

Reserved Instances y Savings Plans: Una vez que tu consumo es estable (3-6 meses después de migrar), compra capacidad reservada. El ahorro es del 30-60% frente a precios on-demand.

Servicios gestionados: Identifica componentes que puedes migrar a servicios nativos. Un servidor NGINX como proxy reverso puede reemplazarse por ALB. Una instalación de Redis puede migrar a ElastiCache. Cada servicio gestionado que adoptas reduce la carga operativa de tu equipo.

Costes reales de una migración

Costes directos

Costes indirectos

Los costes indirectos suelen ser mayores que los directos:

• Equipo dedicado: Un ingeniero senior a tiempo completo durante la migración. En Europa, 6.000-10.000 euros/mes.
• Formación: El equipo necesita aprender AWS. Cursos, certificaciones, tiempo de aprendizaje. Presupuesta 2.000-5.000 euros por persona.
• Doble ejecución: Durante la migración, pagas por la infraestructura on-premise y por AWS simultáneamente. Esta fase puede durar de 2 a 6 meses.
• Licencias: Algunas licencias de software (Oracle, SQL Server) tienen costes diferentes en cloud. Verifica antes de migrar.

Ejemplo de coste total

Para una startup con 10 servidores, 5 TB de datos y 3 meses de migración:

Errores que hemos visto en migraciones reales

Error 1: migrar sin mapa de dependencias

Una empresa migró su aplicación principal a AWS. Funcionaba correctamente en tests. En producción, la aplicación fallaba intermitentemente. La causa: un microservicio interno que consultaba una base de datos legacy que seguía en el datacenter. La latencia entre AWS y el datacenter (40ms) provocaba timeouts en consultas que antes respondían en 2ms.

Error 2: no ajustar los tipos de instancia

Migrar un servidor con 32 GB de RAM que usa un máximo de 4 GB. En on-premise, el servidor ya estaba comprado. En AWS, pagas cada GB cada hora. El sobredimensionamiento de instancias es el mayor desperdicio de dinero en AWS.

Error 3: ignorar los costes de transferencia de datos

AWS cobra por la transferencia de datos saliente. Si tu aplicación sirve 10 TB de datos al mes, pagarás aproximadamente 900 dolares solo en transferencia. Este coste no existe en on-premise y sorprende a muchos equipos después de la primera factura.

Error 4: no tener plan de rollback

Si el cutover falla, necesitas volver al servidor original en minutos, no en horas. Cada migración necesita un plan de rollback documentado y probado antes del cutover.

Herramientas del ecosistema AWS para migración

AWS Database Migration Service (DMS)

DMS merece mención especial porque la migración de bases de datos es la parte más delicada de cualquier migración. DMS replica datos de forma continua desde la base de datos origen a la destino, incluyendo los cambios que ocurren durante la migración (CDC, Change Data Capture).

# Crear tarea de replicación DMS
aws dms create-replication-task \
  --replication-task-identifier my-migration-task \
  --source-endpoint-arn arn:aws:dms:us-east-1:123456789:endpoint:source \
  --target-endpoint-arn arn:aws:dms:us-east-1:123456789:endpoint:target \
  --migration-type full-load-and-cdc \
  --replication-instance-arn arn:aws:dms:us-east-1:123456789:rep:instance \
  --table-mappings file://table-mappings.json

Motores soportados: MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, MongoDB, Amazon Aurora. DMS permite incluso cambiar de motor durante la migración (por ejemplo, de Oracle a PostgreSQL) usando AWS Schema Conversion Tool (SCT) para adaptar el esquema y las consultas.

Checklist de migración

Antes de iniciar cada oleada de migración, verifica:

• Mapa de dependencias actualizado para todas las aplicaciones de la oleada
• VPC y subnets configuradas con grupos de seguridad restrictivos
• Conectividad verificada entre AWS y datacenter (VPN o Direct Connect)
• TTL de DNS reducido a 60 segundos (48 horas antes del cutover)
• Plan de rollback documentado y probado para cada aplicación
• Alertas de monitorización configuradas en CloudWatch
• Equipo de guardia asignado para las primeras 72 horas post-cutover
• Backups verificados antes del cutover
• Comunicación a usuarios sobre ventana de mantenimiento (si aplica)

Conclusión

Una migración a AWS bien ejecutada reduce costes operativos, mejora la escalabilidad y libera a tu equipo de la gestión de infraestructura física. Pero los beneficios no son automáticos. Requieren planificación, ejecución disciplinada y optimización continua.

El error más frecuente no es técnico. Es intentar migrar todo a la vez, sin un inventario completo, sin pruebas de rollback y sin un equipo con experiencia en AWS.

Si estás planificando una migración y necesitas un equipo que haya ejecutado migraciones reales, con errores documentados y lecciones aprendidas, contacta con nuestro equipo de consultoría AWS. También ofrecemos una auditoría gratuita de infraestructura para evaluar el estado actual de tu entorno y definir la estrategia de migración óptima.