Un desarrollador de mi equipo — llamémoslo Nico, porque ese no es su nombre real — pasó una tarde entera tratando de agregar un paquete NuGet a un proyecto que corría sobre .NET Framework 4.8. Nada exótico: una librería conocida para trabajar con JSON, el tipo de cosa que uno espera que simplemente funcione. No funcionó. El paquete solo se publicaba para .NET 6 en adelante. Probó una versión anterior. También estaba descontinuada. Retrocedió dos versiones mayores más hasta encontrar una que todavía soportaba Framework, técnicamente, aunque con una advertencia de que ya no recibía actualizaciones.
Nico vino a hablarme, confundido. "Pensé que .NET Framework todavía estaba soportado." No se equivocaba. Lo está. Microsoft sigue publicando parches de seguridad. Sigue funcionando sin problemas sobre las versiones actuales de Windows. Probablemente seguirá funcionando, en silencio, durante años. Pero "soportado" y "en evolución" son dos promesas distintas, y la distancia entre ambas es exactamente lo que Nico encontró esa tarde.
Este artículo trata sobre esa distancia: qué significa en realidad "sigue soportado" para .NET Framework, por qué esa brecha se agranda en silencio cada año aunque nada se vea roto, y por qué esto es una conversación de planificación, no una alarma de incendio.
Dos promesas distintas, que suelen confundirse
Cuando alguien dice que .NET Framework "está soportado", generalmente se refiere a una cosa concreta: Microsoft va a corregir vulnerabilidades de seguridad, y el framework va a seguir funcionando sobre las versiones de Windows que a su vez sigan soportadas. Esa promesa es real y no va a desaparecer pronto — .NET Framework 4.8 se distribuye como parte del propio Windows, y Microsoft fue explícito en que no va a desconectarlo.
Lo que esa promesa no incluye son funciones nuevas, librerías nuevas ni trabajo activo de rendimiento. Todo eso — cada función nueva del lenguaje C#, cada librería nueva que construye la comunidad de código abierto de .NET, cada ronda de ajuste de rendimiento que los ingenieros de Microsoft le hacen al runtime — va solamente a .NET moderno. .NET Framework dejó de recibir capacidades nuevas hace años. Está terminado, en el sentido en que un libro cerrado está terminado. Se abre exactamente igual cada vez que uno lo toma. Nadie le va a agregar un capítulo nuevo.
Ese es el significado real de "congelado". No abandonado, no inseguro, no urgente — simplemente igual para siempre a como está hoy, mientras todo lo demás en el ecosistema sigue moviéndose.
Por qué la brecha crece en silencio, año tras año
Lo que hace fácil subestimar esto es que una plataforma congelada no se anuncia a sí misma. La aplicación sigue funcionando el lunes por la mañana exactamente igual que el lunes anterior. No hay ningún mensaje de error que diga "ahora está tres años más atrasado que antes". El costo aparece de costado, en momentos pequeños como la tarde de Nico, y se acumula de algunas maneras predecibles.
Primero, cada vez menos librerías nuevas lo soportan. Quienes publican paquetes apuntan a donde está la audiencia, y esa audiencia se mudó a .NET moderno hace años. Cada año, la porción del ecosistema que todavía se toma la molestia de publicar una versión para .NET Framework se achica un poco más.
Segundo, cada vez menos desarrolladores nuevos conocen bien los patrones antiguos. Alguien que empezó su carrera en los últimos cinco o seis años aprendió ASP.NET Core, no Web Forms. Aprendió la inyección de dependencias de la forma moderna, no los patrones en los que suelen apoyarse los proyectos de .NET Framework. Puede aprenderlo, por supuesto, pero es algo adicional que aprender, no su punto de partida, y eso se nota en el tiempo de adaptación y en la contratación (un tema que merece, y tiene, su propio artículo).
Tercero, el hosting sigue reduciéndose. .NET Framework lo ata a Windows. .NET moderno corre en Windows, en Linux y en contenedores livianos, que es hacia donde se movió la mayor parte del hosting barato y flexible. Quedarse en Framework no hace desaparecer su hosting actual, pero sí significa que no puede aprovechar hacia dónde se movió el mercado.
Ninguna de estas cosas se presenta como un incidente. Se presentan como un conjunto de opciones que se achica lentamente, disponible solo para quien lo busca.
Lo que esto no significa
No significa que su aplicación en .NET Framework sea una bomba de tiempo. Si es estable, si cumple su función, si nadie en su equipo pierde el sueño por ella, no hay motivo para tratarla como una emergencia. Trabajé en sistemas que corrieron sobre Framework durante una década sin drama, incluyendo los sistemas centrales de reservas y contenido que mantuve durante años en una agencia de viajes online — software de producción real, atendiendo a clientes reales, todos los días, sobre una plataforma que mucha gente ya llamaba "legacy" mientras cumplía su función en silencio.
Lo que sí significa es que esto merece una decisión deliberada, no una accidental. No "hay que migrar ya mismo", sino "deberíamos saber, a propósito, si este sistema es de los que seguimos corriendo tal cual está, de los que movemos gradualmente hacia adelante, o de los que se están acercando al punto donde quedarse cuesta más que moverse."
Cómo leer la señal correctamente
La pregunta honesta no es "¿sigue soportado?" — sí, lo está, y lo va a seguir estando por un buen tiempo. Las preguntas mejores se acercan más a: ¿este sistema todavía es fácil de conseguir gente para mantenerlo? ¿Las librerías que necesitás para su próxima función están realmente disponibles en esta plataforma? ¿Su hosting se está volviendo más caro o más limitado por dónde está atascado? Esas respuestas cambian despacio, y por eso es fácil pasarlas por alto hasta que un momento como la búsqueda de NuGet de Nico obliga a hacerse la pregunta.
Esa tarde no nos costó más que una hora buscando una alternativa. Pero fue una señal clara y pequeña de dónde está realmente la plataforma hoy, y esas señales merecen atención antes de que se acumulen en una decisión más grande, tomada bajo presión. Una auditoría es la versión deliberada de ese mismo control — una mirada estructurada sobre exactamente dónde está un sistema en ese espectro, antes de que algo obligue la pregunta.