.NET 8 End of Life on November 10, 2026: Planning the Upgrade Without Freezing the Roadmap

Last updated: October 8, 2026

By Jennifer Burdick, Recruiting Manager, KORE1

.NET 8 and .NET 9 both lose Microsoft support on November 10, 2026, and the recommended move is .NET 10, an LTS release supported until November 2028. Your apps keep running past .NET 8 end of life. What stops is security patching. The upgrade itself is a retarget and recompile, not a rewrite, which is exactly why so many teams underestimate who has to do it.

Standing up the new target framework is only half the ticket. We broke down turning off the old runtime once the upgrade lands, including the consumer inventory, the retention rules, and who should own the kill date.

Thirty-three days.

That is what is left between today and November 10, counting from the morning I wrote this. I run IT staffing searches for a living, and almost all of my October has gone to .NET. The calls reaching me this month have the same shape every time. Somebody did the math in late September, realized the deadline is real, and now has to figure out who does the work without stopping the thing the team was hired to build.

One of those calls came in on October 2, from a VP of Engineering at a freight brokerage software company outside Chicago. Fourteen services in production. Nine on .NET 8, five on .NET 9, because a squad had jumped to 9 the previous spring for a couple of features they wanted. He had a Q1 commitment to a customer that involved rebuilding how loads get tendered, and he had two senior platform engineers who understood the build system well enough to own a framework retarget.

Those same two people were the ones the Q1 commitment depended on.

He did not need me to explain the deadline. He needed to know whether the upgrade could be handed to someone else, and what that would cost him. Reasonable question. The answer turns on something most of the coverage of this deadline gets wrong.

Two Clocks, One Date, and No Extra Runway for .NET 9

The first thing worth straightening out is that .NET 9 does not buy anyone time. Microsoft’s .NET support policy runs even-numbered releases as Long Term Support for three years and odd-numbered releases as Standard Term Support for two. .NET 8 shipped in November 2023 and gets three years. .NET 9 shipped in November 2024 and gets two. Both land on the same Tuesday.

If you have a mixed estate like the Chicago team did, the practical effect is that your “newer” services are in identical trouble to your older ones. The squad that jumped to 9 for features bought zero additional runway. Nobody told them that at the time, because at the time it did not matter.

Microsoft’s own end of support announcement is blunt about what changes: after November 10 there are no servicing updates, no security fixes, and no technical support for either version. There is a second requirement hiding in the policy page that catches people. To be supported at all right now you have to be current on patches. The latest .NET 8 patch was 8.0.31 as of September 8. A shop sitting on 8.0.14 because nobody owns runtime upgrades is already outside the support boundary, today, deadline or no deadline.

The Upgrade Is a Build Pipeline Job, Not a C# Job

Here is the part that decides your staffing plan, and the part I spend most of the first call on.

Microsoft’s guidance for the move is to change the TargetFramework property to net10.0 and recompile. That is honest. It is also where teams get the wrong idea about who should do it, because “change one line and rebuild” sounds like a task you hand to whoever has the lightest sprint.

Read the actual breaking changes list for .NET 10 and the shape of the work changes. There are roughly 80 entries on that page. Microsoft notes on the page itself that the list is a work in progress and not complete, and it excludes ASP.NET Core and EF Core, which keep separate lists of their own. So 80 is a floor.

Where those 80 sit is the interesting part.

Twenty-seven of roughly eighty, the single largest block, are in the SDK, MSBuild, and NuGet. Not in C#. In the build.

That inverts the staffing assumption. A framework retarget does not mostly consume application developers writing business logic. It mostly consumes the people who understand your CI pipeline, your package feeds, your container base images, and your release process. In most orgs that is a very short list of names, and those names are load bearing for everything else on the roadmap. My colleague Kris Drouet described the architectural version of this in how engineering orgs end up afraid to touch their own code. Here the bottleneck is people rather than architecture, and a deadline does not care which one you have.

The Chicago VP had already worked this out on his own, which is why he called a staffing firm instead of opening a req. His two platform engineers could do the upgrade. They could not do the upgrade and the Q1 tender rebuild. He had to buy one of those two things from outside, and the upgrade is the one with a fixed end date and a published scope, which makes it the far easier thing to hand to a contractor.

Four Changes That Set the Real Timeline

Scope conversations go badly when they stay abstract. These four are the ones that have actually moved estimates on the projects I have staffed, and they are worth reading before you decide how many weeks to budget.

Debian base images are gone. Default .NET container tags now point at Ubuntu 24.04, and Microsoft is not shipping Debian images for .NET 10 at all. If your Dockerfiles install packages, add users, or depend on paths, somebody is editing every one of them and re-testing the result. Teams that pinned a Debian tag specifically, and some regulated shops did exactly that for image provenance reasons, are now choosing between Ubuntu and maintaining their own base images forever.

