.NET 6 (LTS) EOL Nov 12, 2024 – Budget Essentials

The Date on the Calendar

Microsoft .NET 6 (LTS) reaches its end of life on November 12, 2024 — roughly 13 months from today. This is not an end of active support; it's the final curtain for all support, including security patches and bug fixes. The latest version in the .NET 6 line is 6.0.36, and no further updates are planned.

If your fiscal year starts in January, the EOL lands in your Q4. If your fiscal year aligns with the calendar, it lands in mid-November. Either way, this is the budget cycle where the line item must be addressed.

What the EOL Actually Means

After November 12, 2024:

• No more security patches: CVEs found in .NET 6 after that date will remain unpatched.
• No more bug fixes: Any functional issues or regressions will not be addressed by Microsoft.
• No more support tickets: Microsoft support will direct you to upgrade or purchase extended support (if available).

The risk is not hypothetical. Unpatched runtimes are a known vector for exploitation. For enterprises handling sensitive data or operating under compliance frameworks (PCI-DSS, SOC2, HIPAA), running an EOL runtime creates audit findings and potential liability.

What a Typical Migration Involves (and Why It Often Slips)

Upgrading from .NET 6 to a supported LTS release (like .NET 8, which is supported until November 2026) is not a simple "update click." At enterprise scale, the process usually includes:

• Code compatibility testing: .NET upgrades can introduce breaking changes in APIs, libraries, or runtime behavior.
• Third-party library verification: NuGet packages and internal dependencies must also be compatible.
• Regression testing for every application: A single application might have dozens or hundreds of microservices, each requiring revalidation.
• Deployment pipeline updates: CI/CD scripts, container base images, and monitoring tools need updated targets.
• Cross-team coordination: If your organization uses .NET across multiple business units, the upgrade must be staggered without breaking inter-service communication.

A migration of this scale often takes 12–18 months from start to finish — especially if you have a large portfolio of legacy applications, limited development capacity, or concurrent projects (like cloud migrations or security upgrades). That puts the finishing line past the EOL date for many teams.

Comparing Costs: Migration vs. Vendor Extended Support vs. Third-Party Support

When you sit down with next year's budget spreadsheet, you have three pathways to compare:

1. Migration

Direct cost: Developer hours, testing infrastructure, potential downtime during cutover, and training if the team is unfamiliar with the new version.

Indirect cost: Opportunity cost — every hour spent on a .NET upgrade is an hour not spent on revenue-generating features or other strategic initiatives.

2. Microsoft Extended Support (if available)

Microsoft occasionally offers paid extended support for a limited period after EOL. Typically:

• Per-core or per-machine licensing can be expensive, especially at scale.
• No new features or bug fixes — only critical security patches.
• Renewal risk: Extended support offers can be withdrawn, and pricing can increase year-over-year.
• Compliance implications: Some auditors still flag extended support as a "risk acceptance" since it's not the vendor's primary development cadence.

3. Third-Party Support (e.g., 3rd Party Support)

A third-party maintenance provider can continue delivering security patches and bug fixes for .NET 6 well past November 2024.

• Fixed-price model: Usually a percentage of your current support spend, with no surprise escalations.
• Extended runway: You maintain your current runtime while you take a more measured (and less rushed) approach to migration.
• No forced version upgrade: You choose when to move, not the vendor.
• Compatibility: Third-party patches are tested against your specific deployment environment, reducing regression risk.

A typical comparison might look like this in a budget memo:

Option	Upfront Cost	Annual Cost	Timeline Risk
Full migration to .NET 8	High (dev hours + testing)	Low (after migration)	High — may not finish by Nov 2024
Microsoft Extended Support	Medium (per-core licensing)	Medium-High (escalating)	Low (but limited duration)
Third-party support (e.g., 3rd Party Support)	Low (fixed % of current support)	Fixed	Low (no pressure to rush)

What to Put in the Budget Request Now

Don't wait until Q3 2024 to start this conversation. Here's a recommended budget request structure:

1. Line item 1: Migration project budget (if you proceed). Estimate with a buffer of 25% for unforeseen compatibility issues.
2. Line item 2: A contingency for either Microsoft extended support or third-party support — whichever you choose — to cover the gap between November 2024 and the actual completion of migration.
3. Line item 3: A placeholder for testing and rollback scenarios. You may need to run an EOL version in a controlled environment while testing the new one.

If your leadership is skeptical, present the numbers: the cost of a rushed migration (more defects, outages, rework) is almost always higher than the cost of buying yourself an extra 12–18 months with third-party support.

Benchmark Before You Renew

If you're currently paying Microsoft for support or have an active enterprise agreement, get a third-party support quote now — before you enter renewal or extended support discussions. It gives you a baseline to compare pricing and contract flexibility.

Third-party support can keep your .NET 6 applications running safely, with patching and break-fix support, while you plan a migration that fits your actual timeline — not someone else's.

Get a third-party support quote today to include in your budget request as a concrete benchmark.