What to Test Before Moving a .NET Application to .NET 11 RC1

.NET 11 RC1 was released on September 8, 2026. It is a Go-Live release, so teams can use it in production while preparing for the final .NET 11 release, which is scheduled for November 10, 2026.

That does not mean an existing application can simply change TargetFramework and be considered migrated. The risky part of a .NET upgrade is usually not getting the application to compile. It is finding the places where the new runtime, SDK, libraries, ASP.NET Core behavior, or deployment environment changes how the application behaves.

To migrate to .NET 11 RC1, I would test the application in this order: build compatibility, dependency compatibility, runtime behavior, application-specific workloads, deployment, and production-like performance.

1. Create a Clean Baseline First

Before changing the target framework, record how the application behaves on its current .NET version.

At minimum, capture:

Build and test results
Application startup time
API response times for important endpoints
Memory usage
CPU usage
Database connection behavior
Background job behavior
Logging and telemetry
Container startup behavior, if applicable

This gives you something to compare against after the migration.

Run the existing test suite before changing anything:

dotnet restore

dotnet build --configuration Release

dotnet test --configuration Release

Do not skip this step. If tests are already failing before the migration, you will have a much harder time deciding whether a failure is caused by .NET 11.

2. Test the Application Against .NET 11 RC1

Install the .NET 11 RC1 SDK and change the target framework in the project file.

For an application currently targeting .NET 10:

<PropertyGroup>
    <TargetFramework>net11.0</TargetFramework>
</PropertyGroup>

If the repository uses global.json, check that it is selecting the SDK you intend to test.

For example:

{
  "sdk": {
    "version": "11.0.100-rc.1"
  }
}

Use the actual SDK version installed in your environment rather than copying a version number from an example.

Then verify the SDK:

dotnet --info
dotnet --list-sdks

Build the application again:

dotnet clean

dotnet restore

dotnet build --configuration Release

Treat every new warning as something to investigate. A successful build only proves that the compiler accepted the code. It does not prove that the application will behave the same way at runtime.

3. Check .NET 11 Breaking Changes

This should be one of the first migration checks, not something done after production testing.

Microsoft's .NET 11 compatibility documentation currently lists changes across ASP.NET Core, .NET libraries, cryptography, deployment, networking, JIT, SDK/MSBuild, and other areas. Microsoft also classifies changes as binary incompatible, source incompatible, or behavioral.

Some changes are easy to miss because the application still compiles.

For example, .NET 11 changes the minimum x86/x64 hardware baseline to x86-64-v2. An application running on older hardware can fail to start because the processor does not provide the required instruction sets. ReadyToRun targets have also changed.

If your application runs on older servers, VMs, or unusual infrastructure, verify the CPU capabilities before deployment.

4. Test ASP.NET Core Applications Separately

ASP.NET Core applications need their own compatibility pass.

The ASP.NET Core 11 breaking-change list includes changes to Kestrel, OpenAPI, response compression, Blazor, authentication, middleware, and package dependencies.

For example, Microsoft.OpenApi has moved to version 3.x, which can create source compatibility issues for applications that directly use OpenAPI types. The ConcurrencyLimiter middleware has also been removed.

Check:

Controllers and Minimal APIs
Authentication and authorization
Middleware ordering
Exception handling
OpenAPI/Swagger generation
Response compression
HTTPS and TLS
WebSockets and SignalR
Health checks
Static files
Blazor components, if used

Then exercise real API requests rather than relying only on unit tests.

A simple smoke-test sequence might be:

GET  /health
POST /api/auth/login
GET  /api/products
POST /api/orders
GET  /api/orders/{id}

Test both successful requests and expected failures.

5. Test .NET Library Behavior, Not Just Compilation

Several .NET 11 changes affect runtime behavior.

For example, DateOnly.TryParse and TimeOnly.TryParse can now throw for invalid input. ZIP processing adds CRC32 validation, and ZipArchive.CreateAsync changes how archive entries are loaded. IHost.RunAsync and IHost.StopAsync also have changed behavior when a BackgroundService fails.

These changes matter because existing tests may not cover unusual input or failure paths.

If your application processes dates supplied by users, test invalid values:

var result = DateOnly.TryParse(
    input,
    out var date);

Do not assume that code which behaved a certain way on the previous runtime will behave identically on .NET 11.

The same applies to:

File processing
ZIP/TAR handling
Background services
Networking
Cryptography
Reflection
Serialization
Interop
Globalization

6. Test Background Services and Hosted Applications

Applications using BackgroundService deserve specific testing.

