.NET 11 RC1 puede usarse en producción con soporte de Microsoft, pero eso no convierte al release candidate en una versión final ni hace que la actualización sea adecuada para cualquier sistema. La diferencia práctica de la condición go-live es que RC1 dejó atrás la categoría de preview sin soporte: Microsoft lo trata como una versión preliminar con soporte en producción. La decisión de adoptarlo ahora, sin embargo, sigue dependiendo de la compatibilidad, las dependencias, la capacidad de actualizar con rapidez y la tolerancia a cambios antes de GA.
Qué significa “go-live” en .NET 11 RC1
.NET 11 RC1 se publicó el 8 de septiembre de 2026. En el anuncio oficial, el equipo de .NET describe RC1 como el primero de dos release candidates e informa que incluye una licencia de soporte go-live para aplicaciones de producción. La política de soporte de Microsoft define go-live como una versión preliminar, normalmente un RC, que está soportada por Microsoft en producción.
Sin embargo, existe una ventana específica: la tabla oficial de soporte indica que .NET 11 RC1 está soportado desde el 8 de septiembre hasta el 13 de octubre de 2026. El lanzamiento final de .NET 11 está previsto para el 10 de noviembre de 2026. Por eso, quien lleve RC1 a producción debe planificar desde el principio la migración a la siguiente build soportada y, después, a GA.
Fuentes oficiales: anuncio de .NET 11 RC1, política de soporte de .NET y calendario de versiones de .NET.
Go-live no significa “listo para cualquier producción”
La condición resuelve una cuestión de soporte del producto, no el análisis de riesgo de tu aplicación. Un RC puede ser lo bastante maduro para cargas reales y aun así cambiar antes de la versión final. La propia documentación de breaking changes de .NET 11 advierte que la lista sigue en elaboración y puede no estar completa.
Por eso, la pregunta correcta no es solo “¿Microsoft lo soporta?”. También es: ¿mi sistema, mis bibliotecas, mi pipeline y mi operación están preparados para seguir una versión preliminar soportada?
| Escenario | RC1 puede tener sentido | Mejor esperar |
|---|---|---|
| Aplicación nueva o servicio aislado | Cuando hay pruebas sólidas, rollback sencillo y un beneficio concreto de .NET 11. | Cuando no existe una necesidad técnica de adelantar la migración. |
| Sistema crítico | Solo con homologación representativa, observabilidad y un camino corto de actualización. | Cuando los cambios de runtime exigen certificación, ventanas largas o un rollback costoso. |
| Dependencias de terceros | Cuando paquetes, agentes, APM, drivers y bibliotecas se probaron con el RC. | Cuando el proveedor todavía no declara compatibilidad o hay componentes cerrados difíciles de validar. |
| Entorno con cambios congelados | Rara vez; un RC exige disciplina para seguir nuevas builds. | Cuando la organización no puede actualizar rápidamente después de RC2 o GA. |
Checklist antes de llevar RC1 a producción
1. Fija exactamente el SDK y el runtime que usarás
El SDK de .NET se instala en paralelo, de modo que las versiones anteriores pueden permanecer mientras se evalúa RC1. En repositorios y CI, usa global.json para controlar qué SDK se selecciona y evitar que una máquina con varias versiones elija silenciosamente otra build. Para versiones preliminares, comprueba también la configuración que permite seleccionar prereleases.
Microsoft documenta el uso de global.json para seleccionar el SDK. La versión oficial RC1 incluye el SDK 11.0.100-rc.1.26425.128 con el runtime 11.0.0-rc.1.26425.128.
2. Ejecuta restore y build limpios con los warnings visibles
No te limites a que “la solución compile”. Ejecuta restore en un entorno limpio, recompila todo e investiga warnings nuevos del compilador, SDK, analizadores, source generators, MSBuild y NuGet. Los proyectos con tareas de build personalizadas o herramientas que inspeccionan internals del SDK merecen atención adicional.
3. Revisa los breaking changes antes de atribuir todo a “un bug del RC”
.NET 11 incluye cambios que pueden ser incompatibles a nivel binario, de código fuente o de comportamiento. Un binario existente puede comportarse de otra forma, un proyecto puede requerir cambios para recompilar o una API puede seguir compilando pero cambiar su comportamiento en runtime. Usa la lista oficial de breaking changes de .NET 11 como guía, recordando que Microsoft marca la página como trabajo en curso.
4. Valida bibliotecas, workloads y herramientas externas al runtime
El soporte go-live de .NET no garantiza automáticamente la compatibilidad de cada paquete de terceros, extensión, agente de observabilidad, driver, ORM adicional, workload móvil o herramienta de build. Confirma versiones soportadas, ejecuta pruebas de integración y revisa si alguna dependencia todavía bloquea net11.0 o SDKs prerelease.
En Windows, el anuncio de RC1 recomienda Visual Studio 2026 Insiders; otra opción indicada es Visual Studio Code con C# Dev Kit. El objetivo es mantener el entorno de desarrollo alineado con una toolchain que realmente entienda RC1.
5. Prueba el comportamiento, no solo la compilación
Prioriza flujos de negocio, serialización, autenticación, criptografía, red, acceso a datos, colas, jobs, interoperabilidad nativa y cualquier ruta sensible al runtime o al JIT. Después, compara latencia, throughput, asignación de memoria, uso de CPU, tiempo de arranque y comportamiento del GC con la versión que hoy está en producción. Una pequeña regresión en un benchmark sintético puede ser irrelevante; una regresión en una ruta crítica puede impedir la adopción.
6. Reproduce el deployment real
Prueba el mismo modelo que publicarás: framework-dependent, self-contained, container, IIS, servicio Linux u otro formato. Esto importa porque cambia la responsabilidad de actualización. Las aplicaciones framework-dependent pueden beneficiarse del servicing del runtime instalado en el host. Los deployments self-contained llevan su propio runtime, por lo que el equipo debe reconstruir y volver a publicar para incorporar una versión nueva.
En containers, no trates una etiqueta mutable como prueba de reproducibilidad. Registra la imagen realmente promovida a producción y establece un proceso claro de rebuild cuando llegue RC2, una corrección de seguridad o GA.
7. Ten rollback y observabilidad listos antes del primer tráfico
Un deployment anticipado solo es razonable si las regresiones pueden detectarse y revertirse rápidamente. Define métricas, logs, traces, alertas y criterios de interrupción. Si el despliegue cambia esquemas de base de datos, protocolos, colas o formatos persistidos, confirma que el rollback de la aplicación siga siendo posible después de la migración.
8. Ensaya ahora la siguiente actualización
RC1 no debe tratarse como un destino de largo plazo. Como el soporte de esta build termina el 13 de octubre de 2026, ensaya la siguiente actualización en staging antes de llevar RC1 a producción: cambia el SDK, recompila, prueba y despliega. Así reduces el riesgo de descubrir tarde que la organización puede adoptar RC1, pero no puede salir de él con rapidez.
Qué cambios de RC1 merecen atención en las pruebas
El anuncio de RC1 reúne cambios en bibliotecas, runtime, SDK, MSBuild, NuGet, C# 15, F#, ASP.NET Core, .NET MAUI y Windows Forms. Entre los destacados hay mejoras en dotnet test, publicación de containers más reproducible, cambios de autenticación en SignalR, funciones de C# 15 estabilizadas y ajustes de runtime. Eso no significa que cada proyecto deba probar todas las áreas: céntrate en los componentes que realmente forman parte de tu stack.
Las release notes completas de .NET 11 RC1 son la mejor referencia para construir una matriz de pruebas por componente.
RC1 ahora o la versión final: una regla sencilla de decisión
Adoptar RC1 es más defendible cuando existe un beneficio concreto, cobertura de pruebas fiable, dependencias verificadas, deployment reproducible y capacidad de actualizar en pocas semanas. Es menos defendible cuando la única motivación es “estar en la versión más nueva”, especialmente en organizaciones con procesos de cambio lentos o proveedores que todavía no soportan la nueva línea.
El ciclo de vida también importa: .NET 11 es una versión STS, no LTS. Los equipos que prefieren ciclos de soporte más largos y menos upgrades de versión principal deben incluir este factor en su estrategia incluso después de GA.
Qué registrar antes de aprobar la adopción
- versión exacta del SDK, runtime e imágenes de container usadas;
- resultados de restore, build, pruebas unitarias, de integración y end-to-end;
- breaking changes revisados e impacto documentado;
- estado de compatibilidad de paquetes y herramientas críticas;
- comparación de rendimiento y uso de recursos;
- plan de rollback probado;
- responsable y plazo para migrar de RC1 a la siguiente build soportada;
- fecha de reevaluación antes de que termine el soporte de RC1.
En resumen, el go-live de .NET 11 RC1 abre la puerta a producción con soporte oficial; no elimina la necesidad de gestionar el riesgo de ingeniería. Si tu equipo puede demostrar compatibilidad y mantener una cadencia rápida de actualización, RC1 puede ser una etapa útil de adopción anticipada. Si no puede, esperar a GA es una decisión técnica perfectamente coherente.
