Modernizar software legado empieza por recuperar una versión confiable

La primera entrega puede conservar el comportamiento

Antes de prometer nuevas funciones, conviene identificar la versión realmente operativa, reconstruir dependencias, compilar y ejecutar una release reproducible. La modernización técnica y la evolución funcional necesitan criterios separados: un resultado de compilación no es validación del negocio.

A veces el problema de un sistema legado no es que falte el código fuente. Es exactamente lo contrario: hay demasiadas copias y ninguna puede demostrar por sí sola qué versión terminó en producción.

Puede existir una copia en el equipo de un desarrollador, otra en una carpeta compartida, un backup antiguo, scripts SQL separados y un ejecutable que sigue operando correctamente desde hace años. El conocimiento necesario para unir todas esas piezas suele vivir en procedimientos manuales y en la memoria de pocas personas.

En ese escenario, empezar una modernización directamente con un nuevo lenguaje, una migración cloud o una herramienta de IA añade movimiento antes de recuperar control.

La primera meta debería ser más sencilla y más exigente a la vez:

poder reconstruir una release conocida del sistema sin depender de la máquina ni de la memoria de quien hizo el último cambio.

Microsoft plantea la modernización como un ciclo que comienza por assessment e inventario, incluyendo aplicaciones, datos, infraestructura y dependencias antes de ejecutar la transformación.Microsoft - Application modernization lifecycle

1. La primera release de la modernización puede ser la misma aplicación

No toda modernización necesita empezar cambiando funcionalidad.

Un primer hito muy valioso puede ser tomar el sistema tal como existe y conseguir una línea base reproducible.

Esa línea base debería responder, como mínimo:

• cuáles son las fuentes oficiales;
• qué versión del runtime, IDE, generador o toolchain se necesita;
• cuáles son las dependencias externas;
• qué esquema y scripts de base de datos corresponden a esa versión;
• qué configuración necesita cada ambiente, sin guardar secretos dentro del código;
• cómo se genera el artefacto desplegable;
• qué versión está actualmente operando.

Microsoft recomienda comenzar una modernización construyendo un inventario y mapeando dependencias entre aplicaciones, bases de datos y servicios. No es un paso administrativo: es lo que evita que una dependencia invisible aparezca después como una interrupción inesperada.Microsoft - Make an inventory and collect data

El Baseline Rebuild Test

Hay una prueba simple que sirve para medir cuánto control existe realmente:

¿podemos tomar una máquina limpia, recuperar las fuentes y dependencias declaradas y generar nuevamente una versión funcional del sistema?

Si la respuesta es no, todavía existe conocimiento operativo fuera de la fuente de verdad.

El objetivo inicial no es eliminarlo todo en un día. Es identificarlo y convertirlo progresivamente en algo repetible.

2. Subir el código a Git no resuelve el problema completo

Versionar es mucho más que copiar archivos a un repositorio.

En sistemas modernos, Git suele ser la pieza central. En plataformas legacy puede existir una combinación de mecanismos: Git, repositorios nativos de la plataforma, proyectos de base de datos, paquetes exportables o herramientas especializadas de control de cambios.

Por ejemplo, una solución puede necesitar:

• Git / Azure Repos para código, scripts, configuración declarativa, documentación y pipelines;
• un repositorio nativo de la plataforma para componentes que no se representan correctamente como archivos fuente convencionales;
• SQL Database Projects o scripts de migración para controlar la evolución del esquema;
• un repositorio de artefactos para conservar builds identificables y desplegables.

La tecnología cambia. La regla no:

debe existir una fuente de verdad capaz de explicar qué compone una release.

El control de versiones sirve precisamente para registrar cambios y recuperar estados anteriores; Git fue diseñado para mantener la historia de archivos bajo revisión, no solo su última copia.Git - About Version Control

3. Una release no es solo código

Uno de los errores más peligrosos durante una modernización es versionar la aplicación y dejar el resto del sistema por fuera.

Una release real puede depender de:

• código de aplicación;
• objetos o componentes de plataforma;
• librerías y paquetes;
• versiones del runtime;
• scripts y esquema de base de datos;
• jobs programados;
• configuraciones;
• integraciones externas;
• parámetros de infraestructura;
• artefactos generados.

