The Code Migrator’s Guide to .NET 11

What Preview 1 Means for Legacy Modernization Teams

Microsoft shipped .NET 11 Preview 1 on February 10, 2026, kicking off the development cycle for what will be a Standard Term Support (STS) release in November 2026. For teams in the middle of modernizing legacy applications—whether migrating from VB6, PowerBuilder, WebForms, WinForms, or older .NET Framework versions—every new .NET release reshapes the target you’re aiming at.

This post breaks down the Preview 1 features that matter most to code migration teams, identifies the breaking changes you should know about now, and frames the strategic context around .NET version support timelines that could affect your modernization roadmap.

The Headline: Runtime Async Changes Everything Under the Hood

The biggest technical story in .NET 11 Preview 1 is Runtime Async—a fundamental rearchitecture of how .NET handles asynchronous methods. Since C# 5 introduced async/await over a decade ago, the C# compiler has been solely responsible for rewriting every async method into a state machine struct. That compiler-generated state machine tracks progress across suspension points, hoists local variables to heap-allocated fields, and produces IL that the runtime executes without any understanding of its async semantics.

With Runtime Async, the .NET runtime itself now understands async methods as a first-class concept. The compiler emits simpler IL annotated with [MethodImpl(MethodImplOptions.Async)], and the runtime takes over responsibility for suspending, resuming, and optimizing async execution.

Why This Matters for Migrators

If you’re migrating legacy synchronous codebases to modern .NET, a major part of the transformation involves introducing async patterns—especially for database access, API calls, and I/O-heavy workflows. Runtime Async delivers three practical benefits that lower the cost of getting async right:

• Reduced memory allocations. The runtime can keep local variables on the stack and only spill them to the heap when they actually live across an await boundary. Early benchmarks suggest approximately 50% less memory allocation in common async patterns. For migration projects converting thousands of synchronous methods, this means the performance overhead of introducing async drops significantly.
• Dramatically better debugging. Today, stepping through async code shows synthetic MoveNext methods and mangled stack traces. Runtime Async produces cleaner call stacks that show your original method names. When you’re validating that a migrated PowerBuilder event handler or VB6 subroutine has been correctly converted to async C#, readable stack traces are a productivity multiplier.
• The gap between “optimized” and “just works” shrinks. Previously, squeezing maximum async performance meant carefully applying ValueTask<T>, ConfigureAwait(false), and caching common Task results. Runtime Async narrows this gap by letting the runtime optimize async call chains automatically. Migrated code can follow straightforward async/await patterns without requiring deep performance tuning.

Current Status

CoreCLR support for Runtime Async is enabled by default in Preview 1—no environment variables needed. Native AOT support has also been added. However, none of the core runtime libraries are compiled with runtime-async support yet, which means the full performance benefits won’t materialize until upcoming previews. To experiment with runtime-async compilation today, you need to enable preview features and set a compiler flag in your project file:

CoreCLR Comes to WebAssembly: The Beginning of the End for Mono

.NET applications compiled to WebAssembly have historically relied on the Mono runtime. While Mono served this role, it comes with well-documented performance limitations and doesn’t benefit from the same optimization investment as CoreCLR.

.NET 11 Preview 1 begins foundational work to bring CoreCLR to WebAssembly, including a WASM-targeting RyuJIT for AOT compilation. This is explicitly marked as not ready for general use yet—full support is targeted for .NET 12—but the direction is clear.

Migration Implication

If your modernization target includes Blazor WebAssembly (increasingly common for teams moving desktop-bound applications to the browser), CoreCLR on WASM means better runtime execution speed, JIT capabilities, and consistent behavior across all .NET hosting models. The same code running on your server, your desktop, and your browser will eventually share a single runtime. For now, treat this as a signal that Blazor WASM is getting serious investment, and factor that into your target architecture decisions.

New Library Features Worth Knowing

Preview 1 introduces several library additions. Here are the ones with the most direct relevance to modernization projects:

• Zstandard Compression (ZstandardStream). Native support for Zstd compression eliminates third-party dependencies for teams building modern APIs or data pipelines. If you’re migrating legacy systems that rely on custom compression utilities, this is one less external dependency to manage.
• BFloat16 Floating-Point Type. A new type optimized for AI and machine learning workloads. If your modernization includes adding AI capabilities to legacy applications (as we’re seeing more frequently), this gives you first-class hardware-friendly floating-point support.
• Happy Eyeballs in Socket.ConnectAsync. This implements RFC 6555 for dual-stack IPv4/IPv6 connection racing. Legacy applications often have hardcoded networking assumptions that break in modern cloud-native environments. This kind of built-in network resilience simplifies the migration path.
• HMAC and KMAC Verification APIs. Enhanced cryptographic APIs for security-sensitive migration scenarios, particularly relevant for healthcare, financial services, and government applications moving off legacy platforms.
• FrozenDictionary Collection Expression Support. Performance-optimized immutable dictionaries now work with collection expressions, making it cleaner to represent the kind of static lookup tables that are common in migrated business logic.

C# 15: Collection Expression Arguments

.NET 11 ships with C# 15, though Preview 1 includes only one new language feature: Collection Expression Arguments. This extends the collection expression syntax introduced in C# 12 to allow constructor parameters like capacity during initialization.

Community reaction has been mixed—some developers feel this adds complexity without proportional value. From a migration perspective, this is low-impact: it’s a convenience feature that won’t affect your transformation rules. More C# 15 features are expected in later previews.