Create a test scenario where a background worker throws an exception and verify what your application does next.

Check:

Does the host remain running?
Is the failure logged?
Is the worker restarted?
Does the application shut down?
Does your monitoring system detect the failure?
Are messages or jobs left in an inconsistent state?

This matters because .NET 11 changes the behavior of IHost.RunAsync and IHost.StopAsync when a BackgroundService fails.

If your application relies heavily on hosted workers, this should be part of the migration test plan.

7. Test Native Dependencies and Deployment Targets

A migration is incomplete until the deployed application has been tested.

Test the actual environments used by your application:

Area	What to verify
Windows	Runtime installation, services, IIS, permissions
Linux	Runtime, system libraries, permissions, startup
Containers	Base image, startup, health checks
ARM64	Native dependencies and application startup
x64	CPU compatibility and ReadyToRun behavior
NativeAOT	Native libraries and generated output
CI/CD	SDK selection and build agents

Do not test only on the developer machine.

The .NET 11 runtime has changed hardware requirements for x86/x64, and its ReadyToRun targets have also changed. This makes infrastructure testing particularly important for applications deployed to older machines or mixed environments.

8. Run Integration and End-to-End Tests

Unit tests catch code-level problems. Integration tests catch problems between components.

For a production application, test at least:

Database reads and writes
External APIs
Authentication providers
Message queues
Caches
File storage
Background processing
Scheduled jobs
Email or notification services
Distributed tracing

If you use EF Core, run migrations and execute representative queries against a test database.

If you use Redis, RabbitMQ, Kafka, Azure services, or other external systems, test the actual integration rather than mocking everything.

9. Compare Performance Before and After

Do not assume that a newer .NET version automatically makes your application faster.

Measure the workloads that matter to your application.

For an API, compare:

Request rate
p50 latency
p95 latency
p99 latency
CPU usage
Memory usage
GC activity
Error rate

Run the same workload against the old and new versions.

For example, if the current application handles 500 requests per second at a p95 latency of 120 ms, use the same workload after migration and compare the result.

The goal is not to manufacture a benchmark. It is to find regressions in your own workload.

10. Validate Logging, Metrics, and Tracing

Observability can break even when application functionality appears fine.

After migration, check:

Application logs
Log levels
Structured logging fields
OpenTelemetry traces
Metrics
Health checks
Exception tracking
Correlation IDs

ASP.NET Core 11 changes some telemetry behavior. For example, hosting now emits OpenTelemetry HTTP semantic-convention tags by default.

If dashboards or alerts depend on particular metric names or tags, verify them before switching production traffic.

11. Test the Rollback Path

A migration plan should include rollback testing.

Before production deployment, answer these questions:

Can the old application version still be deployed?
Can the database schema work with the old version?
Are there irreversible data changes?
Can traffic be moved back safely?
Can containers be rolled back quickly?
Are configuration changes backward compatible?

A technically successful migration can still become a deployment problem if rollback has not been tested.

12. Final .NET 11 RC1 Migration Checklist

Before moving the application, I would use this checklist:

Test	Status
Existing tests pass before migration	☐
Application builds on .NET 11 RC1	☐
NuGet packages support .NET 11	☐
.NET 11 breaking changes reviewed	☐
ASP.NET Core breaking changes reviewed	☐
APIs and authentication tested	☐
Database integration tested	☐
Background services tested	☐
External integrations tested	☐
Production hardware verified	☐
Containers tested	☐
CI/CD pipeline tested	☐
Logs and telemetry verified	☐
Performance compared	☐
Rollback tested	☐

Common Migration Mistakes

The most common mistake is treating a successful dotnet build as proof that the migration worked.

It is not.

Other problems include upgrading every NuGet package at the same time, ignoring new compiler warnings, testing only on a developer workstation, skipping failure scenarios, and changing database schemas without considering rollback.

Keep the migration controlled. Change the target framework first, resolve compatibility issues, run the test suite, then test the deployed application.

Conclusion

.NET 11 RC1 gives teams a practical point to validate applications before the final release. The important test is not whether the project compiles. It is whether the application still behaves correctly across its real workload, infrastructure, integrations, and deployment pipeline.

Start with the .NET 11 and ASP.NET Core breaking-change lists, then test the areas that are specific to your application. Pay particular attention to hardware requirements, hosted services, ASP.NET Core behavior, native dependencies, and production deployment.

That approach gives you a much clearer answer to the question that matters during a migration: can this application run safely on .NET 11, and what still needs to change before production?