El 10 de noviembre de 2026, Microsoft deja de enviar actualizaciones de seguridad para dos versiones de .NET el mismo día: .NET 8 y .NET 9. Después de esa fecha, ninguna vulnerabilidad descubierta en la plataforma se corregirá en ninguna de las dos versiones. Si tu sistema contable, tu punto de venta o tu ERP está construido sobre una de ellas —y en el mercado saudí muchos lo están—, tienes menos de dos meses para decidir hacia dónde vas. Para la mayoría de las empresas, el destino correcto es .NET 10, con soporte hasta el 14 de noviembre de 2028, y no .NET 11, cuya primera versión candidata salió hace apenas dos días.

Qué ocurrió el 8 de septiembre

El 8 de septiembre de 2026, Microsoft anunció que .NET 11 había alcanzado la Release Candidate 1, con una licencia de soporte go-live, lo que significa que Microsoft respalda oficialmente su uso en producción real antes de que salga la versión final. Ese mismo día se publicaron las actualizaciones de mantenimiento habituales para .NET 10, .NET 9 y .NET 8.

Esa es la noticia técnica. La noticia que le importa al dueño de un negocio está en una página completamente distinta: la página oficial de la política de soporte, actualizada ese mismo día, que dice claramente que .NET 8 y .NET 9 salen del soporte el 10 de noviembre de 2026. El vistoso anuncio de la versión se lleva la atención; la línea que te cuesta dinero de verdad está escrita en una tabla aburrida.

Por qué una versión de "soporte a largo plazo" se queda sin soporte

Microsoft publica una versión principal de .NET cada noviembre. Las versiones pares son de soporte a largo plazo y reciben tres años de parches gratuitos; las impares son de soporte estándar y reciben dos.

.NET 8 salió el 14 de noviembre de 2023, así que sus tres años vencen en noviembre de 2026. .NET 9 salió el 12 de noviembre de 2024, así que sus dos años vencen aproximadamente en el mismo momento. Por eso ambas coinciden en el 10 de noviembre. Aquí es donde los equipos se llevan la sorpresa: "soporte a largo plazo" no significa soporte para siempre. Significa tres años contados desde el día del lanzamiento, y buena parte de ese reloj ya ha corrido sin que nadie lo vigilara.

El destino correcto es .NET 10, no .NET 11

La reacción refleja ante una noticia así es "entonces actualizamos a la más nueva". Para la mayoría de los sistemas empresariales esa es la decisión equivocada, y la razón está en la misma tabla de soporte.

.NET 10 salió el 11 de noviembre de 2025, es una versión de soporte a largo plazo y tiene soporte hasta el 14 de noviembre de 2028. Una sola actualización te da algo más de dos años de estabilidad sin volver a abrir el expediente. .NET 11 es una versión impar, así que solo tiene dos años de soporte estándar y quedará sin soporte antes que .NET 10, a pesar de ser más reciente. Actualizar a una versión más nueva que caduca antes no es una actualización: es un aplazamiento con una factura adicional.

Hay una segunda consideración. La propia versión candidata de .NET 11 solo tiene soporte hasta el 13 de octubre de 2026, porque es una compilación de transición de la que se espera que salgas: a la siguiente candidata y luego a la versión de noviembre. Quien lea "go-live" como una invitación a instalar una versión candidata en un sistema contable y dejarla ahí se ha apuntado a un ciclo de actualizaciones mensual en lugar de librarse de uno.

La regla práctica para una empresa que usa software contable u operativo: apunta siempre a la versión par de soporte a largo plazo. Deja las impares a los equipos de producto que actualizan continuamente y quieren las funciones cuanto antes.

Qué trae realmente .NET 11

Para que la decisión se base en el conocimiento y no en la evasión, esto es lo que incluye la versión candidata. En C#, la versión 15 estabilizó los tipos unión, una forma más clara de expresar un valor que puede tomar más de una forma, como una operación que o bien tiene éxito o bien falla por un motivo concreto. En las herramientas, el comando de pruebas mejoró su manejo de las aplicaciones móviles y añadió controles a nivel de ejecución.