The runtime stopped catching shutdown signals for you. On Unix, .NET 10 no longer registers a default SIGTERM handler, and on Windows it no longer handles the shutdown and close events. The OS default kills the process immediately, and AppDomain.ProcessExit never fires. Standard ASP.NET apps are fine, because the hosting layer registers its own handlers. Hand-rolled console workers and queue consumers are not fine. If you have a service that flushes a batch or releases a lease on the way out, it will stop doing that, quietly, in a way that looks like an intermittent data problem three weeks later rather than a failed deployment.

NuGet got stricter in ways that break builds rather than apps. A PackageReference with no version is now an error instead of a warning. dotnet restore audits transitive packages, so vulnerabilities two levels down in a dependency you did not choose start showing up in your build output. Audit sources no longer permit insecure HTTP by default, which matters if your internal Artifactory or ProGet feed is still on plain HTTP behind the firewall. None of these are hard to fix. All of them surface at once, on day one, across every repository, and they make the first week look like a disaster if nobody warned the team.

C# 14 resolves some span overloads differently. No compile error. Nothing turns red. Code that ran correctly under .NET 8 can bind to a different overload and quietly do something slightly else, which is why I would spend test time on this one rather than review time. Thin coverage on a service means you will not catch it. Production will.

Read together, those four say something useful about who you are hiring. Two are container and pipeline work. One is distributed systems behavior. One is a testing problem. Only the last is close to ordinary application development.

Why .NET 11 Is the Wrong Escape Hatch

.NET 11 ships on November 10, 2026. Same day the other two die, at the opening of .NET Conf.

Every October I get some version of the question, and this year it arrives as “if 11 lands the same day, why not skip 10 and go straight there.” It sounds efficient. It moves you backwards.

.NET 11 is an odd-numbered release, so it is Standard Term Support. Two years. Two years from November 10, 2026 lands in November 2028, within a few days of where .NET 10’s support already ends. So the trade is real and it is not in your favor: you would run production on a platform that has been generally available for a matter of days instead of eleven months, and buy no additional runway for it.

There is also a sequencing argument that matters more than the dates. .NET 10 has been out since November 2025. Eleven months of other people finding the sharp edges. The breaking changes are documented, the workarounds are on Stack Overflow, and your contractor has probably done the retarget before. On a 33-day clock, boring is the feature you are paying for.

Go to 10. Revisit 11 when your next upgrade cycle comes up on its own schedule, with a planned project and no deadline attached.

What a Time-Boxed Upgrade Squad Actually Looks Like

The reason I keep calling this a contract shape rather than a hiring shape is that the work has a defined end. When the last service is on net10.0 and the pipeline is green, the project is done. There is no steady-state version of this job. Staffing it permanently means you have hired someone whose role evaporates in March, which is a bad outcome for both of you and the fastest way I know to lose a good engineer in their first year.

Three shapes cover almost everything I have seen, and the right one depends on service count and container footprint more than on company size.

On rates, the bands have not moved much since we published our guide to hiring C# and .NET developers in 2026. Mid-level contract .NET runs $100 to $140 an hour. Senior, meaning someone who has owned a framework migration and can read an MSBuild file without flinching, runs $140 to $185. A platform or DevOps engineer for the pipeline and container half sits in a similar range depending on how much Kubernetes is involved.

Do the arithmetic on the middle row, because that is where most companies land. Two contractors for ten weeks at a blended $155 an hour is roughly $124,000. Against that, the Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 as of May 2025, and that is base pay before the loaded cost of a permanent hire you do not need in April. The contract math is not close.

The number that should actually drive the decision is different, though, and it is not on either side of that comparison. It is the revenue attached to whatever your senior people were supposed to ship in Q1. For the Chicago team that was a customer commitment with a date in it. Compared to that, a six-figure contract squad was not really a cost question.

If the shape is still unclear, our notes on ratios and ramp plans for contractor pods cover how to split work between contract and permanent people without the handoffs eating the savings, and project staffing is the engagement model this falls under.

Sorting Your Services Before You Staff Anything

Every .NET 8 end of life plan I have seen work started with an inventory rather than a requisition. Do not put a req in before you have one. Every upgrade project I have watched go sideways went sideways because the scope was discovered in week three instead of week zero, and the contract had been written against the wrong number of weeks.

The sort takes an afternoon and goes in this order, because each step changes what the next one means.

1. List every deployed artifact and its target framework. Not repositories. Deployed things. The gap between those two numbers is where forgotten services live, and there is always at least one.
2. Mark which ones are internet facing. An unpatched runtime behind seven layers of network is a different risk than one answering requests from the public. This is what lets you sequence rather than panic.
3. Flag every Dockerfile and every custom base image. This is the Ubuntu problem, and it is the single best predictor of whether you need a platform engineer on the squad or not.
4. Identify services with no meaningful test coverage. Those are the ones where the C# 14 overload change and the shutdown signal change will hurt, because nothing will catch them. Budget test writing as part of the upgrade, not as a nice-to-have.
5. Note which ones a vendor or a certification touches. Regulated and vendor-certified apps move on somebody else’s timeline, and occasionally the honest answer is that one of them cannot move by November 10 and needs a documented risk acceptance instead.

