Cómo Modernizar Sistemas Legacy Empresariales

Qué hace que un sistema sea realmente problemático

En la práctica, los sistemas legacy problemáticos que encontramos en empresas de la región comparten las mismas características: aplicación monolítica en lenguaje o framework sin soporte activo, base de datos con procedimientos almacenados que encapsulan lógica de negocio crítica, deploy manual al servidor mediante FTP o scripts frágiles, y conocimiento técnico concentrado en 1-2 personas que estuvieron desde el inicio.

Las señales concretas de que la situación es urgente: los deploys se hacen en horarios de baja actividad para minimizar el impacto de errores, hay incidentes frecuentes que tardan horas en resolverse, las estimaciones de nuevas funcionalidades son invariablemente más largas de lo esperado, y el equipo tiene miedo de tocar ciertos módulos.

Las cuatro estrategias de modernización

No existe una estrategia universalmente correcta. La elección depende del riesgo que puede asumir la empresa, el presupuesto disponible, el estado del equipo y el valor crítico del sistema.

Strangler Fig Pattern

La estrategia más conservadora y recomendada para sistemas críticos. Construyes la nueva solución en paralelo y migras funcionalidades gradualmente, estrangulando el sistema legacy mientras el nuevo crece. El sistema viejo sigue funcionando como fallback hasta que el nuevo lo reemplaza completamente. El riesgo en cada paso es mínimo.

Big Bang Rewrite

Reescribir completamente el sistema desde cero. La estrategia más riesgosa — históricamente la más propensa a fracasar. Solo recomendada cuando el sistema está tan acoplado que cualquier migración incremental es impráctica, o cuando el negocio puede permitirse un período de desarrollo sin nuevas funcionalidades. Estátidicamente, la mayoría de los proyectos de reescritura completa terminan sobre tiempo y presupuesto.

Lift and Shift (Containerización)

Envolver el sistema existente en contenedores Docker sin cambiar el código. No resuelve los problemas de arquitectura, pero moderniza la plataforma de deployment, elimina la dependencia de un servidor físico específico y habilita escalar horizontalmente. Es un primer paso pragmático que reduce el riesgo operacional mientras se planea una migración más profunda.

Phased Modernization

Identificar y modernizar los componentes del sistema con mayor valor de negocio o mayor riesgo técnico primero. Similar al Strangler Fig pero orientado por prioridades de negocio en lugar de flujo de usuario. Más fácil de justificar presupuestariamente porque cada fase tiene ROI demostrable.

El assessment técnico previo que nunca debe saltarse

Antes de proponer una estrategia de modernización, el assessment técnico estructurado no es un trámite — es lo que determina qué estrategia es realmente viable.

• Inventario de dependencias: tecnologías, versiones, librerías de terceros. ¿Hay versiones con vulnerabilidades de seguridad conocidas sin parchear?
• Análisis de la base de datos: ¿cuánta lógica de negocio vive en stored procedures? ¿Hay triggers con side effects? ¿El esquema tiene centenares de tablas sin documentar?
• Análisis de acoplamiento: ¿el sistema se integra con otros sistemas? ¿Mediante qué mecanismos (base de datos compartida, FTP, APIs, archivos planos)?
• Análisis de riesgo operacional: tiempo de deploy, frecuencia de incidentes, tiempo de resolución promedio
• Análisis del equipo: ¿quién conoce el sistema? ¿Hay documentación? ¿Hay tests automatizados?

El resultado del assessment determina la estrategia — no al revés. Hemos visto proyectos donde la recomendación inicial era Strangler Fig pero el assessment reveló que la lógica de negocio en stored procedures era tan extensa que el Lift and Shift primero era el único camino pragmático.

La trampa de los procedimientos almacenados

En sistemas legacy empresariales, la lógica crítica de negocio con frecuencia vive en stored procedures de Oracle, SQL Server o MySQL. Este es el obstáculo técnico más complejo en una modernización: los SP pueden tener miles de líneas sin tests, con side effects implícitos, y el conocimiento de cómo funcionan puede estar concentrado en personas que ya no están en la empresa.

La estrategia que usamos: no reescribir los SP de golpe. Construir una capa de API sobre ellos, generar golden tests que documentan el comportamiento actual exhaustivamente, y luego migrar la lógica gradualmente al nuevo sistema mientras los tests verifican que el comportamiento es idéntico.

Containerización como primer paso pragmático

Si el sistema corre en Windows Server 2008 con IIS, o en un servidor físico con Oracle instalado localmente, la containerización como primer paso elimina la dependencia del hardware y hace posible deployar en cualquier ambiente cloud.

# Containerizar una app .NET legacy con Windows containers
FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019

# Copiar aplicación
COPY ./app /inetpub/wwwroot/app

# Configurar IIS
RUN powershell -NoProfile -Command \
    Import-Module WebAdministration; \
    New-WebApplication \
      -Site "Default Web Site" \
      -Name "legacy-app" \
      -PhysicalPath "C:\inetpub\wwwroot\app" \
      -ApplicationPool "DefaultAppPool"

EXPOSE 80

Esto no resuelve la deuda técnica, pero da movilidad operacional. El equipo puede deployar en cloud, hacer rollbacks controlados y gestionar múltiples versiones — sin tocar una línea del código de negocio. Es el punto de partida que desbloquea las fases siguientes.

Estrategia de migración de datos: el componente más complejo

La base de datos es invariablemente el componente más difícil de modernizar. El esquema tiene años de cambios acumulados sin planificación, y frecuentemente hay aplicaciones satélite que acceden directamente a las mismas tablas.

Las estrategias de migración de datos que usamos:

• Dual write: el nuevo sistema escribe en ambas bases de datos durante la transición. Garantiza que la base legacy está siempre actualizada como fallback.
• Change Data Capture (CDC): capturar cambios en la base legacy y replicarlos al nuevo sistema con herramientas como Debezium. Funciona sin modificar el sistema legacy.
• Strangler fig en la capa de datos: migrar una tabla o dominio a la vez al nuevo esquema, con una capa de abstracción que oculta la migración al resto del sistema.

Cómo justificar el ROI internamente

La modernización de sistemas legacy raramente se justifica solo por deuda técnica. Los tomadores de decisión empresariales necesitan números. Los argumentos que funcionan en la práctica:

• Costo de downtime actual: si el sistema tiene incidentes frecuentes de 2-4 horas, el costo por hora de operación detenida es un número concreto.
• Velocidad de desarrollo: si una nueva funcionalidad tarda 6 semanas en el sistema legacy vs. 1 semana en el nuevo, el ROI se calcula directamente.
• Riesgo de seguridad: sistemas en versiones sin soporte activo de seguridad son pasivos con riesgo regulatorio creciente (GDPR, PCI-DSS, etc.).
• Dependencia de personas clave: si la persona que conoce el sistema se va, ¿cuánto valdría ese conocimiento perdido? El bus factor es un riesgo de negocio real.