.NET 8 llega al fin de su soporte: es hora de preparar la migración de las aplicaciones GeneXus a .NET 10
Hay una fecha que quienes mantenemos aplicaciones GeneXus sobre .NET deberíamos marcar en el calendario:
10 de noviembre de 2026.
Ese día Microsoft finaliza el soporte de .NET 8, actualmente una versión LTS —Long Term Support— muy utilizada en aplicaciones empresariales. A partir de ese momento las aplicaciones seguirán funcionando, pero Microsoft dejará de proporcionar actualizaciones de seguridad y soporte para esa versión.
La versión LTS que la reemplaza es .NET 10, liberada por Microsoft en noviembre de 2025 y con soporte previsto hasta noviembre de 2028.
Para quienes desarrollamos con GeneXus, esto significa que durante los próximos meses tendremos que planificar la migración de nuestras aplicaciones.
Pero el camino depende bastante de dónde estemos hoy.
GeneXus y la evolución de .NET
GeneXus viene acompañando la evolución de la plataforma .NET desde hace muchos años.
Con GeneXus 18 Upgrade 7, liberado en diciembre de 2023, GeneXus incorporó la generación para .NET 8.
Al mismo tiempo, GeneXus fue tomando una decisión importante respecto a la plataforma anterior.
A partir de GeneXus 18 Upgrade 8, el generador .NET Framework fue declarado Legacy. Esto significa que GeneXus dejó de evolucionarlo funcionalmente y recomendó migrar las aplicaciones hacia el nuevo generador .NET.
El generador moderno, anteriormente llamado .NET Core Generator, pasó simplemente a llamarse .NET Generator, siguiendo también el cambio de nombre realizado por Microsoft.
Actualmente genera aplicaciones ASP.NET Core y es la plataforma sobre la cual GeneXus continúa incorporando las nuevas versiones de .NET.
.NET 10 llega con GeneXus 18 Upgrade 16
El siguiente paso de esta evolución es GeneXus 18 Upgrade 16, que incorpora oficialmente en sus características el soporte de .NET 10.
Hay, sin embargo, un detalle importante.
Al 31 de agosto de 2026, GeneXus 18 Upgrade 16 todavía figura en la documentación oficial como Preview. La última versión liberada en forma estable es GeneXus 18 Upgrade 15, publicada el 6 de mayo de 2026.
Por lo tanto, hoy podemos comenzar las pruebas de compatibilidad con Upgrade 16, pero para ambientes productivos probablemente sea conveniente esperar su liberación definitiva.
La documentación oficial consultada todavía no publica una fecha concreta de disponibilidad general de Upgrade 16.
De todas formas, la dirección tecnológica ya está definida:
GeneXus 18 + .NET 10 será el camino para mantener las aplicaciones .NET sobre una plataforma LTS soportada.
No alcanza con instalar .NET 10 en el servidor
Este punto es particularmente importante.
Una aplicación generada con GeneXus 18 Upgrade 15 para .NET 8 no se transforma en una aplicación .NET 10 simplemente instalando el runtime de .NET 10 en el servidor.
El framework objetivo forma parte del proyecto generado por GeneXus.
Por lo tanto, la migración implica:
actualizar GeneXus → regenerar → recompilar → probar → empaquetar → desplegar nuevamente.
Esto también significa que hay que revisar los ambientes de desarrollo, servidores de Build, pipelines Jenkins o similares, imágenes Docker y servidores de ejecución.
Escenario 1: GeneXus 18 Upgrade 7 a Upgrade 15 usando .NET
Este debería ser el caso más sencillo.
La aplicación ya utiliza el generador moderno .NET y actualmente genera para .NET 8.
En este escenario mi recomendación sería:
Instalar GeneXus 18 Upgrade 16 inicialmente en un ambiente separado.
Instalar el SDK de .NET 10 en las máquinas de desarrollo y servidores de Build.
Abrir una copia de la Knowledge Base.
Ejecutar un Rebuild All.
Corregir eventuales incompatibilidades.
Generar todos los Deployment Units.
Crear un ambiente de TEST con .NET 10.
Ejecutar pruebas funcionales, de integración y rendimiento.
Actualizar posteriormente los ambientes de producción.
En aplicaciones grandes conviene comenzar este proceso antes de la liberación definitiva de Upgrade 16, utilizando Preview únicamente para detectar incompatibilidades.
La migración productiva puede hacerse cuando Upgrade 16 esté liberado.
Escenario 2: versiones anteriores usando .NET Core o .NET
El escenario requiere algo más de cuidado cuando todavía tenemos aplicaciones generadas con versiones antiguas de GeneXus que utilizan .NET Core, .NET 6 u otras versiones que ya han llegado al final de su ciclo de soporte.
En estos casos no recomendaría realizar migraciones intermedias de runtime.
El objetivo debería ser directamente:
versión GeneXus actual → GeneXus 18 Upgrade 16 → .NET 10.
Dependiendo de la antigüedad de la Knowledge Base puede ser necesario analizar primero las incompatibilidades introducidas entre versiones de GeneXus.
Especial atención merecen:
User Controls.
Extensions.
Patterns.
módulos externos.
librerías propias.
External Objects.
componentes NuGet.
código C# incorporado manualmente.
mecanismos personalizados de deployment.
Cuanto más antigua sea la versión de GeneXus, más conveniente será separar el proyecto en dos problemas diferentes:
primero actualizar la Knowledge Base y después validar la nueva plataforma de ejecución.
Escenario 3: aplicaciones que todavía utilizan .NET Framework
Este es el escenario que merece mayor atención.
No estamos simplemente cambiando de .NET Framework 4.x a una nueva versión del runtime.
Estamos cambiando de plataforma.
GeneXus considera al generador .NET moderno como la evolución del generador .NET Framework, pero existen diferencias importantes entre ambos.
Por eso, para una aplicación que todavía utiliza el generador .NET Framework recomiendo considerar la migración como un pequeño proyecto tecnológico.
1. Crear un nuevo Environment .NET dentro de la Knowledge Base
El primer paso debería ser crear un nuevo Environment utilizando el generador .NET, manteniendo temporalmente el Environment .NET Framework existente.
Esto permite trabajar en paralelo:
Environment actual → .NET Framework
Nuevo Environment → .NET
Hay un punto especialmente importante durante este proceso:
hay que copiar y revisar cuidadosamente TODAS las propiedades comunes del Environment anterior al nuevo.
No conviene asumir que, por estar ambos Environments dentro de la misma Knowledge Base, toda la configuración se trasladará automáticamente.
Hay que comparar propiedad por propiedad, incluyendo especialmente:
Data Stores y conexiones a base de datos;
propiedades del DBMS;
Application Server;
configuración web;
propiedades de generación;
namespaces;
configuración de GAM;
configuración de GXflow;
URLs y paths;
configuración de servicios;
propiedades de seguridad;
manejo de sesiones;
variables y parámetros utilizados por la aplicación;
propiedades específicas que hayan sido modificadas respecto de los valores por defecto.
También conviene revisar propiedades heredadas desde otros niveles de la Knowledge Base, porque una propiedad que aparentemente no estaba configurada explícitamente en el Environment anterior puede estar afectando la generación por herencia.
La recomendación es sencilla:
antes de generar con el nuevo Environment, comparar sistemáticamente las propiedades del Environment .NET Framework con las del nuevo Environment .NET.
En Knowledge Bases grandes puede ser útil mantener una checklist de propiedades o incluso automatizar esta comparación.
2. Generar inicialmente sin eliminar el Environment anterior
Una vez configurado el nuevo Environment, conviene realizar una primera generación y un Rebuild All sin modificar ni eliminar todavía el Environment .NET Framework.
Esto permite comparar ambos resultados y volver rápidamente al ambiente anterior cuando sea necesario investigar alguna diferencia.
La migración debería realizarse de forma incremental, no destruyendo el ambiente conocido antes de validar el nuevo.
3. Revisar las diferencias entre .NET Framework y .NET
Una aplicación .NET Framework utiliza tradicionalmente web.config, mientras que una aplicación .NET moderna utiliza principalmente appsettings.json.
También cambia la arquitectura de ejecución.
Una aplicación .NET moderna ejecuta ASP.NET Core sobre Kestrel, incluso cuando IIS se utiliza como servidor frontal.
Los Procedures Main también cambian su forma de ejecución: en lugar del tradicional .exe, normalmente se ejecuta un .dll mediante dotnet.
Por lo tanto, hay que revisar particularmente:
configuración de
web.config;migración de configuraciones hacia
appsettings.json;variables de ambiente;
manejo de sesiones;
autenticación;
integración con IIS;
configuración de Kestrel;
librerías .NET propias;
componentes de terceros;
External Objects;
procedimientos Main y procesos batch;
servicios REST;
acceso a archivos;
logging;
criptografía;
envío de correo;
acceso a base de datos;
código C# externo.
4. Revisar dependencias externas
Este suele ser uno de los puntos donde aparecen más problemas.
Una librería utilizada durante años por una aplicación .NET Framework puede no ser compatible con .NET moderno.
Por eso hay que inventariar las DLL y componentes externos utilizados por la Knowledge Base y determinar para cada uno:
si existe una versión compatible con .NET;
si debe actualizarse;
si debe reemplazarse;
o si la funcionalidad puede resolverse actualmente utilizando capacidades estándar de GeneXus o .NET.
Especial atención merecen las librerías desarrolladas internamente y aquellas que dependen directamente de APIs exclusivas de .NET Framework.
5. Probar primero la generación y después la infraestructura
Conviene separar dos tipos de problemas.
Primero verificar:
¿La Knowledge Base genera y compila correctamente utilizando el nuevo generador .NET?
Una vez resuelto eso, verificar:
¿La aplicación puede ejecutarse correctamente en la nueva infraestructura?
Separar ambas etapas simplifica considerablemente el diagnóstico.
6. Mantener ambos Environments durante las pruebas
Durante la migración puede ser conveniente mantener temporalmente:
Environment .NET Framework → referencia / producción actual
Environment .NET → migración / TEST
Esto permite comparar comportamiento, resultados, configuraciones y rendimiento.
Una vez validado completamente el Environment .NET y realizada la migración productiva, recién entonces puede evaluarse eliminar el Environment anterior.
La buena noticia es que GeneXus genera nuevamente gran parte de la aplicación.
Ese es precisamente uno de los beneficios de trabajar con una plataforma basada en modelos: podemos regenerar el sistema para una plataforma tecnológica diferente sin tener que reescribir manualmente toda la aplicación.
Pero esa capacidad no sustituye el trabajo de migración.
El modelo puede ser el mismo, pero cambian el generador, el runtime, la configuración y posiblemente parte de la infraestructura.
Por eso, en este escenario la secuencia que recomiendo es:
crear nuevo Environment .NET → copiar y revisar todas las propiedades → Rebuild All → resolver incompatibilidades → probar dependencias → probar infraestructura → TEST → PREPRODUCCIÓN → PRODUCCIÓN.
Y solamente después de completar ese proceso retirar el antiguo Environment .NET Framework.
Cómo organizar la migración
En organizaciones con muchas Knowledge Bases evitaría tratar la migración como una sucesión de proyectos independientes.
Conviene crear primero una metodología común.
1. Hacer un inventario
Clasificar cada aplicación por:
versión GeneXus;
generador;
versión .NET;
sistema operativo;
servidor IIS/Kestrel;
base de datos;
uso de GAM/GXflow;
Deployment Units;
bibliotecas externas;
User Controls y Extensions;
De esta forma rápidamente aparecen los grupos de aplicaciones que pueden migrarse utilizando la misma estrategia.
2. Crear una aplicación piloto
No empezaría por la aplicación más crítica ni por la más sencilla.
Elegiría una aplicación de complejidad media que represente razonablemente la arquitectura utilizada por la empresa.
Ese proyecto permitirá descubrir los problemas reales de la migración y convertirlos después en una checklist reutilizable.
3. Automatizar el Build
La prueba real de una migración no debería ser únicamente:
"Compila en mi PC".
Debería poder realizarse automáticamente:
Checkout → Build/Rebuild → Test → Package → Deploy.
El servidor de integración continua también deberá tener instalado el SDK de .NET 10 y las versiones correspondientes de GeneXus.
4. Crear un ambiente paralelo
Durante un tiempo conviene mantener:
Producción actual → .NET 8
y
TEST/PREPRODUCCIÓN → .NET 10
Esto permite realizar pruebas funcionales, integraciones, carga y rendimiento antes de realizar el cambio definitivo.
5. Probar las interfaces, no solamente las pantallas
Los principales problemas de estas migraciones frecuentemente no aparecen en la interfaz de usuario.
Hay que probar especialmente:
APIs REST;
autenticación OAuth/GAM;
servicios externos;
procesos batch;
generación de documentos;
envío de correo;
filesystem;
uploads/downloads;
integraciones;
observabilidad y logging.
6. Medir rendimiento antes y después
La migración también es una oportunidad para establecer una línea base.
Antes de migrar conviene medir tiempos de respuesta, consumo de memoria, CPU y ejecución de procesos importantes.
Después podemos comprobar que la aplicación .NET 10 mantiene o mejora esos valores.
No esperaría a noviembre
El 10 de noviembre de 2026 no debería ser la fecha para empezar la migración.
Debería ser la fecha para la cual las aplicaciones críticas ya estén ejecutándose sobre una versión soportada.
.NET 8 seguirá funcionando después de esa fecha. El problema es otro: dejará de recibir el mantenimiento y las actualizaciones de seguridad correspondientes de Microsoft.
Y en sistemas empresariales, especialmente aquellos expuestos a Internet o sujetos a políticas de seguridad, permanecer indefinidamente sobre un runtime sin soporte no parece una buena estrategia.
Tenemos además una ventaja importante.
En una aplicación GeneXus, buena parte de esta evolución tecnológica puede resolverse regenerando desde el modelo.
Eso no significa que la migración sea automática.
Pero sí significa que debería ser considerablemente más sencilla que migrar una aplicación escrita y mantenida completamente a mano.
El camino está bastante claro:
.NET Framework → .NET moderno → .NET 10
o, para quienes ya estamos en .NET 8:
GeneXus 18 U15 o anterior → GeneXus 18 U16 → .NET 10.
El momento de empezar a probarlo es ahora.
Comentarios
Publicar un comentario
1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.