Si alguno de esos elementos cambia sin trazabilidad, la organización puede tener el código correcto y aun así ser incapaz de reproducir el comportamiento de producción.

Por eso la pregunta útil no es únicamente "¿está el código en Git?".

Es:

"¿qué necesito para reconstruir esta release y dónde está versionado cada elemento?"

4. Hacer el cambio revisable

Una vez existe una línea base, el siguiente problema es controlar cómo entra un nuevo cambio.

En Git, una implementación típica puede ser:

Work Item -> branch -> Pull Request -> revisión -> build validation -> merge

Azure Repos permite proteger ramas mediante políticas que obligan a usar Pull Requests, revisores y validaciones de build antes de integrar cambios.Microsoft - Azure Repos branch policies

En una plataforma que no use Git de esa forma, el mecanismo puede cambiar, pero deberían conservarse los mismos principios:

1. existe una razón trazable para el cambio;
2. se puede identificar exactamente qué objetos fueron modificados;
3. otra persona puede revisar el impacto cuando el riesgo lo requiere;
4. existe evidencia de validación antes de integrar o liberar.

No se trata de agregar ceremonias a software viejo. Se trata de disminuir el número de cambios que solo una persona puede explicar.

5. El build también debe salir de la memoria de las personas

Un repositorio ayuda poco si compilar sigue requiriendo veinte pasos manuales que solo funcionan en una estación de trabajo específica.

La modernización empieza a ganar fuerza cuando el build se vuelve repetible:

• toolchain identificado;
• dependencias declaradas;
• secretos fuera del código;
• scripts o pipeline para compilar;
• validaciones mínimas automáticas;
• resultado empaquetado de forma consistente.

Microsoft recomienda ejecutar modernizaciones incrementalmente con source control y CI/CD, incluso cuando se trabaja sobre código legado, y añadir pruebas sobre funciones críticas para detectar cambios de comportamiento durante refactorizaciones.Microsoft - Execute cloud modernization

Esto no significa que un sistema legado deba tener cobertura unitaria perfecta antes de avanzar.

En muchos casos el primer objetivo será más pragmático: automatizar aquello que hoy podemos verificar de forma repetible.

Puede empezar con compilación, smoke tests, comparación de salidas, validaciones de consultas o casos funcionales críticos.

6. La base de datos también forma parte del control de versiones

Este punto merece atención especial porque una aplicación puede volver a una versión anterior mucho más fácilmente que sus datos.

Cada cambio de base de datos debería poder responder:

• qué modifica;
• desde qué versión parte;
• en qué orden se ejecuta;
• cómo se valida;
• qué dependencias tiene;
• y cuál es el plan de recuperación.

Para cambios simples puede existir un rollback directo. Para cambios de esquema o datos más complejos, intentar revertir puede ser más riesgoso que avanzar con una corrección.

La guía de safe deployments de Azure advierte que hacer rollback de cambios en base de datos, esquema u otros componentes con estado puede ser complejo. También recomienda diseñar cambios de esquema compatibles con versiones anteriores cuando deban coexistir versiones durante un despliegue.Microsoft - Safe deployment practices

Por eso, en sistemas críticos, rollback no siempre significa ejecutar un script inverso. Puede significar restaurar, hacer roll-forward o diseñar el cambio en varias etapas para preservar compatibilidad.

7. El artefacto debe tener identidad

Después del build necesitamos saber exactamente qué estamos desplegando.

Una release debería producir un artefacto identificable:

• versión o build ID;
• commit o baseline asociado;
• fecha;
• resultado de validaciones;
• scripts de base de datos relacionados;
• notas de cambio;
• instrucciones de despliegue y recuperación cuando apliquen.

Azure Pipelines permite publicar artefactos de pipeline y utilizarlos entre etapas de build y deployment. La guía de Operational Excellence también recomienda versionar los artefactos para soportar rollback y roll-forward.Microsoft - Pipeline artifacts Microsoft - Safe deployments

Esto cambia una pregunta importante durante un incidente.

En lugar de:

"¿qué archivos copió alguien al servidor?"

podemos preguntar:

"¿qué release está desplegada y de qué baseline salió?"

