Sistemas empresariales
El checklist de migración a AWS para mover sin tiempo de inactividad
Actualizado en junio de 2026 · 10 min de lectura · por Brian
La mayoría de los equipos aborda una migración a la nube al revés. Se obsesiona con levantar el servidor y trata los datos y el cutover como ocurrencias tardías, cuando esos son justamente los dos pasos que ponen tu negocio en riesgo. Mover un servidor web sin estado a EC2 es mecánico. Mover una base de datos de producción en la que los clientes están escribiendo activamente, y luego redirigir el tráfico en vivo sin perder una transacción, es donde las migraciones triunfan o fracasan. Este checklist de migración a AWS está construido en torno a esa realidad. Recorre la evaluación, la selección de estrategia, la migración de datos y un plan de cutover que te mantiene en línea, con el trabajo de seguridad, redes y costos que convierte una mudanza exitosa en una estable.
Empieza con una evaluación e inventario honestos
No puedes migrar lo que no has mapeado. Antes de que nadie toque AWS, construye un inventario real de cada aplicación, servidor, base de datos, tarea programada, integración y dependencia de tu entorno actual. El objetivo no es un diagrama bonito. Es sacar a la luz las cosas que te morderán a mitad de la migración: el cron job no documentado que envía correos al equipo de finanzas, la dirección IP fija enterrada en un archivo de configuración, la aplicación heredada que nadie quiere asumir.
Para cada carga de trabajo, captura qué hace, con qué se comunica, cuántos datos contiene, su línea base de rendimiento y su tolerancia al tiempo de inactividad. Ese último punto importa más de lo que la gente espera. Una base de datos de reportes puede estar fuera de línea una hora a las 2am. Un sistema de procesamiento de pedidos no puede. Conocer el objetivo de tiempo de recuperación y el objetivo de punto de recuperación reales de cada sistema te dice cuánta ingeniería de cutover justifica de verdad cada uno.
- Inventaría cada servidor, base de datos, aplicación y tarea programada, incluidos los que nadie documentó
- Mapea dependencias y flujos de datos para saber qué se rompe cuando se mueve un componente
- Registra una línea base de rendimiento (CPU, memoria, IOPS, rendimiento) para dimensionar los recursos de AWS con precisión
- Define la tolerancia al tiempo de inactividad, el RPO y el RTO de cada carga de trabajo de forma individual
- Marca las restricciones de licenciamiento, cumplimiento y residencia de datos antes de que se vuelvan bloqueos
- Identifica IP, nombres de host y credenciales fijos que no sobrevivirán a una mudanza
Elige una estrategia de migración: las 'R' en lenguaje claro
No toda carga de trabajo debería moverse de la misma manera. AWS describe un conjunto de estrategias de migración a menudo llamadas las 'R', y elegir la correcta por aplicación mantiene el proyecto realista en lugar de convertir cada mudanza en una reescritura.
Rehost, a menudo llamado lift and shift, significa mover una carga de trabajo a AWS más o menos tal cual, normalmente sobre EC2 con el mismo sistema operativo y software. Es el camino más rápido y el de menor riesgo para el comportamiento de la aplicación, porque casi nada cambia salvo dónde corre la máquina. Replatform significa hacer mejoras puntuales durante la mudanza sin rearquitecturar, siendo el ejemplo clásico mover una base de datos autogestionada a Amazon RDS para que AWS se encargue de los parches, los respaldos y el failover. Refactor significa reescribir partes de la aplicación para usar servicios nativos de la nube, como dividir un monolito en contenedores o funciones serverless. La refactorización entrega el mayor valor a largo plazo y conlleva el mayor costo y riesgo, así que debería ser una elección deliberada, no la opción por defecto. Para la mayoría de las primeras migraciones, haz rehost del grueso, replatform de las bases de datos que se benefician con claridad, y aplaza la refactorización hasta que estés estable en AWS.
- Rehost (lift and shift): mover tal cual a EC2, lo más rápido y de menor riesgo de comportamiento
- Replatform: mejoras puntuales como mover una base de datos a RDS sin rearquitecturar
- Refactor: reescribir hacia servicios nativos de la nube para valor a largo plazo, el mayor costo y riesgo
- Retirar las cargas de trabajo que ya no se usan en lugar de pagar por migrarlas
- Retener lo que debería quedarse por ahora, y planificar una conexión híbrida hacia ello
Planifica la migración de datos con cuidado
Los datos son la parte más riesgosa de cualquier migración, y es donde corresponde la mayor parte del esfuerzo de ingeniería. El problema central es que tu base de datos de origen sigue cambiando mientras la copias. Una exportación e importación simple funciona bien para un conjunto de datos estático, pero para un sistema de producción en vivo garantiza datos obsoletos y una larga interrupción. Por eso las migraciones serias separan la carga masiva inicial de la replicación continua de cambios.
El patrón que evita el tiempo de inactividad es una carga completa seguida de replicación continua. Copias los datos existentes una vez, luego transmites cada cambio posterior del origen al destino hasta que ambos estén sincronizados y se mantengan sincronizados. AWS Database Migration Service soporta exactamente esto para muchos motores, incluidas las mudanzas heterogéneas donde el origen y el destino son plataformas de base de datos distintas. Cualquiera que sea la herramienta que uses, el paso no negociable es la validación: confirma que los conteos de filas, los checksums y los registros revisados por muestreo coinciden antes de confiar el tráfico en vivo al destino. Migrar los datos es solo la mitad del trabajo; probar que llegaron intactos es la otra mitad.
- Estima el volumen de datos y el tiempo de transferencia con honestidad, incluidos objetos grandes y archivos históricos
- Haz una carga inicial completa, luego habilita la replicación continua para capturar los cambios en curso
- Usa AWS DMS o herramientas de replicación nativas, especialmente para migraciones entre motores distintos
- Valida con conteos de filas, checksums y revisiones por muestreo a nivel de registro antes del cutover
- Prueba el camino de restauración, no solo el respaldo, para poder recuperarte si algo sale mal
Construye un plan de cutover que evite el tiempo de inactividad
El cutover es el momento en que el tráfico se mueve del entorno antiguo a AWS, y es donde se esconde el tiempo de inactividad. El principio que previene una caída es simple: deja el destino completamente listo y sincronizado antes de redirigir a un solo usuario. Con la replicación continua manteniendo al día la base de datos de AWS, el cambio en sí se convierte en una redirección breve y controlada en lugar de una copia frenética y de rezar.
Ejecuta los entornos antiguo y nuevo en paralelo durante un período para poder comparar el comportamiento y detectar problemas mientras el original todavía sirve tráfico. Cuando tengas confianza, mueve el tráfico de forma gradual en lugar de todo de golpe. El cambio basado en DNS con un tiempo de vida bajo te deja redirigir a los usuarios a AWS y revertir rápido si hace falta, aunque debes tener en cuenta el almacenamiento en caché de DNS. Un balanceador de carga o el enrutamiento ponderado te da un control más fino, permitiéndote enviar primero un pequeño porcentaje del tráfico al nuevo entorno y observarlo antes de comprometer el resto. Sobre todo, escribe el plan de reversión antes del día del cutover y ensáyalo. Una migración sin una reversión probada es una apuesta, no un plan.
- Mantén el destino de AWS sincronizado de forma continua para que el cutover sea un cambio, no una copia
- Ejecuta el antiguo y el nuevo en paralelo y compara el comportamiento antes de comprometerte
- Baja el TTL de DNS con antelación para que los cambios de tráfico y las reversiones se propaguen rápido
- Mueve el tráfico de forma gradual usando enrutamiento ponderado o un balanceador de carga, observando las métricas en cada paso
- Escribe y ensaya el plan de reversión antes del día del cutover, con criterios claros de continuar o no
- Programa el cambio para una ventana de bajo tráfico y congela los cambios no relacionados a su alrededor
Acierta en seguridad, IAM y redes
Los fallos de seguridad en la nube rara vez son exóticos. Suelen ser una política de IAM demasiado permisiva, un grupo de seguridad abierto o un bucket de almacenamiento público que debería haber sido privado. Construye el acceso de mínimo privilegio desde el principio, porque incorporarlo después del lanzamiento es doloroso y a menudo se omite. Da a cada servicio y persona solo los permisos que necesita, usa roles en lugar de claves de acceso de larga duración siempre que sea posible, y activa el registro para poder responder después quién hizo qué.
Las redes merecen el mismo cuidado. Diseña tu VPC, subredes y grupos de seguridad de forma deliberada en lugar de aceptar los valores por defecto, aísla las bases de datos en subredes privadas sin exposición directa a internet, y cifra los datos tanto en reposo como en tránsito. Si estás corriendo en híbrido durante la migración, la conexión entre tu entorno existente y AWS necesita ser segura y fiable, ya que tu flujo de replicación y posiblemente el tráfico en vivo dependen de ella.
- Aplica IAM de mínimo privilegio desde el primer día, usando roles en lugar de claves de acceso de larga duración
- Habilita CloudTrail y el registro relevante para que las acciones sean auditables
- Diseña las subredes de la VPC y los grupos de seguridad de forma intencional; mantén las bases de datos en subredes privadas
- Cifra los datos en reposo y en tránsito, y gestiona las claves de forma deliberada
- Asegura la conexión híbrida que transporta la replicación y cualquier tráfico en vivo durante la migración
Controla el costo una vez que aterrices
AWS factura por lo que aprovisionas, no por lo que usas, así que un lift and shift que refleje servidores on premises sobredimensionados gastará de más en silencio cada mes. La solución no es subaprovisionar antes del cutover, cuando la estabilidad es lo que más importa, sino ajustar el tamaño de forma deliberada una vez que tengas datos reales de uso. Observa las cargas de trabajo durante unas semanas, luego ajusta los tamaños de las instancias y el almacenamiento para que coincidan con la demanda real.
Una vez que el uso es predecible, comprométete con él. Los Savings Plans y las Reserved Instances cambian un compromiso de uso por un descuento significativo sobre el precio bajo demanda. Configura alertas de facturación y monitorización de costos temprano para que un recurso descontrolado salga a la luz en días, no a fin de mes. Y limpia los escombros de la migración: las instancias temporales, las instantáneas extra y la infraestructura de replicación que fueron esenciales durante la mudanza y puro desperdicio después.
- Ajusta el tamaño de las instancias y el almacenamiento tras observar el uso real, no antes del cutover
- Usa Savings Plans o Reserved Instances una vez que la demanda sea predecible
- Configura alertas de facturación y presupuestos para que el gasto excesivo salga a la luz temprano
- Elimina los recursos temporales de migración, las instancias inactivas y las instantáneas huérfanas
- Etiqueta los recursos de forma consistente para que el costo sea atribuible a equipos y cargas de trabajo
Valida antes de darlo por terminado
Una migración no termina cuando el servidor arranca en AWS. Termina cuando has probado que la carga de trabajo se comporta correctamente bajo condiciones reales y tienes una forma de saber cuándo no lo hace. Recorre la aplicación de principio a fin como lo haría un usuario, confirma que las integraciones y las tareas programadas siguen disparándose, y compara el rendimiento contra la línea base que capturaste durante la evaluación. Más lento que antes es un defecto, no una rareza que aceptar.
Configura monitorización y alertas antes de dar de baja nada, para que estés vigilando el nuevo entorno en lugar de suponer que está bien. Mantén el entorno antiguo disponible, en un estado al que puedas volver, durante una ventana definida tras el cutover. Solo cuando el nuevo entorno haya corrido limpio a través de un ciclo de negocio completo deberías desmantelar el antiguo. Esa disciplina es la diferencia entre una migración que parece terminada y una que de verdad lo está.
- Ejecuta pruebas funcionales de extremo a extremo como lo haría un usuario real, incluidas integraciones y trabajos por lotes
- Compara el rendimiento contra la línea base previa a la migración y trata las regresiones como defectos
- Levanta monitorización, tableros y alertas antes de dar de baja el origen
- Mantén el entorno antiguo recuperable durante una ventana definida tras el cutover
- Da de baja el origen solo después de un ciclo de negocio completo y limpio en AWS
Preguntas frecuentes
- ¿Cuánto tarda una migración a AWS?
- Depende por completo del alcance y la complejidad, así que desconfía de cualquiera que cotice un cronograma fijo antes de ver tu inventario. Un puñado de servidores sin estado con rehost puede moverse en días. Un patrimonio grande con varias bases de datos de producción, restricciones de tiempo de inactividad ajustadas y trabajo de refactorización puede extenderse durante meses. La fase de evaluación existe precisamente para convertir esa incertidumbre en un cronograma creíble.
- ¿De verdad puedo migrar con cero tiempo de inactividad?
- Para la mayoría de las cargas de trabajo puedes llegar a un tiempo de inactividad casi nulo, a menudo un breve cambio medido en segundos a minutos, usando replicación continua de datos y un cambio gradual de tráfico para que el destino esté completamente listo antes de mover a los usuarios. El cero absoluto verdadero para un sistema con estado es difícil y caro, así que vale la pena ser preciso sobre lo que cada carga de trabajo realmente requiere en lugar de sobreingeniar todo.
- ¿Debería hacer lift and shift primero o refactorizar durante la migración?
- Para la mayoría de las primeras migraciones, haz rehost del grueso del patrimonio y replatform de las bases de datos que se benefician con claridad, luego aplaza la refactorización hasta que estés estable en AWS. Refactorizar a mitad de la migración combina dos proyectos difíciles en uno y multiplica el riesgo. Muévete primero, optimiza después, una vez que entiendas cómo se comportan las cargas de trabajo en la nube.
- ¿Cuál es la parte más riesgosa de una migración a AWS?
- La migración de datos y el cutover, no el levantamiento del servidor. Copiar una base de datos viva y cambiante sin perder transacciones y luego redirigir el tráfico de producción sin una caída es donde las migraciones de verdad salen mal. Por eso la mayor parte del esfuerzo de ingeniería y el ensayo debería concentrarse en esos dos pasos, y por eso un plan de reversión probado no es negociable.
- ¿Cómo mantengo los costos de AWS bajo control después de migrar?
- Ajusta el tamaño después de tener datos reales de uso en lugar de reflejar hardware on premises sobredimensionado, luego comprométete con la demanda predecible mediante Savings Plans o Reserved Instances. Configura alertas de facturación temprano, etiqueta los recursos para que el costo sea atribuible, y elimina las instancias temporales y las instantáneas que sobraron de la migración misma.
Más guías