Blazor and ASP.NET Core Improvements

For teams targeting Blazor as their modern UI framework (a common choice when migrating WinForms, WebForms, or PowerBuilder applications), Preview 1 delivers several quality-of-life improvements:

• EnvironmentBoundary component enables conditional rendering based on hosting environment (Development, Staging, Production), bringing parity with MVC’s environment tag helper.
• IHostedService support in Blazor WebAssembly enables background services in the browser—useful for migrating applications that relied on background processing in desktop environments.
• QuickGrid OnRowClick event adds row-level interaction to the built-in grid control, which directly maps to the grid-based UIs common in legacy desktop applications.
• Relative navigation with RelativeToCurrentUri in both NavLink and NavigationManager simplifies URL management for applications with deep navigation hierarchies.
• IOutputCachePolicyProvider allows dynamic output cache policy resolution at runtime from databases, feature flags, or per-tenant configuration—a pattern frequently needed in modernized multi-tenant applications.

Breaking Changes: Hardware Requirements Get Stricter

This is the section migrators need to flag for their infrastructure teams. .NET 11 updates the minimum hardware requirements for both x86/x64 and Arm64 architectures:

• x86/x64: The baseline moves from x86-64-v1 to x86-64-v2, requiring CX16, POPCNT, SSE3, SSSE3, SSE4.1, and SSE4.2. The ReadyToRun compilation target moves to x86-64-v3 on Windows and Linux, which includes AVX, AVX2, BMI1, BMI2, FMA, and more.
• Arm64 on Windows: Now requires the LSE (Large System Extensions) instruction set.
• Impact: Applications running on .NET 11 will fail to launch on hardware that doesn’t meet these requirements. The last CPUs lacking x86-64-v2 support went out of vendor support around 2013, so this shouldn’t affect modern servers. But if your legacy modernization project runs on older on-premises hardware, verify compatibility before planning your target framework upgrade.

The Elephant in the Room: .NET 8 and .NET 9 Both Hit EOL in November 2026

Here’s the strategic context that makes .NET 11 particularly relevant for migration planning. Due to Microsoft’s 2025 decision to extend STS support from 18 to 24 months, both .NET 8 (LTS) and .NET 9 (STS) reach end of support on the same date: November 10, 2026.

This is unusual. Typically, teams on an LTS release have a comfortable runway while the next version matures. This time, the safety net disappears for both versions simultaneously. After that date, neither .NET 8 nor .NET 9 will receive security patches, bug fixes, or compliance updates from Microsoft.

What This Means for Your Migration Target

If you’re currently planning or executing a legacy modernization project, your target framework decision just got more consequential:

1. .NET 10 (LTS) is the safe, long-term target. It will receive three years of support through 2028. If your migration is in flight, .NET 10 remains the recommended production target.
2. .NET 11 (STS) will offer cutting-edge features like full Runtime Async, but as an STS release it will only be supported for two years. It makes sense as a target for teams comfortable with annual upgrades or those who need the specific capabilities it introduces.
3. If you’re still on .NET 8 or .NET 9, the clock is ticking. You have roughly eight months before those versions go unsupported. Begin planning your upgrade path now—whether that means moving to .NET 10 or leapfrogging to .NET 11 when it GA’s.

.NET MAUI: CoreCLR Default on Android

For teams modernizing legacy desktop applications toward cross-platform mobile/desktop targets, .NET MAUI in Preview 1 defaults to XAML source generation for improved build and runtime performance. More notably, CoreCLR is now the default runtime for Android release builds, replacing Mono. This brings performance improvements, particularly in startup time, and ensures consistent runtime behavior across platforms.

Entity Framework Core: Better Inheritance Support

EF Core 11 adds support for complex types and JSON columns on entity types with TPT (Table Per Type) and TPC (Table Per Concrete Type) inheritance. If your legacy database uses complex inheritance hierarchies—common in enterprise systems built on stored procedures and normalized schemas—this gives EF Core more flexibility to map those structures without workarounds. EF Core 11 also introduces one-step migration creation and application, streamlining the database schema management workflow.

Our Take: Plan for .NET 10, Watch .NET 11 Closely

At GAPVelocity AI, we’re tracking .NET 11 closely because the features landing in this release directly affect how we build and optimize our VELO modernization platform. Runtime Async, in particular, has the potential to improve the performance characteristics of the async code our platform generates during migration.

For our clients and the broader modernization community, here’s our practical guidance:

• Target .NET 10 for production migrations today. It’s LTS, it’s stable, and it gives you the longest support runway.
• Audit your hardware if you plan to adopt .NET 11. The new minimum CPU requirements will catch some teams off guard, especially those running on older on-premises infrastructure.
• If you’re still on .NET 8 or 9, start moving. November 2026 is closer than it feels, and both versions lose support on the same day.
• Keep Blazor in your modernization toolkit. Between the Blazor improvements in this preview and the coming CoreCLR WebAssembly support, “all roads lead to Blazor” continues to hold as a frontend migration strategy.

We’ll continue covering each .NET 11 preview as new features land. If your team is planning a modernization and wants to understand how these platform changes affect your timeline, architecture, or costs—let’s talk.

Ready to modernize? GAPVelocity AI’s VELO platform delivers 85–95% automated code coverage for legacy-to-modern .NET migrations. Visit gapvelocity.ai to learn more.