“.NET is stable, let’s build features” works until a security fix, partner SDK, or framework bump needs a newer runtime. This guide shows when to move, how to keep risk low, and what good looks like in late 2025.

Why this matters now

Modern .NET runs on two tracks. LTS is the long baseline most services should use. STS moves faster for teams that can adopt changes quickly. Falling far behind increases security and integration risk and makes hiring harder. And, also blocks or complicates AI adoption as cloud AI SDKs align to current .NET lines. The solution is a repeatable cadence that keeps you near supported lines.

The leadership checklist before any upgrade

• Support window: Which .NET line are we on and when does it end
• Platform fit: Do our key frameworks and cloud SDKs support the target
• Safety nets: Do business-level tests pass in a staging environment we trust
• Dependencies: Are container and OS base images, CI runners, and scanners aligned
• Rollout plan: Can we release in stages and measure health before full rollout

This turns upgrades into controlled work rather than a gamble.

Plan and ship without drama

Confirm the target line and prove the order of changes with a short exercise. Release in stages. Watch service health and promote only if the numbers hold. For data changes, use a plan that allows old and new code to run side by side while data is moved. Be honest about rollback. When data changed, rolling forward to a safe patch is the realistic option.

.NET today: where you stand by version

We focus on supported lines. After end of support there are no Microsoft security patches and ecosystem friction grows.

.NET 10 (LTS) — launches November 2025
Next long-term baseline. New services starting late 2025 should target 10 once GA lands. Expect rapid ecosystem uptake, performance gains, and new platform features to land here first.
Why it matters: longest runway for security fixes and the best alignment with future ASP.NET Core, EF Core, and cloud SDK updates.

.NET 9 (STS)
Current standard-term release. Good for teams that move fast, but several vendors already align roadmaps to “9 now, 10 LTS next.”
Risk if you linger: shrinking overlap with partner SDKs as they deprecate older target frameworks, creating a narrow window to move without double work.

.NET 8 (LTS)
Today’s LTS and a solid baseline. Most Azure SDKs, EF Core 8, and ASP.NET Core 8 features land here. You benefit from Native AOT improvements and runtime perf work that are not available on 6.
Why it matters: staying on 8 keeps you eligible for current security, performance, and SDK updates while you prepare for 10.

.NET 6 (LTS) — end of support passed
EoS was November 2024. You’ll hit more “net8.0 required” notes in EF Core, ASP.NET Core, analyzers, and cloud SDKs. Container base images for 6 are frozen, which pushes security risk to your OS layer.
Why it matters: rising compliance exposure and mounting engineering time spent on pinning and exceptions instead of product work.

.NET Framework 4.x
Still supported, tied to Windows lifecycle, but new innovation ships on modern .NET. Many newer Azure and third-party SDKs assume .NET 6/8+ targets, so 4.x apps need shims or older clients.
Why it matters: integrations get harder, and hiring gets tougher as engineers prefer modern .NET.

.NET Framework 3.5 SP1
Supported mainly for running legacy apps, not for new development. Tooling, security baselines, and partner SDKs are thin.
Why it matters: higher risk and limited ecosystem choices; migrations require time for dependency and configuration changes.

.NET Framework 3.0 SP2
Out of support since 2011. Any reliance here usually signals deeper platform and dependency freezes.
Why it matters: significant security and operability risk; you’ll need at least a two-step rise before you can adopt modern SDKs.

Can my .NET version use modern AI services?

When teams say “we can’t plug AI in,” it’s usually a runtime/SDK mismatch. Here’s a practical, version-by-version view for Azure OpenAI / OpenAI, AWS Bedrock & SageMaker, and Google Vertex AI.

What the SDKs target (in plain terms)

• Azure OpenAI (.NET) – Azure.AI.OpenAI targets .NET Standard 2.0, so it works on modern .NET (6/8/9/10) and on .NET Framework ≥ 4.6.1/4.6.2 with caveats. nuget.org
• OpenAI official .NET library – compatible with .NET Standard 2.0 apps (examples use .NET 8, but the library supports netstandard2.0). GitHub
• AWS SDK for .NET (Bedrock/SageMaker) – current v4 removes .NET Framework 3.5; it’s compiled against .NET Framework 4.7.2 (and supports modern .NET). Bedrock has official .NET examples via the AWS SDK. AWS Documentation+1
• Google Cloud / Vertex AI (.NET) – client libraries (e.g., Google.Cloud.AIPlatform.V1) target .NET Standard 2.0 and .NET Framework 4.6.2+. nuget.org
• Azure SDK (general) – designed for .NET Standard 2.0; modern releases track current .NET lines closely. Microsoft Learn+2Microsoft for Developers+2

