Fin del soporte de .NET 8 y .NET 9 el 10 de noviembre: qué pasa y cómo pasar a .NET 10

El 10 de noviembre de 2026, .NET 8 y .NET 9 dejan de recibir parches. Si tienes una API o una aplicación web en cualquiera de las dos, el día 11 seguirá arrancando como si nada. Y precisamente por eso es fácil dejarlo para más adelante.

En el último año he pasado a .NET 10 dos aplicaciones en producción: E3M, el ERP de EPMTIC, desde .NET 8, y Power Time, desde .NET 9. Aquí te cuento qué significa el fin de soporte, qué cambió en esas migraciones y qué pasos seguiría si tuviera que hacerlo esta semana.

Qué significa “fin de soporte” (y qué no)

Según el anuncio de Microsoft, a partir del 10 de noviembre no habrá más actualizaciones de mantenimiento, correcciones de seguridad ni soporte técnico para .NET 8 ni para .NET 9. Puede que ambos reciban una última actualización ese mismo día si hay un problema crítico conocido. Después, se acabó.

Tu aplicación no se apaga. Lo que pasa es más silencioso: cuando se publique la próxima vulnerabilidad del runtime o de ASP.NET Core, el parche saldrá para las versiones con soporte y no para la tuya. Si la aplicación está expuesta a internet, ese hueco se queda abierto.

Dos aclaraciones:

• .NET 9 se acaba a la vez que .NET 8 porque Microsoft amplió el soporte de las versiones STS de 18 a 24 meses. Iba a terminar en mayo y se movió a noviembre.
• .NET Framework 4.8 no está en esta lista. Se soporta como parte de Windows. Si tu aplicación es de Web Forms o WinForms sobre .NET Framework, tu problema es distinto (hablo de él al final), pero no tiene fecha el 10 de noviembre.

Y si aún estás en .NET 6, llevas sin parches desde noviembre de 2024.

El destino es .NET 10, que es LTS y tiene soporte hasta el 14 de noviembre de 2028.

Cómo fueron dos migraciones reales

Power Time, de .NET 9 a .NET 10. El cambio cupo en un commit de 18 ficheros. La mayor parte fue de proyecto: subir la versión, actualizar paquetes y cambiar las imágenes de Docker. Aproveché para centralizar las versiones de los paquetes en un Directory.Packages.props, que es lo que más ficheros tocó. En código hubo tres ajustes pequeños: el transformador del esquema de seguridad de OpenAPI, el nombre de una propiedad de las cabeceras reenviadas (KnownNetworks pasa a KnownIPNetworks) y la creación de credenciales en el servicio de notificaciones push, por la actualización de su paquete.

E3M, de .NET 8 a .NET 10. Aquí hay dos cosas que merece la pena contar.

La primera tiene que ver con la configuración. En .NET 10, el proveedor de configuración JSON ya no convierte los null en cadenas vacías: ahora llegan como null y se enlazan como tales. Una clave que esté a null en un appsettings.json y que el código trate como “vacía, usa el valor por defecto” pasa a ser null. En E3M no había ningún null en la configuración, pero el código daba por hecho que esas claves existían. Antes de desplegar añadí una validación al arrancar de las claves obligatorias, con un mensaje que dice exactamente cuál falta.

La segunda: al actualizar salió deuda que ya estaba ahí. Tres campos eran NOT NULL en la base de datos, pero el modelo de Entity Framework los veía como opcionales. No era un problema de .NET 10; llevaba tiempo así y nadie lo había notado. Lo detectó dotnet ef migrations has-pending-model-changes, que pasé antes y después de subir de versión. Mejor que salga en tu máquina que en producción.

También cambió la API de seguridad de Swashbuckle 10: si declaras el requisito de seguridad con AddSecurityRequirement, hay que adaptarlo a OpenApiSecuritySchemeReference y al nuevo espacio de nombres Microsoft.OpenApi.

Los pasos, en orden

Así lo haría hoy con una aplicación ASP.NET Core en .NET 8 o 9.

1. Fija el SDK. Un global.json en la raíz evita que cada máquina o cada pipeline compile con un SDK distinto:

{
  "sdk": {
    "version": "10.0.100",
    "rollForward": "latestFeature"
  }
}

2. Cambia el framework de destino en cada proyecto (o una sola vez en Directory.Build.props si lo tienes):

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

3. Actualiza los paquetes de Microsoft (Microsoft.AspNetCore.*, Microsoft.EntityFrameworkCore.*, Microsoft.Extensions.*) a la versión 10 y revisa los de terceros. Swashbuckle, por ejemplo, tiene cambios propios en su versión 10.

4. Cambia las imágenes de Docker:

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
# ...
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime

5. Valida la configuración al arrancar. Es la defensa contra el cambio de los null, y merece la pena aunque no migres:

using System.ComponentModel.DataAnnotations;

public sealed class JwtOptions
{
    [Required] public string Key { get; set; } = "";
    [Required] public string Issuer { get; set; } = "";
    [Required] public string Audience { get; set; } = "";
}

builder.Services.AddOptions<JwtOptions>()
    .Bind(builder.Configuration.GetSection("Jwt"))
    .ValidateDataAnnotations()
    .ValidateOnStart();

Si alguna clave falta, o llega como null o vacía, la aplicación falla al arrancar con un error que nombra la propiedad, en lugar de fallar en la primera petición que la use.

6. Comprueba el modelo de datos. Si usas Entity Framework Core (con la herramienta dotnet-ef y el paquete Microsoft.EntityFrameworkCore.Design), este comando te dice si el modelo y las migraciones están desalineados, que es justo lo que me encontré en E3M. Ejecútalo una vez por cada DbContext:

dotnet ef migrations has-pending-model-changes --context MiDbContext

7. Lee las listas de cambios incompatibles de .NET 9 (si vienes de .NET 8) y de .NET 10, filtrando por lo que usas. Después, pasa los tests y despliega primero en un entorno de pruebas.

Una nota sobre herramientas: Microsoft ha marcado como obsoleto el .NET Upgrade Assistant y recomienda en su lugar el agente de modernización de GitHub Copilot. Para un salto de .NET 8 a .NET 10 con una buena batería de tests, en mi experiencia no hace falta un asistente de migración específico: el cambio es asequible y entender cada ajuste compensa.

Si lo tuyo es .NET Framework

Si tu aplicación está en .NET Framework 4.8 (o en 4.6.2 o posterior; las anteriores ya no tienen soporte), no tienes la urgencia del 10 de noviembre, pero el salto es otro. Web Forms no existe en .NET moderno, así que no es cambiar una versión: hay que rehacer la capa web conservando la lógica de negocio. Es lo que hago en la modernización de aplicaciones .NET, y la estrategia (de golpe o por partes) la explico en modernizar un ERP legacy.

Lo que haría esta semana

Abre una terminal en la carpeta donde tengas tus repositorios y busca qué versión usa cada proyecto:

grep -r --include='*.csproj' --include='Directory.Build.props' "<TargetFramework" .

Si ves net8.0, net9.0 o, peor, net6.0 en algo que está en producción, ya sabes qué hay que planificar. Si son muchas aplicaciones, o no tienes tests que te den confianza, empieza por una auditoría técnica: en una semana te dice qué hay, qué se rompe al subir de versión y en qué orden hacerlo.

Recursos

• Anuncio de Microsoft: fin de soporte de .NET 8 y .NET 9
• Política de soporte de .NET
• Cambios incompatibles en .NET 9
• Cambios incompatibles en .NET 10
• Servicios de modernización de VisibleSoft