Cómo migrar de .NET Framework a .NET moderno sin frenar la operación
Tu sistema funciona, pero cada año cuesta más mantenerlo. Así encaramos una migración por etapas: qué se mueve primero, qué conviene reescribir y cómo evitar el temido “apagón” de un fin de semana.
Muchas empresas en Paraguay y en la región tienen su operación entera corriendo sobre sistemas hechos en .NET Framework: facturación, stock, compras, sueldos. Son sistemas que funcionan, que la gente conoce y que nadie quiere tocar. Justamente por eso, la migración suele postergarse hasta que se vuelve urgente.
La buena noticia es que no hace falta apagar nada ni reescribir todo de una vez. En este artículo te contamos el método que usamos para mover un sistema a .NET moderno por etapas, con la operación funcionando todos los días.
Contexto: Por qué conviene pensarlo ahora
.NET Framework 4.8 es la última versión de esa línea. Sigue recibiendo parches de seguridad como parte de Windows, pero no incorpora novedades: todo lo nuevo en rendimiento, contenedores, Linux, nube y librerías llega solamente a .NET moderno (el que antes se llamaba .NET Core).
Hoy la versión con soporte extendido es .NET 10, lanzada en noviembre de 2025 y con soporte hasta noviembre de 2028. Es el destino lógico para cualquier migración que empiece este año.
.NET 8 y .NET 9 dejan de tener soporte el 10 de noviembre de 2026. Si tu sistema ya está en alguna de esas versiones, el salto a .NET 10 suele ser corto, pero conviene planificarlo antes de esa fecha.
Antes de empezar: ¿Te conviene migrar?
No siempre. Migrar tiene costo, y un sistema estable que casi no cambia puede seguir tranquilo donde está. Estas son las señales de que llegó el momento:
- Cada cambio pequeño tarda más de lo que debería, o nadie en el equipo quiere tocar ciertas partes.
- Te cuesta encontrar desarrolladores que quieran trabajar con esa tecnología.
- Querés llevar el sistema a la nube, a contenedores o a servidores Linux para bajar costos.
- Necesitás integrar servicios nuevos (pagos, facturación electrónica, inteligencia artificial) y las librerías actuales ya no son compatibles con Framework.
- El rendimiento se volvió un problema a medida que creció la cantidad de usuarios o de datos.
Si te identificás con dos o más, vale la pena por lo menos hacer el diagnóstico.
Paso 1: Inventario antes que código
El error más caro es empezar a migrar sin saber qué hay adentro. Antes de tocar una línea, hacemos un inventario de cada proyecto de la solución y de sus dependencias, y clasificamos todo en tres grupos:
- Se mueve casi directo: lógica de negocio, cálculos, acceso a datos con ADO.NET, la mayoría de los paquetes NuGet populares.
- Necesita adaptación: configuración en
web.config, código que depende deSystem.Web, autenticación, acceso al registro de Windows. - Hay que reescribir: tecnologías que no existen en .NET moderno, como Web Forms, .NET Remoting o los AppDomains.
Este mapa es el que define el alcance, el orden y el presupuesto. Sin él, cualquier estimación es una adivinanza.
Paso 2: Empezar por la base
Las migraciones que salen bien empiezan por abajo: las librerías compartidas que usan todas las pantallas y servicios. La idea es llevarlas a .NET Standard 2.0, o compilarlas para ambos destinos a la vez (por ejemplo net48 y net10.0).
Así, la misma librería de cálculo de precios, impuestos o stock la usan el sistema viejo y el nuevo. No hay dos versiones de la lógica que puedan dar resultados distintos, que es exactamente lo que no querés en un sistema que factura.
Paso 3: Migración incremental, pantalla por pantalla
En lugar de un gran lanzamiento, ponemos un proxy delante del sistema (usamos YARP, el proxy de Microsoft para .NET). Al principio, el proxy manda todo al sistema viejo. Después, a medida que migramos un módulo, esas rutas pasan a atenderse desde la aplicación nueva en .NET 10.
Para el usuario es el mismo sistema, en la misma dirección. Por detrás, cada semana hay un poco menos de código viejo. Con los adaptadores de System.Web, ambas aplicaciones pueden compartir la sesión y el inicio de sesión mientras conviven.
Este enfoque (conocido como strangler fig, por la higuera que crece alrededor de un árbol hasta reemplazarlo) tiene una ventaja enorme: si algo sale mal, se vuelve a apuntar la ruta al sistema anterior en minutos.
Paso 4: Lo que sí hay que reescribir
No todo tiene un camino directo. Esta es la tabla que más consultamos en los diagnósticos:
| Tecnología actual | Camino en .NET moderno |
|---|---|
| ASP.NET MVC / Web API | AdaptaciónPasa a ASP.NET Core. Cambian el arranque, los filtros y la configuración; los controladores se parecen mucho. |
| Web Forms | ReescrituraNo existe en .NET moderno. Se rehace la interfaz con Razor Pages, Blazor o un frontend en JavaScript. |
| WCF (servidor) | AdaptaciónCoreWCF para mantener los contratos, o pasar a APIs REST o gRPC si los clientes lo permiten. |
| Entity Framework 6 | Por etapasEF6 corre sobre .NET moderno, así que puede quedar al principio y pasar a EF Core después. |
| WinForms / WPF | AdaptaciónFuncionan en .NET moderno, solo en Windows. Suele ser de las partes más simples. |
Paso 5: Pruebas que protejan el comportamiento
Antes de mover la lógica crítica escribimos pruebas de caracterización: tests que no validan cómo debería funcionar el sistema, sino cómo funciona hoy. Si una factura da un total con el sistema viejo, tiene que dar exactamente el mismo con el nuevo.
En los módulos más sensibles corremos ambos sistemas en paralelo durante un tiempo y comparamos resultados automáticamente. Recién cuando coinciden, el tráfico pasa al sistema nuevo, primero a un grupo chico de usuarios y después a todos.
Aprendido a la fuerza: Errores comunes que conviene evitar
- Reescribir todo de cero. Parece más limpio, pero pierde años de reglas de negocio que nadie documentó y que solo viven en el código.
- Migrar y agregar funciones al mismo tiempo. Si algo cambia, no sabés si fue la migración o la función nueva. Primero se migra igual; después se mejora.
- Olvidarse de la configuración regional. .NET moderno usa ICU para la globalización, y eso puede cambiar cómo se comparan textos o se formatean fechas y montos. Revisá que los guaraníes, sin decimales, se muestren igual que antes.
- Dejar la infraestructura para el final. Servidores, certificados, tareas programadas y rutas de archivos también se migran, y suelen ser la causa de los sustos del día del lanzamiento.
Una migración bien hecha es aburrida: no hay un gran día de lanzamiento, no hay fines de semana perdidos y el equipo sigue trabajando como siempre. Lo único que cambia es que, al final, el sistema es más rápido, más barato de mantener y está listo para lo que venga.
Volver al blog