8. Desplegar y recuperar son dos partes del mismo diseño

Automatizar un deployment sin pensar en recuperación solo automatiza la ida.

Antes de mover una modernización a un ambiente crítico conviene definir:

• prerequisitos;
• orden de despliegue;
• validación posterior;
• condiciones para detener;
• procedimiento de rollback o roll-forward;
• backup o restore cuando el cambio afecta datos;
• evidencia de qué versión quedó operando.

Microsoft recomienda escribir los pasos de rollback junto con los pasos de deployment y usar estrategias de despliegue seguras según el riesgo del cambio.Microsoft - Plan cloud modernization

La capacidad importante no es solamente desplegar más rápido.

Es saber qué hicimos y tener una salida cuando no funciona.

9. Recuperar control no significa congelar el sistema

Aquí aparece uno de los trade-offs más importantes.

Mientras construimos la línea base, el negocio puede seguir necesitando cambios sobre el sistema actual.

Hay varias estrategias posibles:

• freeze temporal: reduce incertidumbre, pero limita la capacidad de atender cambios durante el baseline;
• ventana controlada: se permiten solo cambios críticos y después se reconcilian;
• trabajo paralelo: mantiene velocidad de negocio, pero exige disciplina para evitar que la línea base quede obsoleta antes de terminarla.

No existe una respuesta universal.

La decisión depende de criticidad, frecuencia de cambios, número de equipos y capacidad de reconstruir diferencias.

Lo importante es que la organización sepa qué baseline está estabilizando y cómo incorpora cualquier cambio que ocurra durante ese proceso.

10. Después del control viene la estrategia de modernización

Recuperar versiones no obliga a reescribir.

Al contrario: permite decidir mejor.

Con una línea base confiable podemos evaluar por componente si conviene:

• mantener;
• rehost;
• replatform;
• refactorizar;
• reemplazar;
• o retirar.

En sistemas grandes, una estrategia incremental suele reducir el riesgo frente a una sustitución completa. El patrón Strangler Fig, por ejemplo, permite reemplazar funcionalidad gradualmente mientras el sistema legado continúa operando.Microsoft - Strangler Fig pattern

La decisión arquitectónica importante deja de ser:

"¿a qué tecnología migramos todo?"

Y pasa a ser:

"¿qué parte debemos cambiar primero, qué riesgo elimina y cómo comprobamos que sigue funcionando?"

11. Dónde entra la IA

La IA puede ser extremadamente útil en software legado.

Puede ayudar a:

• explicar módulos difíciles de leer;
• clasificar dependencias;
• encontrar código duplicado;
• generar documentación inicial;
• proponer characterization tests;
• ayudar con upgrades de frameworks;
• comparar implementaciones;
• acelerar la búsqueda de incompatibilidades.

Microsoft ya ofrece herramientas de modernization asistidas por GitHub Copilot que realizan análisis del codebase, dependencias, configuración, workflows y modelos de datos para ayudar a planear transformaciones.Microsoft - GitHub Copilot modernization

Pero hay una regla que no debería cambiar:

el código generado por IA no necesita un carril especial hacia producción.

Si una IA propone una modificación, esa modificación entra al mismo circuito que cualquier aporte humano:

versionado -> revisión -> build -> pruebas -> artefacto -> despliegue controlado.

La IA acelera el trabajo. El sistema de control determina si ese trabajo es aceptable.

12. Trade-offs que conviene hacer explícitos

Decisión

Beneficio

Trade-off

Crear una baseline sin reconstruir historia antigua

Permite empezar rápido con un punto confiable

Se pierde trazabilidad detallada de cambios anteriores

Congelar cambios durante el baseline

Reduce divergencias

Puede afectar necesidades operativas del negocio

Unificar todo en Git

Visibilidad y tooling homogéneo

Algunas plataformas legacy necesitan repositorios o mecanismos nativos

Automatizar todas las pruebas antes de modernizar

Alta seguridad de regresión

Puede retrasar meses el inicio; characterization tests incrementales pueden ser más realistas

Rollback automático de base de datos

Recuperación rápida en cambios simples

Puede ser peligroso cuando existen transformaciones de datos o cambios destructivos

Reescritura completa

Libertad arquitectónica máxima

