Migré varias aplicaciones .NET legadas a AWS Elastic Beanstalk a lo largo de los años — algunas desde servidores Windows on-premise, algunas desde hosting compartido, y algunas desde otros proveedores de nube. Los pasos técnicos están bien documentados. Lo que está menos documentado es la disciplina operacional necesaria para hacerlo sin tiempo de inactividad y sin que tus usuarios lo noten.
Este es el playbook que sigo.
Por Qué Elastic Beanstalk para .NET
Elastic Beanstalk es la plataforma administrada de AWS para desplegar aplicaciones sin gestionar directamente la infraestructura EC2 subyacente. Para aplicaciones .NET, soporta entornos Windows Server (para apps .NET Framework más antiguas) y entornos Linux (para .NET Core y .NET 5+). Obtenés autoescalado, balanceo de carga, monitoreo de salud y capacidades de despliegue progresivo de fábrica.
Para una app .NET legada que necesita moverse a la nube sin una reescritura completa, suele ser el punto de partida correcto — menor overhead operacional que EC2 puro, más control que Lambda, y un camino de migración que no requiere containerización de entrada.
Fase 1: Preparar Antes de Tocar AWS
La migración comienza antes de crear un solo recurso AWS. Siempre hago tres cosas primero.
Externalizar toda la configuración. Las apps .NET legadas suelen tener cadenas de conexión de base de datos, claves de API y configuraciones específicas de entorno hardcodeadas en Web.config o appsettings.json comprometidos en el repositorio. Antes de la migración, muevo cada valor específico de entorno a AWS Systems Manager Parameter Store o variables de entorno de Elastic Beanstalk. El código de la aplicación lee de variables de entorno; los secretos nunca viven en el control de código fuente.
Auditar el estado de sesión. Si tu aplicación usa estado de sesión en proceso (el default de ASP.NET), se romperá en el momento en que tengas más de una instancia detrás de un balanceador de carga. Reemplazo la sesión en proceso con un proveedor de sesión distribuida respaldado por Redis (ElastiCache) antes de la migración. Esto también es lo que habilita los despliegues sin tiempo de inactividad — cuando Elastic Beanstalk lanza una nueva instancia durante un despliegue progresivo, la nueva instancia puede acceder a todas las sesiones existentes de inmediato.
Ejecutar la app localmente con configuración equivalente a producción. Configuro un entorno local que refleje la configuración AWS objetivo lo más fielmente posible y ejecuto la aplicación completa contra él antes del día de la migración. Las sorpresas que aparecen en esta fase son mucho más baratas de corregir que las que aparecen durante un corte en vivo.
Fase 2: Construir el Entorno AWS en Paralelo
Nunca descomisiono el entorno viejo antes de que el nuevo esté probado. Construyo el entorno Elastic Beanstalk completamente — capa de aplicación, base de datos RDS (si migro desde una base de datos local), ElastiCache y toda la infraestructura de soporte — y lo ejecuto en paralelo con el sistema existente.
Estrategia de migración de base de datos. Si también migrás la base de datos, usá AWS Database Migration Service para la carga masiva inicial, luego habilitá la replicación continua. Esto mantiene la nueva base de datos sincronizada con la vieja durante el período de ejecución paralela. Podés verificar la integridad de los datos sin ningún riesgo para producción.
Reducción del TTL de DNS. Al menos 48 horas antes del corte, reduzco el TTL del registro DNS que apunta a la aplicación a 60 segundos. Esto significa que cuando hago el cambio de DNS durante el corte, se propaga a la mayoría de los clientes en un minuto en lugar de horas.
Fase 3: El Corte
Esta es la parte que pone nervioso a la gente. Así es exactamente cómo lo abordo.
Programo el corte para el período de menor tráfico de la semana — típicamente temprano el domingo por la mañana. Tengo monitoreo activo en ambos entornos. Tengo un plan de rollback documentado y ensayado.
La secuencia:
- Poner el sistema viejo en modo de solo lectura (o mostrar un breve aviso de mantenimiento para operaciones verdaderamente con estado)
- Ejecutar una sincronización final de base de datos para confirmar cero deriva de datos
- Actualizar el registro DNS para apuntar al balanceador de carga de Elastic Beanstalk
- Monitorear el tráfico entrante en el nuevo entorno por 15 minutos
- Verificar manualmente los flujos de usuario clave
- Eliminar el modo de solo lectura
Con un TTL de DNS de 60 segundos y un almacén de sesiones ElastiCache preparado, la mayoría de los usuarios no experimenta nada. Los que estaban a mitad de sesión reciben una nueva sesión en el nuevo entorno — los datos de sesión están en Redis, así que ni siquiera necesitan volver a iniciar sesión.
El momento de la cadena de conexión. Este es el paso donde la mayoría de los equipos tienen problemas. Las cadenas de conexión en Elastic Beanstalk se inyectan como variables de entorno. En .NET Core esto es directo — el sistema de configuración lee de variables de entorno por default y sobreescriben appsettings.json. Para apps .NET Framework legadas en entornos Windows Server, necesitás mapear las variables de entorno al Web.config usando transformaciones de configuración. Siempre pruebo este mapeo explícitamente en staging antes de tocar producción.
Fase 4: Validación Post-Migración
Mantego el entorno viejo funcionando durante al menos dos semanas después de una migración exitosa. Los costos de almacenamiento y cómputo de un entorno inactivo son mínimos, y tener la capacidad de hacer rollback vale cada centavo.
Durante el período de validación monitoreo: tasas de error, percentiles de tiempo de respuesta, rendimiento de consultas de base de datos, y cualquier excepción registrada que no existía antes de la migración. El perfil es casi siempre más limpio en Elastic Beanstalk que en el entorno viejo — los parches administrados, el autoescalado y la infraestructura adecuada tienden a resolver varios problemas intermitentes que se habían atribuido a la aplicación.
Si estás planificando una migración .NET a la nube y querés hablar sobre los detalles de tu arquitectura, contactáme. Cada sistema legado tiene su propio carácter, y los detalles importan.