Congratulations, Your “Modern” .NET App Needs Another Upgrade

Remember getting budget to move your application to .NET 8? The business case, the meetings, the explanation of why something that still worked needed upgrading?

You picked Long-Term Support. Sensible choice. You probably hoped to spend a little less time talking about runtimes.

Well, check your calendar.

On November 10, 2026, 15 days* from today, both .NET 8 and .NET 9 reach the end of Microsoft support. The team that chose the LTS release and the team that wanted last year’s new features now have the same deadline.

Hopefully someone booked time in the sprint.

What actually happens on November 10?

Your application won’t stop working. Nobody at Microsoft is reaching for a giant off switch.

But Microsoft will stop providing security fixes, servicing updates, and technical support for those versions. .NET 8’s three-year support window is closing, and .NET 9’s two-year window ends on the same day.

That matters wherever the runtime lives:

• On a server: Keeping the operating system patched doesn’t make an unsupported .NET runtime supported.
• In a container: You’ll need to update your base images, rebuild, and redeploy. A Dockerfile isn’t a preservation order.
• Bundled with your application: Self-contained deployments carry their own runtime. Updating the host won’t update the copy packaged with your app.

For teams looking for a supported LTS destination, .NET 10 is already available and supported through November 14, 2028. You can start now.

Didn’t we just modernize this thing?

We hear some version of this a lot.

A team spends real money moving an application forward. Leadership celebrates. Everyone would quite reasonably like to work on something else.

Then another upgrade comes due, and someone asks, “What did we pay for last time?”

It’s a fair question. We haven’t always done a great job explaining that modernization comes with ongoing maintenance.

Moving to modern .NET should make future changes more manageable. It doesn’t mean you’re finished making them. The budget needs to include keeping the application current, along with getting it there.

That’s a harder sell than “one project and we’re done.” It’s also a more honest one.

Please don’t promise a five-minute upgrade

Moving from .NET 8 or 9 to .NET 10 generally shouldn’t require rewriting your application. But “just change the target framework” leaves out quite a bit of work.

There are dependencies to check, build environments to update, and behavior to test. Microsoft publishes breaking changes for a reason. ASP.NET Core and Entity Framework Core changes may matter just as much as changes to the runtime itself.

And yes, there may be a PDF library that has quietly become load-bearing.

Some teams will move quickly. Others have vendor dependencies, regulated workflows, or complicated integrations that need more testing. That doesn’t automatically mean they’ve built something badly.

Still, if every upgrade requires weeks of people manually clicking through screens, it’s worth asking what would make the next one easier. Better automated tests? Fewer unsupported packages? A clearer deployment process?

The goal is to get comfortable enough with upgrades that they stop becoming company events.

What this means for the application still waiting its turn

If you’re maintaining a VB6, PowerBuilder, or Clarion application, you may be reading this and thinking, “Great. We haven’t even migrated yet, and the destination already needs maintenance.”

Fair.

Those applications often contain decades of business knowledge. They’re still running because they do useful work, and replacing them deserves more thought than a joke about old technology.

But the .NET support deadline raises a useful question for any modernization project: How easy will this application be to maintain after we move it?

Ask what the team will receive. Can they understand and change the generated code? How will they verify that the business rules survived? Can they build, test, and deploy it reliably? Who owns the next runtime upgrade?

Whether you use deterministic tools, AI, or both, those questions belong in the plan from the beginning.

Otherwise, you risk spending a lot of money to create an application nobody wants to touch—with a newer copyright date.

What to do this week

If you still have .NET 8 or .NET 9 in production:

1. Find what’s actually deployed. Check project files, SDK settings in global.json, Dockerfiles, build pipelines, and hosting environments. Include background jobs and the small internal tools everyone forgets about until they stop working.
2. Plan the move to .NET 10. Confirm that your hosting environment, tooling, and key dependencies support it. Give someone ownership of the upgrade and a deployment date.
3. Test the workflows that matter. Review the relevant breaking changes and check authentication, data access, integrations, and critical business processes. A successful build is encouraging. It isn’t the whole test plan.
4. Schedule the next upgrade before closing this one. Include dependency reviews, runtime updates, testing, and deployment in normal maintenance work. Give them actual time on the calendar.

And if your starting point is a 500,000-line desktop application that’s been scheduled for modernization “next year” since 2019, come talk to our team of mega nerds.

We’d love to help you get it onto modern .NET and make sure the next upgrade is a much smaller conversation. Btw, we wrote a more detailed post about this a few months ago.

*If you're reading this after November 26, 2026 and you're still using .NET 8 or .NET 9, your situation has not improved.