Mayor superficie de cambio y más comportamiento que demostrar nuevamente

La modernización responsable no elimina estos trade-offs. Los hace visibles antes de tomar decisiones costosas.

13. Un Modernization Control Loop mínimo

Antes de transformar una aplicación completa, podemos establecer un circuito de control pequeño pero verificable.

1. Inventory + Baseline

Fuentes, runtime, dependencias, base de datos, integraciones y versión productiva identificadas.

2. Source of Truth

Cada componente de una release tiene un repositorio o mecanismo de versionado definido.

3. Change Gate

Todo cambio tiene motivo, trazabilidad y revisión proporcional al riesgo.

4. Reproducible Build + Validation

El sistema puede construirse nuevamente y ejecutar validaciones repetibles.

5. Versioned Release Package

Artefactos, scripts, evidencia y versión quedan unidos en un paquete identificable.

6. Controlled Deployment + Recovery

El paso entre ambientes y la recuperación tienen procedimiento y evidencia.

La IA puede acelerar cualquiera de estas capas, pero no reemplaza ninguna.

flowchart LR
 A["Sistema heredado"] --> B["Inventario y línea base"]
 B --> C["Fuentes oficiales"]
 C --> D["Revisión y aprobación"]
 D --> E["Compilación y validación"]
 E --> F["Entrega versionada"]
 F --> G["Despliegue controlado"]
 G --> H{"Siguiente decisión"}
 H -->|"Mantener"| C
 H -->|"Modernizar"| I["Evaluar opciones"]
 J["Asistencia con IA"] -.-> B
 J -.-> D
 J -.-> E

14. Cómo medir si realmente recuperamos control

Algunos indicadores simples ayudan más que afirmar que el proyecto "ya tiene DevOps":

• porcentaje de componentes con fuente de verdad identificada;
• porcentaje de cambios de base de datos versionados;
• porcentaje de builds reproducibles desde un ambiente limpio;
• porcentaje de releases generadas por un proceso repetible;
• porcentaje de releases con artefacto y baseline identificables;
• número de pasos manuales necesarios para desplegar;
• cambios encontrados en producción que no existen en el repositorio;
• tiempo necesario para reconstruir una release conocida;
• porcentaje de cambios críticos con evidencia de validación y plan de recuperación.

La meta no es obtener cero pasos manuales inmediatamente.

La meta es reducir progresivamente las partes del sistema que dependen de conocimiento invisible.

15. La oportunidad de modernización está en recuperar capacidad de decisión

Para una empresa con software crítico, una reescritura completa puede sonar atractiva, pero no siempre es la primera inversión correcta.

A veces la primera fase de modernización debería producir algo menos espectacular y mucho más útil:

• una baseline confiable;
• un inventario técnico;
• una fuente de verdad;
• un build reproducible;
• una ruta de cambios;
• un paquete de release;
• y un mapa de qué vale la pena modernizar después.

Ese enfoque encaja con cómo estamos orientando en Eximus los proyectos de modernización: primero recuperar control y evidencia; después decidir dónde transformar.

No porque Git, CI/CD o Azure DevOps sean el objetivo final.

Sino porque hacen posible algo mucho más importante: cambiar un sistema antiguo sin tener que confiar en heroísmo cada vez que tocamos producción.

La meta no es que el software parezca nuevo.

La meta es que la organización vuelva a poder responder con confianza:

qué cambió, por qué cambió, qué versión está operando y qué hacemos si necesitamos recuperarnos.

Siguiente paso

¿Puedes reconstruir hoy la versión de tu sistema que está en producción únicamente con sus fuentes, dependencias y proceso documentado?

Si la respuesta depende de una persona o de una máquina específica, probablemente ahí ya existe un buen punto para comenzar la modernización.

Referencias técnicas

• Microsoft - Application modernization lifecycle
• Microsoft - Make an inventory and collect data
• Microsoft - Azure Repos branch policies
• Microsoft - Execute cloud modernization
• Microsoft - Pipeline artifacts
• Microsoft - Safe deployment practices
• Microsoft - Plan cloud modernization
• Microsoft - Strangler Fig pattern
• Microsoft - GitHub Copilot modernization
• Git - About Version Control