That last one is worth saying plainly. Some services will miss the date. The goal is not a perfect sweep. It is knowing which ones missed it, on purpose, with somebody’s name next to the decision. A team with eleven of fourteen services on .NET 10 and a written risk acceptance on the other three is in dramatically better shape than a team that moved all fourteen in a rush and broke two of them.

We went through almost exactly this sequence with clients on the SQL Server 2016 end of life deadline in July, and the pattern held there too. The inventory is the deliverable that keeps paying. Once it exists, the next version deadline is a two-week project instead of a three-month one.

Six Things Teams Ask Me in October

Will our .NET 8 apps stop working on November 10?

No. They keep running exactly as they do today, and nothing in the runtime switches off.

What ends is Microsoft’s obligation to you. No security patches, no servicing updates, no support case. The first serious CVE published against .NET 8 after that date stays open on your servers permanently, and the only fix available will be the upgrade you were already putting off, done under pressure instead of on a plan.

We are on .NET 9. Does that buy us until 2027?

It buys nothing. .NET 9 ends on November 10, 2026, the same day as .NET 8.

Standard Term Support is two years and .NET 9 shipped in November 2024. I have had this conversation four times since Labor Day, always with a team that moved to 9 for a specific feature and reasonably assumed newer meant safer. It did not. Check your project files rather than trusting institutional memory on this one, especially if different squads made different calls.

Realistically, can a contractor be productive in 33 days?

Yes, and we fill IT roles in 17 days on average, so there is still room, but the window closes around the end of October.

Contract .NET is one of the deeper benches we work with, and a framework retarget is a well-defined ask, which makes it a fast search. The honest caveat is that nobody finishes fourteen services in the three weeks left after onboarding. What a start this month buys you is a real inventory, a sequenced plan, and your internet-facing services done first. The rest lands in December and January on a schedule you chose. That is a completely different year than starting in November.

Could we just pay for extended support like we did with SQL Server?

Microsoft does not offer a paid Extended Security Updates program for .NET 8 or .NET 9.

This trips up anyone who went through the SQL Server or Windows Server version of this exercise, where writing a check buys years. There is no equivalent here. Third-party vendors sell post-end-of-life support for .NET, and for a genuinely stuck application that is worth a look, but it is a containment measure with its own cost curve and not a substitute for the upgrade.

Does the .NET Upgrade Assistant handle this for us?

It handles the mechanical part well, which is maybe a third of the work.

Microsoft’s tooling will retarget project files, update package references, and flag API changes, and it genuinely saves days on a large solution. It will not fix your Dockerfiles, re-point a package feed off HTTP, write the tests you never had, or decide whether a vendor-certified app can move. Those are the things that consume the schedule. Treat the tool as a productivity multiplier on a person, not as the person.

Should this person convert to permanent afterward?

Sometimes, and the upgrade is an unusually good audition for it.

Ten weeks inside your build system, your deployment process, and your worst-documented service is more signal than any interview loop produces. If the work exposed that nobody owns runtime versions, package hygiene, or base images, that gap is permanent and the deadline just made it visible. Some of our clients run these as contract-to-hire from the start for exactly that reason. Others do not need the seat and should not create it, and we have talked a few of them out of a req they were about to open. If you do convert, our notes on interviewing contract engineers cover how to evaluate someone you have already been working with, which is a different problem than a cold loop.

Thirty-Three Days Is Enough. Sixty Would Have Been Better.

The clock is not the interesting constraint. Plenty of teams will clear this deadline, and a few will do it with their own people over a quiet December. The decision that actually costs money is whether you pull the two engineers who know your build system off the roadmap to do it, because that bill does not show up as a line item. It shows up in March, as a commitment you missed.

If you have .NET 8 or .NET 9 in production and you have not sorted your services yet, do that first. Then bring the list to a conversation with our team. We will tell you whether it reads like one contract .NET engineer for six weeks, a C# developer paired with a DevOps engineer for a quarter, or a list short enough that your own team should just handle it in December. That third answer comes up more than you would expect, and we would rather say it than sell you a squad you do not need.

KORE1 has been placing .NET and C# engineers since 2005, across more than 30 US metros, and 92 percent of the people we place are still there a year later. For a project that should be finished in twelve weeks, that number is mostly beside the point. It starts mattering on the ones that turn into a permanent seat, which happens often enough to plan for, usually once the upgrade has shown everybody what was never being maintained in the first place.

Our contract staffing practice covers the rest of the stack this deadline touches, and the application modernization guide is the longer read if your .NET estate includes anything still on .NET Framework, which is its own conversation and a much larger one.