.NET 11 RC1 can be used in production with Microsoft support, but that does not turn the release candidate into a final release or make the upgrade appropriate for every system. The practical difference of the go-live designation is that RC1 has moved beyond the unsupported preview category: Microsoft treats it as a prerelease that is supported in production. Whether to adopt it now still depends on compatibility, dependencies, the ability to update quickly, and tolerance for changes before GA.
What “go-live” means for .NET 11 RC1
.NET 11 RC1 was published on September 8, 2026. In the official announcement, the .NET team describes RC1 as the first of two release candidates and says it comes with a go-live support license for production applications. Microsoft’s support policy defines go-live as a prerelease, typically an RC, that is supported by Microsoft in production.
There is, however, a specific support window: Microsoft’s official table lists .NET 11 RC1 as supported from September 8 through October 13, 2026. The final .NET 11 release is planned for November 10, 2026. Teams that put RC1 in production should therefore plan from day one to move to the next supported build and then to GA.
Official sources: .NET 11 RC1 announcement, .NET support policy, and the .NET release schedule.
Go-live does not mean “ready for every production system”
The designation answers a product-support question, not your application’s risk assessment. An RC can be mature enough for real workloads and still change before the final release. The .NET 11 breaking changes documentation itself warns that the list is still a work in progress and may not be complete.
So the right question is not only “does Microsoft support it?” It is also: are my system, libraries, pipeline, and operations ready to follow a supported prerelease?
| Scenario | RC1 may make sense | Better to wait |
|---|---|---|
| New application or isolated service | When test coverage is strong, rollback is simple, and .NET 11 provides a concrete benefit. | When there is no technical need to bring the migration forward. |
| Critical system | Only with representative staging, observability, and a short update path. | When runtime changes require certification, long change windows, or costly rollback. |
| Third-party dependencies | When packages, agents, APM, drivers, and libraries have been tested with the RC. | When vendors have not stated compatibility or closed components are hard to validate. |
| Change-frozen environment | Rarely; an RC requires discipline to track new builds. | When the organization cannot update quickly after RC2 or GA. |
Checklist before putting RC1 into production
1. Pin the exact SDK and runtime you intend to use
The .NET SDK installs side by side, so earlier versions can remain installed while RC1 is evaluated. In repositories and CI, use global.json to control which SDK is selected and avoid a machine with multiple versions silently picking a different build. For prerelease versions, also verify the setting that allows prerelease SDK selection.
Microsoft documents global.json for SDK selection. The official RC1 release includes SDK 11.0.100-rc.1.26425.128 with runtime 11.0.0-rc.1.26425.128.
2. Run clean restore and build jobs with warnings visible
Do not stop at “the solution compiles.” Run restore in a clean environment, rebuild everything, and investigate new compiler, SDK, analyzer, source generator, MSBuild, and NuGet warnings. Projects that use custom build tasks or tools that inspect SDK internals deserve extra attention.
3. Review breaking changes before blaming “an RC bug”
.NET 11 includes changes that can be binary incompatible, source incompatible, or behavioral. An existing binary may behave differently, a project may require source changes to recompile, or an API may still compile while behaving differently at runtime. Use the official .NET 11 breaking changes list as a checklist, while remembering that Microsoft marks the page as a work in progress.
4. Validate libraries, workloads, and tools outside the runtime
.NET go-live support is not an automatic compatibility guarantee for every third-party package, extension, observability agent, driver, additional ORM, mobile workload, or build tool. Confirm supported versions, run integration tests, and check for dependencies that still block net11.0 or prerelease SDKs.
On Windows, the RC1 announcement recommends Visual Studio 2026 Insiders; another listed option is Visual Studio Code with C# Dev Kit. The goal is to keep the development environment aligned with tooling that actually understands RC1.
5. Test behavior, not only compilation
Prioritize business flows, serialization, authentication, cryptography, networking, data access, queues, jobs, native interop, and any path sensitive to the runtime or JIT. Then compare latency, throughput, memory allocation, CPU usage, startup time, and GC behavior with the version currently used in production. A small regression in a synthetic benchmark may not matter; a regression on a critical route may block adoption.
6. Reproduce the real deployment model
Test the same model you will ship: framework-dependent, self-contained, container, IIS, Linux service, or another format. This matters because update responsibility differs. Framework-dependent applications can benefit from servicing of the runtime installed on the host. Self-contained deployments carry their own runtime, so the team must rebuild and republish to incorporate a newer runtime.
For containers, do not treat a mutable tag as proof of reproducibility. Record the actual image promoted to production and have a clear rebuild process for RC2, a security fix, or GA.
7. Have rollback and observability ready before the first production traffic
An early deployment is only rational if regressions can be detected and reversed quickly. Define metrics, logs, traces, alerts, and stop criteria. If a deployment changes database schemas, protocols, queues, or persisted formats, verify that application rollback is still possible after the migration.
8. Rehearse the next upgrade now
RC1 should not be treated as a long-term destination. Because support for this build ends on October 13, 2026, rehearse the next upgrade in staging before RC1 reaches production: swap the SDK, rebuild, test, and roll out. This reduces the risk of discovering that the organization can adopt RC1 but cannot leave it quickly.
Which RC1 changes deserve attention in testing
The RC1 announcement covers updates across libraries, runtime, SDK, MSBuild, NuGet, C# 15, F#, ASP.NET Core, .NET MAUI, and Windows Forms. Highlights include improvements to dotnet test, more reproducible container publishing, SignalR authentication changes, stabilized C# 15 features, and runtime work. That does not mean every project needs to test every area: focus on components that are actually part of your stack.
The complete .NET 11 RC1 release notes are the best reference for building a component-by-component test matrix.
RC1 now or the final release: a simple decision rule
Adopting RC1 is easier to justify when there is a concrete benefit, reliable test coverage, verified dependencies, reproducible deployment, and the ability to update within weeks. It is harder to justify when the only motivation is “being on the newest version,” especially in organizations with slow change processes or vendors that do not yet support the new line.
The lifecycle also matters: .NET 11 is an STS release, not LTS. Teams that prefer longer support cycles and fewer major-version upgrades should factor that into the strategy even after GA.
What to record before approving adoption
- the exact SDK, runtime, and container image versions used;
- restore, build, unit, integration, and end-to-end test results;
- reviewed breaking changes and documented impact;
- compatibility status of critical packages and tools;
- performance and resource-use comparison;
- a tested rollback plan;
- an owner and deadline for moving from RC1 to the next supported build;
- a reassessment date before RC1 support ends.
In short, .NET 11 RC1 go-live opens the door to production with official support; it does not remove the need for engineering risk management. If your team can demonstrate compatibility and maintain a fast update cadence, RC1 can be a useful early-adoption step. If it cannot, waiting for GA is a perfectly coherent technical decision.
