Migrar la infra de una empresa a AWS tras una adquisición

El contexto: una adquisición con infraestructura heredada

Cuando una empresa grande adquiere otra, el foco inicial está en lo financiero y lo legal. La infraestructura IT queda en segundo plano — hasta que alguien tiene que hacer algo con ella. Ese "alguien" fui yo.

La empresa adquirida tenía un stack heterogéneo: servidores físicos on-prem, algunas VMs en un proveedor cloud distinto al nuestro, aplicaciones legacy con dependencias no documentadas y equipos que nunca habían trabajado con AWS. El objetivo era claro: migrar todo a nuestra cuenta de AWS en 12 meses sin interrupciones de negocio relevantes.

Fase 1: Discovery — lo que no sabes te puede hundir

El primer error que cometen muchos proyectos de migración es saltar directamente a mover cargas de trabajo. Nosotros invertimos las primeras 6 semanas en discovery exhaustivo:

Inventario completo de todos los servicios en producción (aplicaciones, bases de datos, integraciones).
Mapeo de dependencias entre sistemas — esto fue lo más revelador y lo más tedioso.
Evaluación del estado de cada servicio: ¿se puede migrar tal cual (lift & shift)? ¿necesita reingeniería? ¿se puede eliminar?
Identificación de riesgos regulatorios (datos personales, cumplimiento sectorial en seguros).

Resultado: descubrimos 3 aplicaciones críticas que nadie tenía en el radar y una integración con un sistema de un proveedor externo que requería negociación de contrato. Sin este discovery, habríamos migrado a ciegas.

Fase 2: Arquitectura target y aprobación de presupuesto

Con el inventario en mano, diseñé la arquitectura target en AWS. El principio guía fue no innovar durante la migración: primero llevar las cargas de trabajo a AWS con cambios mínimos, luego optimizar. Cada decisión de arquitectura tiene coste, y durante una migración el presupuesto es finito.

La aprobación de presupuesto fue una parte crítica de mi rol. Tuve que justificar cada línea de coste frente a stakeholders no técnicos. La clave: hablar en términos de riesgo de negocio, no de tecnología. "Si no migramos el servidor X antes de la fecha Y, perdemos el soporte del proveedor y quedamos expuestos a vulnerabilidades sin parche" entiende mucho mejor que "necesitamos una EC2 de tipo m5.large".

Fase 3: Migración por olas — el orden importa

Organizamos la migración en cuatro olas, de menor a mayor criticidad:

Ola 1 — Entornos no productivos: dev y staging primero. Nos permitió afinar procesos sin riesgo.
Ola 2 — Servicios internos: herramientas de equipo, monitorización, sistemas de backup.
Ola 3 — Aplicaciones de negocio secundarias: las que tienen impacto si caen pero no son el core.
Ola 4 — Core productivo: las aplicaciones más críticas, migradas en ventanas de mantenimiento negociadas con el negocio.

Cada ola tenía su propio plan de rollback. Si algo salía mal, el procedimiento para volver atrás estaba documentado y probado antes de empezar. Esta disciplina nos salvó en al menos dos ocasiones.

Gestión de riesgos: lo que me quita el sueño

Mi mayor preocupación durante todo el proyecto fue el uptime durante los cortes de migración. Para las aplicaciones críticas usamos un enfoque de migración en paralelo: levantar el servicio en AWS, sincronizar datos, redirigir tráfico gradualmente con Route 53 weighted routing y mantener el origen activo durante 48-72 horas como fallback.

Otro riesgo importante fue la gestión del cambio en los equipos. Los técnicos de la empresa adquirida no conocían AWS. Invertimos tiempo en formación básica y en documentar los nuevos procedimientos operativos. Sin ese buy-in humano, la migración técnica perfecta puede fracasar en producción.

Lo que haría diferente

Empezar el discovery el día 1, no el día 30. Siempre se tarda más de lo esperado.
Automatizar el inventario con herramientas como AWS Migration Hub desde el principio.
Incluir al equipo de seguridad antes, no después de diseñar la arquitectura.
Comunicación más frecuente con el negocio — los silencios generan desconfianza.

Una migración cloud no es un proyecto técnico. Es un proyecto de cambio organizacional con componente técnica. Quien lo olvida, lo aprende a las malas.

Resultado final

Completamos la migración en plazo, dentro del presupuesto aprobado y sin incidentes críticos en producción. El SLA de disponibilidad se mantuvo por encima del 99.8% durante todo el proceso. No fue perfecto — hubo noches largas y decisiones difíciles — pero el resultado justificó el esfuerzo.