Migrar de .NET Framework 4.8 a .NET 10 sin detener la operación

Migrar un sistema que sostiene el negocio no es un ejercicio de laboratorio. Si el sistema procesa pagos, pólizas, facturas o nóminas, cada hora de indisponibilidad tiene un costo. Y si el código lleva diez años creciendo, nadie sabe realmente qué se rompe hasta que se rompe.

Aun así, quedarse en .NET Framework 4.8 también tiene un costo: dificultad para contratar, dependencia de Windows/IIS, librerías sin soporte, menor rendimiento y una integración con la nube más incómoda. La pregunta no es “¿migro o no migro?”, sino “¿cómo migro sin apostar la operación a un solo despliegue?”.

Por qué el big bang suele fallar

El plan típico suena así: congelamos el desarrollo durante seis meses, reescribimos todo, probamos al final y salimos un lunes con la versión nueva.

Funciona en una demo. En producción suele fallar por tres razones:

1. El negocio no se congela. Durante esos seis meses hay cambios regulatorios, nuevos clientes y urgencias que obligan a tocar el sistema viejo.
2. Las reglas no están documentadas. Gran parte del comportamiento vive en el código, en stored procedures y en la cabeza de quienes lo construyeron.
3. El riesgo se concentra. Si algo falla el día del corte, no hay un módulo pequeño que revertir: hay que devolver todo.

La alternativa es migrar por partes, con el sistema viejo y el nuevo conviviendo durante un tiempo controlado.

Una estrategia en seis pasos

1. Inventario y mapa de dependencias

Antes de elegir tecnologías, necesitas saber qué tienes. Documenta:

• Proyectos, soluciones y assemblies.
• Dependencias externas: DLLs, COM, servicios SOAP, APIs, bases de datos.
• Puntos de entrada: webs, jobs, Windows Services, aplicaciones de escritorio.
• Componentes compartidos y acoplamientos ocultos.
• Personas que entienden cada parte.

El resultado no tiene que ser perfecto. Tiene que ser suficiente para priorizar.

2. Pruebas de caracterización

Las pruebas de caracterización capturan el comportamiento actual, incluso si el comportamiento es raro. No prueban que el código sea correcto: prueban que no cambió después de tu intervención.

Empieza por los flujos con más impacto: cálculo de primas, generación de facturas, registro de pagos, cierres contables. Si no hay pruebas, escribe pruebas de integración sobre la interfaz existente antes de refactorizar.

3. Strangler fig, no reescritura total

La idea es construir la funcionalidad nueva alrededor de la vieja y redirigir el tráfico por partes. Puedes hacerlo con:

• Branch by abstraction: una interfaz común con implementación vieja y nueva.
• Proxy o gateway: enrutar ciertas rutas al servicio nuevo.
• Feature flags: activar el módulo nuevo por cliente, país o porcentaje de tráfico.
• Capas anticorrupción: aislar el modelo nuevo de las estructuras del sistema viejo.

El sistema viejo se apaga cuando ya no recibe tráfico, no cuando el equipo se cansó de él.

4. La base de datos es el verdadero proyecto

Migrar C# suele ser más sencillo que migrar datos y procedimientos. Define desde el inicio:

• Qué tablas y procedures se comparten.
• Cómo convivirán el esquema viejo y el nuevo.
• Cómo se harán migraciones reversibles.
• Cómo se validará la integridad después de cada paso.
• Qué pasa si hay que volver atrás.

No dejes la base de datos para el final. Es donde se concentra el riesgo silencioso.

5. CI/CD y observabilidad desde la primera fase

Un sistema migrado sin pipeline ni métricas es un sistema que no puedes operar. Antes de mover el primer módulo, asegura:

• Builds reproducibles.
• Ambientes separados (desarrollo, staging, producción).
• Despliegues automatizados y rollback.
• Logs estructurados, métricas y alertas.
• Trazabilidad de errores por flujo de negocio.

6. Apagado controlado del legacy

El objetivo no es “tener .NET 10”. Es retirar el sistema viejo con evidencia. Define criterios de salida por módulo: tráfico, errores, latencia, quejas, conciliaciones. Cuando el módulo nuevo cumple los criterios durante un periodo acordado, se apaga el viejo.

Qué migrar primero

No empieces por el módulo más grande ni por el más divertido. Empieza por uno que cumpla estas condiciones:

• Tiene dolor de negocio claro (errores, lentitud, costo, riesgo).
• Está relativamente aislado.
• Se puede medir.
• Tiene un dueño de producto disponible.
• No depende de diez integraciones simultáneas.

Un primer módulo exitoso compra credibilidad para el resto del programa.

Errores comunes

• Subestimar las dependencias. Una DLL de 2008 puede bloquear toda la migración.
• No involucrar a operación. El equipo que despliega y monitorea detecta problemas que el desarrollo no ve.
• Migrar todo el frontend al mismo tiempo. Cambiar backend, UI y base de datos en un solo paso multiplica el riesgo.
• No definir criterios de salida. Sin criterios, el legacy nunca se apaga y pagas dos sistemas para siempre.
• Confundir modernizar con reescribir. Modernizar puede incluir encapsular, estabilizar y migrar selectivamente.

Cuándo no migrar todavía

Si el sistema es estable, no tiene riesgo regulatorio, el costo de mantenerlo es bajo y no hay una necesidad de negocio, una migración puede ser un gasto sin retorno. Antes de migrar, hazte tres preguntas:

1. ¿Qué problema de negocio resuelve la migración?
2. ¿Cuál es el costo de no hacerla?
3. ¿Tenéis el equipo y el patrocinio para sostenerla?

Si no hay una respuesta clara, primero haz una auditoría. Migrar por moda es tan caro como quedarse quieto por miedo.

Checklist rápido

• ☐ Inventario de proyectos y dependencias.
• ☐ Mapa de flujos críticos y dueños de negocio.
• ☐ Pruebas de caracterización en los flujos principales.
• ☐ Estrategia de convivencia y rollback.
• ☐ Plan de datos y migraciones reversibles.
• ☐ CI/CD y observabilidad antes del primer módulo.
• ☐ Criterios de apagado del legacy.
• ☐ Comunicación quincenal con negocio y operación.

Si estás evaluando una migración y no sabes por dónde empezar, una auditoría técnica de 2–3 semanas puede darte el mapa y el plan antes de comprometer un presupuesto grande. Hablemos.