Modernización de .NET legacy

El problema con el “big bang”

Reescribir todo y salir un lunes con el sistema nuevo suena limpio. En la práctica, concentra el riesgo: el negocio no puede esperar seis meses, el equipo nuevo no conoce las reglas del sistema viejo y nadie sabe qué se rompió hasta que los usuarios lo descubren.

La alternativa es migrar por partes, con el sistema viejo y el nuevo conviviendo. Se reemplaza un módulo, se valida en producción, se mide y se sigue. Así el negocio obtiene valor antes y el riesgo se reparte.

Mi enfoque

1. Inventario y priorización

Identifico módulos, dependencias, integraciones y flujos críticos. Priorizo por riesgo y valor, no por lo que sea más divertido de programar.

2. Pruebas de caracterización

Antes de cambiar una línea, capturo el comportamiento actual con pruebas. No necesito que el código viejo sea bonito; necesito saber qué no puedo romper.

3. Strangler fig

Construyo la nueva funcionalidad alrededor del sistema existente y redirijo el tráfico por módulos. El sistema viejo se apaga cuando ya no es necesario, no antes.

4. Datos e integraciones

Migraciones de esquema controladas, compatibilidad temporal, contratos de API versionados y estrategia de rollback. La base de datos suele ser la parte más delicada; no la dejo para el final.

5. Operación

CI/CD, logs, métricas, alertas y ambientes separados. Si no puedes observar el sistema nuevo, no puedes decir que está listo.

Tecnologías típicas

• Origen: .NET Framework 4.8, Web Forms, VB6/COM, WPF, SQL Server, IIS.
• Destino: .NET 10, ASP.NET Core, Web API, Angular o Razor, Azure, SQL Server/Azure SQL.
• Puente: capas anticorrupción, adaptadores, feature flags, pruebas de caracterización.

Qué necesito de tu equipo

Un dueño del producto, acceso a los ambientes y a las personas que conocen las reglas del negocio. No necesito que tengas todo documentado; parte del trabajo es reconstruir ese conocimiento.

La migración no es un proyecto de tecnología. Es un proyecto de negocio con restricciones técnicas.