What this means by your runtime:

• .NET 10 (LTS) & .NET 9 (STS)
  Fully compatible with all major AI SDKs above. If you’re starting a new service late 2025, targeting .NET 10maximizes runway and AI SDK feature alignment.
  NET Upgrade Guide_ A Calm Path …
• .NET 8 (LTS)
  Good baseline for AI work. Azure/OpenAI, AWS Bedrock/SageMaker, and Vertex AI SDKs are all supported. You also benefit from modern gRPC/HTTP handlers that many AI SDKs assume. This is the safest “ship now” target while preparing for .NET 10. nuget.org+3nuget.org+3GitHub+3
• .NET 6 (LTS, now past EoS)
  The AI SDKs still work (they’re netstandard2.0-friendly), but you’re on an unsupported runtime which increases security/compliance risk and narrows future SDK options. Prioritize moving to 8 or 10 to avoid getting pinned by next-wave SDK updates that may require net6+/net8+.
  NET Upgrade Guide_ A Calm Path …
• .NET Framework 4.7.2–4.8
  Works, with caveats.
  
  • Azure/OpenAI: OK via netstandard2.0. nuget.org+1
  • Google Vertex AI: OK (packages support .NET Framework 4.6.2+). nuget.org
  • AWS: Use AWS SDK v4 (compiled against 4.7.2). Older frameworks (e.g., 3.5) are no longer supported. AWS Documentation
    Expect more friction with modern gRPC/HTTP2 and TLS defaults than on .NET 8/10. If you stay here, budget extra time for dependency and platform quirks.
• .NET Framework 4.6.1–4.6.2
  Some AI libraries still load (netstandard2.0), but several cloud SDKs now require 4.6.2+ or 4.7.2+ and newer TLS/HTTP stacks. Treat this as transitional at best; moving to modern .NET will cut integration risk. GitHub+1
• .NET Framework 3.5 / 3.0
  Not viable for modern AI integrations. AWS SDK v4 dropped .NET 3.5, and current AI SDKs assume netstandard2.0 or newer frameworks. Plan a two-step upgrade (Framework → modern .NET) before adding AI. AWS Documentation

Rule of thumb for leaders
If you’re on .NET 8+, you’re in the “green” for Azure/OpenAI, AWS Bedrock/SageMaker, and Vertex AI. On .NET Framework, it’s often technically possible but operationally fragile; the real cost is time lost on workarounds versus building features. Aligning to .NET 8 now (and .NET 10 next) keeps you inside the primary support path that these AI SDKs track. 

NET Upgrade Guide_ A Calm Path …

.NET-specific guidance leaders should ask for

• Framework alignment: Are ASP.NET Core and Entity Framework versions healthy on the target line
• Cloud SDKs: Do our Azure or other cloud SDKs support the target and are we pinned to safe versions
• Platform hygiene: Are container images and Windows or Linux base images within support dates
• Supply chain: Do we produce a software bill of materials and scan dependencies on each build
• People and access: Do we have continuity if a key engineer leaves

These questions surface hidden risks early and cut upgrade costs.

What leaders should expect in outcomes

• Lower risk: supported security posture and fewer overnight incidents.
• Faster releases: less friction in CI/CD and partner integrations.
• Better hiring story: modern .NET attracts stronger candidates.
• Predictable spend: quarterly hygiene instead of emergency projects.

FAQ for decision makers

Can we jump from .NET 6 to 10 directly

Often yes, if your frameworks and SDKs support it. Ask for a short compatibility check and a pilot rollout plan.

What about .NET Framework apps

Keep them isolated. Migrate where the business value is clear. Not every app needs a rewrite, but every app needs a plan.

How do we avoid downtime?

Stage the release, measure health in production with a small slice of traffic, and only promote when results are good.

What to do next

Ask for a one-page inventory listing your .NET line, major frameworks, cloud SDKs, base images, and support dates. Approve a short exercise to prove the upgrade order, then schedule a staged rollout. Repeat quarterly so upgrades never become a crisis.

Talk to us

We plan and execute .NET upgrades with calm, measurable steps. If you want an outside view or delivery support, start a conversation.