Migrar a AWS sin frenar la operación: lista por fases
Respuesta corta: las migraciones a AWS no fallan por la tecnología; fallan porque nadie definió qué se movía primero, qué dependía de qué y qué pasaba si algo salía mal durante el corte. Lo que evita que la operación se detenga (turnos, facturación, planta) es un inventario honesto, un orden de migración que empiece por lo de bajo riesgo, un plan de reversa probado y un criterio de aborto acordado antes de tocar producción.
Esta lista organiza lo que hay que resolver antes, durante y después del corte. Está pensada para servidores locales o un proveedor de hosting que se mueven a una cuenta de AWS, que es como trabajamos en cloud AWS y DevOps.
¿Qué hay que inventariar antes de mover nada?
Ninguna migración empieza en el servidor. Empieza con un inventario de lo que existe y de cómo se usa hoy, no de cómo dice el diagrama que debería usarse:
- Qué sistemas existen y quién los usa de verdad. No el organigrama, sino los equipos que dependen de cada aplicación para operar.
- Dependencias entre aplicaciones. Qué se rompe si un sistema se mueve antes que otro: integraciones, reportes automáticos, procesos por lote, tareas programadas.
- Ventanas reales de operación. Turnos de planta, cierres contables, temporadas altas: momentos en los que un corte no es viable.
- Licencias y contratos vigentes. Qué software depende de un servidor físico, de un dongle o de un acuerdo que no se traslada solo a la nube.
- Quién es dueño de cada dato. Sin un responsable por sistema, nadie valida después si la migración se hizo bien o si algo se perdió.
El entregable es una tabla, no un diagrama: sistema, usuarios, dependencias, ventana, licencia, responsable.
¿Qué se migra primero y con qué estrategia?
No todo se migra igual. AWS describe siete estrategias de migración (las «7 R»: retire, retain, rehost, relocate, repurchase, replatform, refactor) en su guía de migraciones grandes (https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html). En la práctica, para una empresa que sale de servidores locales, se reducen a tres decisiones por sistema:
| Estrategia | Qué significa | Cuándo aplica |
|---|---|---|
| Rehost | Mover la máquina tal cual (a EC2) | Sistemas que funcionan bien y que no vale la pena tocar todavía |
| Replatform | Ajustar sin rediseñar: base de datos administrada (RDS), almacenamiento en S3, balanceador | Sistemas que se benefician de dejar de administrar servidores sin reescribir código |
| Refactor | Rediseñar de raíz, normalmente a serverless (Lambda, DynamoDB, API Gateway) | Sistemas viejos que ya no soportan la operación actual o que conviene reescribir |
Y dos que se olvidan: retirar lo que nadie usa (aparece en el inventario) y retener lo que por licencia o hardware se queda donde está.
El orden importa más que la técnica. Empieza por lo que genera molestia operativa pero implica bajo riesgo si algo sale mal: un servidor de archivos, un ambiente de pruebas, una aplicación secundaria. Nunca arranques por el sistema más crítico: ahí es donde menos margen hay para aprender sobre la marcha.
¿Por qué el plan de reversa no es opcional?
Un respaldo que nunca se ha restaurado no es un respaldo: es una suposición. Antes de mover nada, hay que probar la restauración completa en un ambiente aislado y confirmar que los datos llegan íntegros y utilizables, no solo que el archivo del respaldo existe.
El criterio de aborto se define antes del corte, no durante:
- Qué señales obligan a revertir. Errores de datos, caída de un sistema dependiente, un corte que se alarga más de lo planeado.
- Quién tiene la autoridad para decidir. Una persona con nombre, que decide con la información disponible en ese momento, no después con el beneficio de la retrospectiva.
- Cuánto tarda la reversa y hasta qué punto es posible. Después de cierto volumen de datos nuevos en el destino, volver atrás deja de ser gratis. Ese punto se marca en el plan.
¿Cómo es la ventana de corte paso a paso?
- Congelar cambios en el sistema origen para que no haya movimiento de datos a mitad del corte.
- Sincronizar los datos finales entre origen y destino.
- Validar en el destino con casos reales de uso, no solo con pruebas sintéticas: una factura, un pedido, un reporte de cierre.
- Hacer el corte: redirigir DNS, conexiones y accesos hacia el nuevo entorno.
- Monitorear con todo el equipo disponible, no solo con quien lideró la migración.
- Confirmar el corte o revertir, según el criterio de aborto acordado.
Los tiempos de cada paso se ensayan antes en un simulacro con datos de prueba. Lo que no se ensayó no se sabe cuánto tarda.
¿Por qué AWS no es barato por default?
AWS factura por lo que usas, no por lo que aprovisionaste una vez, y eso es una ventaja solo si se dimensiona bien. Dimensiona según el uso real de tu operación, no según el pico histórico que ocurrió una vez; sobredimensionar «por si acaso» es la forma más común de que una migración termine costando más que la infraestructura que reemplazó.
Datos clave para el presupuesto:
- Estima antes de migrar con la calculadora pública de AWS (https://calculator.aws/) usando el inventario: tamaño de cada máquina, almacenamiento, tráfico de salida. La estimación va por escrito en el plan.
- Define presupuestos con alerta desde el primer día con AWS Budgets (https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html), no hasta que llegue una factura inesperada.
- Apaga ambientes de prueba y desarrollo fuera de horario. No necesitan estar encendidos de noche ni en fin de semana.
- Considera ARM (Graviton) y serverless donde apliquen. AWS afirma que las instancias basadas en Graviton cuestan hasta 20 % menos que instancias EC2 x86 comparables (https://aws.amazon.com/ec2/graviton/), y Lambda publica precios distintos para x86 y Arm (https://aws.amazon.com/lambda/pricing/): compara las dos tablas para tu región. Son afirmaciones del proveedor; la cifra que cuenta es la de tu factura después de migrar, medida contra la estimación.
- Revisa el gasto mensual con la misma disciplina con la que se revisa cualquier insumo de la operación, no como una línea que se aprueba sin mirar.
¿Qué se valida después del corte?
El corte no es el final del proyecto: es el inicio de la operación en el nuevo entorno.
- Monitoreo y alertas configurados para el destino, no copiados del ambiente anterior: ajustados a la nueva arquitectura y con un responsable que las reciba.
- Accesos y permisos depurados. Una migración es el momento indicado para eliminar cuentas y privilegios que ya no deberían existir, y para dejar IAM con el mínimo necesario.
- Respaldos operando en el destino, no apuntando al servidor que ya se apagó. Y probados, igual que antes del corte.
- Documentación de cómo opera el nuevo ambiente, para que no dependa de la memoria de quien hizo la migración. Infraestructura como código (SAM o CDK) es la forma más directa de que esa documentación sea ejecutable.
Aquí es donde SRE y observabilidad marcan la diferencia entre una migración que se sostiene sola y una que acumula deuda técnica desde el primer día. Cada punto se puede planear con más o menos detalle según el tamaño de la operación, pero ninguno se puede saltar sin asumir un riesgo que, tarde o temprano, sale más caro que el tiempo que hubiera tomado hacerlo bien.