En la publicación de contenedores, la generación de imágenes ahora es reproducible y evita volver a subir capas que ya existen, lo que acorta el tiempo de despliegue y facilita auditar lo que has entregado. En la gestión de paquetes, actualizar paquetes con vulnerabilidades conocidas ahora funciona incluso cuando las advertencias se tratan como errores, un viejo obstáculo que obligaba a los equipos a desactivar la comprobación de seguridad solo para que una compilación pasara. En ASP.NET Core, se finalizaron las API de renovación de autenticación de SignalR, y los circuitos de Blazor Server ahora actualizan su estado tras una renovación en lugar de conservar una identidad obsoleta. En los sistemas Unix llegaron los informes de fallos en proceso, lo que significa mejores diagnósticos cuando un servidor se cae a las tres de la madrugada.

Son mejoras reales. Ninguna de ellas compensa el riesgo de ejecutar un sistema financiero sobre una versión que caduca antes que la alternativa.

Por qué esto es un asunto de cumplimiento, no técnico

Ejecutar una plataforma que ya no recibe parches de seguridad no es una cuestión de preferencia de ingeniería. La Ley de Protección de Datos Personales (PDPL) obliga a toda organización que maneja datos de clientes a aplicar medidas de protección adecuadas, y cualquier revisión de seguridad seria preguntará qué versión de la plataforma utilizas y cuándo termina su soporte. "Estamos en una versión que quedó sin soporte hace ocho meses" no es una respuesta que puedas defender ante un auditor, ante un cliente corporativo que te envía un cuestionario de seguridad antes de firmar o ante una aseguradora de riesgos cibernéticos.

Lo mismo se aplica a los sistemas de facturación electrónica conectados a la plataforma Fatoora. Un sistema que firma digitalmente las facturas y las transmite a una autoridad gubernamental necesita estar sobre una plataforma que todavía reciba parches criptográficos. No es un detalle interno: forma parte de la cadena de confianza en la que se apoya tu factura.

Un plan de acción de aquí a noviembre

  • Esta semana: averigua dónde estás. Pide a tu proveedor o a tu equipo técnico un inventario de la versión de .NET detrás de cada sistema que utilizas, incluidas las pequeñas herramientas internas y los servicios en segundo plano en los que nadie piensa. En un servidor, dotnet --list-runtimes lo muestra; en el propio proyecto, es la entrada del framework de destino en el archivo del proyecto.
  • La próxima semana: clasifica. Marca todo lo que esté en .NET 8 o anterior y todo lo que esté en .NET 9. Lo que ya está en .NET 10 está a salvo hasta 2028. Lo que está en .NET 6 o 7 lleva años sin soporte y necesita atención urgente, no un calendario.
  • En dos semanas: lee los cambios incompatibles. Microsoft publica una lista de cambios incompatibles para cada versión. Pasar de 8 a 10 suele ser sencillo, pero leerla antes de empezar ahorra días.
  • En un mes: actualiza primero el entorno de pruebas. Cambia el framework de destino, compila, ejecuta las pruebas y luego pon el sistema a funcionar con una copia de datos reales antes que nada.
  • Antes de noviembre: despliega. Deja al menos dos semanas de margen de seguridad antes del 10 de noviembre, y no despliegues durante un cierre de mes ni en plena temporada alta de ventas.
  • Una vez y para siempre. Anota hoy el 14 de noviembre de 2028 en el calendario de la empresa y fija una regla: cada actualización va a la siguiente versión par. Así esto deja de ser una sorpresa anual y se convierte en una partida presupuestaria conocida.

Si el sistema lo suministró un proveedor

Muchas empresas no son dueñas del código fuente; compran un sistema terminado a un proveedor. En ese caso, el único correo que debes enviar hoy pregunta tres cosas: con qué versión de .NET funciona el sistema, cuándo entregará una versión sobre .NET 10 y si la actualización está cubierta por nuestro contrato de soporte o se factura aparte. La forma en que responda tu proveedor te dice más sobre el producto que cualquier presentación. Y el proveedor que no sabe la respuesta, o da largas, es el mismo al que estarás llamando el 11 de noviembre.

Fuentes

  • Microsoft — Announcing .NET 11 Release Candidate 1, 8 de septiembre de 2026: devblogs.microsoft.com
  • Microsoft — política oficial de soporte de .NET y fechas de fin de soporte: dotnet.microsoft.com
  • Microsoft — Cambios incompatibles en .NET 11: learn.microsoft.com
  • Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA) — Ley de Protección de Datos Personales (PDPL): sdaia.gov.sa