Migrar de .NET 8 a .NET 11: la lista de verificación completa

Corrección — 2 de noviembre de 2026: .NET 11 se describía incorrectamente como una versión LTS ya publicada. También se corrigen selección del SDK, paquetes, hosting, serialización, consultas EF, bloqueos y rollback. Las afirmaciones anteriores sobre resultados de migraciones no tenían pruebas registradas.

El soporte de .NET 8 termina el 10 de noviembre de 2026. La política actual identifica .NET 10 como LTS y .NET 11 RC3 como versión preliminar go-live. .NET 11 es una línea STS. Para un destino LTS ya publicado, evalúe .NET 10. Si necesita .NET 11, acepte explícitamente su estado actual y planifique la siguiente actualización. Actualizar el SDK no actualiza aplicaciones ya desplegadas.

1. Registrar la referencia y elegir el SDK

Registre runtime desplegado, SDK, sistema operativo, dependencias, resultados de pruebas y comportamiento representativo. Una referencia verde ayuda a detectar regresiones, pero no demuestra que cualquier fallo posterior sea causado por la migración.

dotnet --info
dotnet --list-sdks
dotnet --version
dotnet list package --include-transitive
dotnet test -c Release

Ejecute los comandos en el directorio de la solución con el SDK previsto. La selección del SDK es independiente del framework objetivo. Para evaluar la versión completa RC3 de la página de descarga, utilice este global.json:

{
  "sdk": {
    "version": "11.0.100-rc.3.26522.148",
    "rollForward": "disable",
    "allowPrerelease": true
  }
}

disable exige ese SDK exacto; latestFeature permite bandas posteriores. Instale el SDK elegido también en CI. Se comprobó esta versión RC3 contra metadatos publicados, pero no se instaló ni ejecutó para el artículo. Actualícela deliberadamente al cambiar de versión.

2. Cambiar el destino y revisar cada dependencia

La estructura mínima de un proyecto web es:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net11.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

Es una definición para .NET 11, no un proyecto probado aquí en .NET 11. Deje la versión del lenguaje en el valor predeterminado del SDK/TFM salvo una razón concreta. C# 14 corresponde a .NET 10; no es la nueva versión de lenguaje de .NET 11.

No actualice todos los paquetes Microsoft.* a versión 11. Cada producto tiene su propia línea. Compruebe frameworks, dependencias, proveedores y estado de publicación. Alinee paquetes EF Core, proveedor, paquete de diseño y herramientas según su documentación. Revise Directory.Packages.props si usa administración centralizada. Un paquete net8.0 puede seguir siendo compatible; NuGet no prefiere automáticamente un recurso .NET Standard antiguo porque el destino sea más nuevo.

3. Revisar los cambios de cada versión intermedia

Lea las listas de .NET 9, .NET 10 y .NET 11, además de las notas de frameworks y proveedores. La lista de .NET 11 sigue explícitamente en elaboración.

• BinaryFormatter: Desde .NET 9, la implementación incorporada lanza una excepción; los tipos de API siguen existiendo. Prefiera otro formato. La guía de migración explica cómo leer NRBF sin construir tipos serializados arbitrarios. Convertir no exige necesariamente ejecutar la aplicación antigua en .NET 8.
• Hosting: WebHostBuilder, IWebHost y WebHost se marcaron obsoletos en .NET 10. Eso no demuestra que se haya eliminado todo código IWebHostBuilder o ConfigureWebHostDefaults. Prefiera WebApplication.CreateBuilder para código nuevo y atienda diagnósticos reales.
• Consultas EF: Para SQL Server, EF8 introdujo parámetros JSON para colecciones; EF10 usa parámetros escalares por defecto. Inspeccione SQL y planes con su proveedor real. Añadir ToList() indiscriminadamente puede llevar trabajo a memoria; no es una solución universal.
• Serialización y compilación: Pruebe contratos JSON reales, fechas, números, enums y polimorfismo. Investigue diagnósticos concretos, incluidas conversiones span, sin asumir que toda sobrecarga span gana a una de array.
• Bloqueos: System.Threading.Lock y Monitor son reentrantes. Un Lock con tipo estático usa un mecanismo distinto de una referencia convertida a object; no los mezcle para el mismo estado protegido. Cambiar bloqueos es opcional.
• Servicios alojados: Azure Functions tiene su propia matriz de soporte. En esta revisión, el máximo destino isolated worker es .NET 10; el soporte in-process termina el 10 de noviembre de 2026. La disponibilidad del SDK no prueba soporte de .NET 11.

4. Verificar el artefacto desplegado

Este Program.cs completo ofrece un endpoint de humo. No configura autenticación, controladores ni base de datos de producción:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
app.Run();

dotnet restore
dotnet build -c Release --no-restore
dotnet test -c Release --no-build
dotnet publish -c Release --self-contained false

El ejemplo se compiló, publicó y consultó correctamente en .NET 8.0.33 y 10.0.10. --self-contained false requiere un runtime compatible en el host. Para un despliegue autocontenido, elija un RID real y --self-contained true; pruebe el resultado en el SO de destino. /health no aparece automáticamente en cualquier proyecto.

Pruebe también autenticación, autorización, contratos de lectura/escritura, transacciones, tareas en segundo plano y rollback en staging. Mida una carga acordada. Con trimming o AOT, resuelva advertencias concretas y ejecute el resultado publicado; las anotaciones no hacen compatible cualquier generación dinámica de código con Native AOT.

5. Mantener un rollback compatible

Conserve el artefacto anterior y su configuración. Esquema, datos persistidos, mensajes y estado de autenticación determinan si ambas versiones pueden coexistir. La primera escritura no impide automáticamente volver atrás y cambiar SDK no genera una migración de base de datos. Use cambios compatibles y ensaye la reversión del tráfico antes del corte.

Límites de verificación: No se ejecutó una migración .NET 11, actualización EF/base de datos, despliegue Azure ni comparación de rendimiento. El ejemplo portable y algunas correcciones se probaron en .NET 8/10; la información específica de versión se contrastó con documentación primaria.

Otras fuentes primarias

• System.Threading.Lock
• C# 14 span overload resolution
• .NET application publishing