Quick answer: .NET 8 and .NET 9 both reach end of support on 10 November 2026. After that date Microsoft stops releasing security patches, bug fixes and technical support for them. Your apps will keep running, but any new vulnerability stays unpatched. If you still have .NET 8 or 9 applications in production, the safest target is .NET 10, the current Long Term Support (LTS) release. With about two weeks left, the practical plan is to inventory every app, rank them by risk, upgrade the simple ones now, and put a documented plan around the complex ones.
Why 10 November 2026 matters
Most businesses think of .NET end of support as a distant, technical milestone. This time two widely used versions expire on the same day. .NET 8 was an LTS release, and .NET 9 was a Standard Term Support release whose support window Microsoft extended to match. That means a large share of modern .NET applications in Australia are about to lose official support together.
End of support does not mean your software stops working. It means:
- No more security patches. Vulnerabilities discovered after 10 November stay open in your runtime.
- No bug fixes or technical support from Microsoft for those versions.
- Growing compatibility risk. New libraries, tooling, Azure services and hosting images increasingly target .NET 10 and later.
- Compliance and insurance exposure. Running unsupported software is hard to defend in a security review, an audit or a cyber insurance claim.
If you want the full background on why the upgrade matters, read our earlier guide: .NET 10 Migration Guide: Why Australian Businesses Need to Upgrade Before November 2026. This article is the short, practical version for the final stretch.
Is your app affected? A 5-minute check
You are affected if any of the following is true:
- A project file contains <TargetFramework>net8.0</TargetFramework> or net9.0.
- Your servers or containers run the .NET 8 or .NET 9 runtime or SDK.
- Your Azure App Service, Azure Functions or other hosting is set to a .NET 8 or .NET 9 runtime stack.
- A vendor or agency built your application and you do not know which version it uses.
A few quick ways to find out:
- Run dotnet –list-runtimes on your servers to see which runtimes are installed.
- Search your repositories for net8.0 and net9.0 in .csproj files, and check global.json for pinned SDK versions.
- Check your Dockerfiles and CI/CD pipelines for base images and SDK setup steps that reference version 8.0 or 9.0.
- In the Azure portal, open each App Service or Function App and check the configured runtime stack.
- Ask your development partner for a list of applications and the framework version each one uses.
Note that .NET Framework 4.8 is a different product with its own support lifecycle tied to Windows, so it is not affected by this date. If you have older .NET Framework apps, see our legacy migration roadmap.
The last-minute upgrade checklist
Step 1: Build a complete application inventory
List every .NET application, API, background service, scheduled job and Azure Function. Include internal tools and anything built by a previous vendor. Record the .NET version, hosting location, owner and last release date. The apps people forget are usually the ones that end up exposed.
Step 2: Rank each app by risk
You will not be able to treat every application equally in two weeks, so triage them. Prioritise the apps that:
- Are exposed to the internet, such as customer portals, public APIs and web stores.
- Handle personal, financial or health information.
- Process payments or connect to third-party systems.
- Are business-critical, so downtime would be costly.
Internal tools with no external exposure and low data sensitivity can follow later, as long as you record the decision.
Step 3: Sort apps into three upgrade groups
| Group | What it looks like | Typical approach |
|---|---|---|
| Quick wins | Small apps, few dependencies, good test coverage | Retarget to .NET 10, update packages, test, deploy |
| Moderate | Larger apps, several third-party packages, some custom hosting | Upgrade in a branch, fix breaking changes, full regression test |
| Complex | Legacy components, poor test coverage, heavy integrations or unsupported libraries | Plan a staged upgrade with a risk mitigation plan in the meantime |
The quick wins can often be done in days. Moderate apps typically take a few weeks. Complex systems may need a longer project, and that is fine as long as you manage the risk in the meantime (see Step 8).
Step 4: Upgrade the project files and packages
For a typical application, the core steps are:
- Create a new branch and make sure the current build and tests pass first.
- Update the target framework to net10.0 in each project file, and update global.json if you pin an SDK version.
- Update NuGet packages, including Entity Framework Core, ASP.NET Core packages and Microsoft.Extensions libraries, to versions that support .NET 10.
- Review Microsoft’s published breaking changes for .NET 10 and fix compiler warnings and errors.
- Check third-party libraries for .NET 10 compatibility. If a package is abandoned, plan a replacement.
Microsoft and GitHub provide upgrade tooling that can analyse a project and suggest changes. It is a useful starting point, but treat its output as a draft and review every change.
Step 5: Update build, containers and hosting
A code upgrade is only half the job. Make sure your delivery pipeline matches:
- Update CI/CD pipelines to install the .NET 10 SDK.
- Update Docker base images to the .NET 10 runtime and SDK images.
- Change the runtime stack in Azure App Service, Azure Functions or your other hosting platform.
- Update any servers that still need the .NET 8 or 9 runtime installed, and plan to remove the old versions once everything has moved.
Step 6: Test properly, not just “it builds”
A successful build does not prove the app behaves correctly. Run your automated tests, then manually check the critical paths: logins, payments, reports, file uploads, integrations and scheduled jobs. Pay attention to:
- Database queries and Entity Framework behaviour changes.
- Date, time and culture handling.
- Authentication and authorisation flows.
- Performance under realistic load.
If you have little or no test coverage, this is the moment to add tests around your most important workflows.
Step 7: Deploy with a rollback plan
Release to a staging environment first, then to production during a low-traffic window. Keep the previous version ready to restore quickly, and monitor logs, error rates and response times closely for the first few days.
Step 8: Have a plan for anything you cannot finish in time
Some applications will not be ready by 10 November. That is a manageable situation if you handle it deliberately rather than ignoring it. For those apps:
- Document the risk. Record the app, the reason it is delayed, the owner and a target date for the upgrade.
- Reduce exposure. Put the app behind a web application firewall, restrict network access, and remove public access if it is not needed.
- Tighten monitoring. Watch for unusual activity and keep dependencies and the operating system patched.
- Set a firm deadline. Agree on a date to finish the upgrade, ideally within weeks rather than months.
- Tell the right people. Let your security lead, leadership and, where relevant, your cyber insurer know.
Australian compliance and insurance considerations
Running unsupported software is not just a technical issue. For Australian organisations it can affect:
- The Privacy Act 1988. Entities covered by the Act must take reasonable steps to protect personal information from misuse, interference and loss. Knowingly running unpatched software that handles personal data makes that harder to demonstrate.
- The ACSC Essential Eight. Patching applications and avoiding unsupported software are core parts of the Australian Cyber Security Centre’s baseline mitigation strategies.
- Cyber insurance. Insurers increasingly ask about patching and software lifecycle practices, and unsupported systems can complicate a claim or a renewal.
- Customer and supplier contracts. Enterprise and government customers often require suppliers to run supported software.
This is general information rather than legal advice, so check your specific obligations with your compliance or legal team.
Common mistakes to avoid
- Waiting until the date passes. The risk starts on 10 November, but the pressure to rush mistakes starts well before it.
- Only upgrading the code. Forgetting build agents, containers and hosting settings leaves old runtimes in production.
- Skipping testing to hit the deadline. A rushed upgrade that breaks payments or logins is worse than a documented delay.
- Forgetting forgotten apps. Old internal tools, scheduled jobs and Azure Functions often escape the inventory.
- Assuming your vendor has it covered. Ask directly which applications are affected and when they will be upgraded.
Should you upgrade in-house or get help?
If your team has capacity and the apps are small, an in-house upgrade is realistic. Bringing in specialists makes sense when you have several applications to move at once, when the codebase is large or poorly tested, when key developers have left, or when you simply do not have the time before the deadline. A good partner will start with an assessment, give you a prioritised plan, and make the upgrade without disrupting your business.
If you are weighing up costs, our guide to .NET development costs in Australia explains typical pricing, and you can learn more about our custom software development and dedicated .NET developer services.
Frequently asked questions
What happens to my app on 10 November 2026 if I do nothing?
It will keep running. However, Microsoft will no longer issue security patches or fixes for .NET 8 or .NET 9, so any vulnerability found after that date remains unpatched in your runtime.
Do I need to upgrade to .NET 10, or can I wait for .NET 11?
For most businesses, .NET 10 is the right target because it is an LTS release with a longer support window. Waiting for a newer release means running unsupported software in the meantime, and you would still need to plan another upgrade later.
Is .NET Framework 4.8 affected by this deadline?
No. .NET Framework 4.8 follows a separate support lifecycle linked to Windows. That said, moving legacy .NET Framework applications to modern .NET is still worth planning because it unlocks better performance, security and cloud options.
How long does a .NET 8 or 9 to .NET 10 upgrade take?
It depends on the size and complexity of the application. Small apps with few dependencies can often be upgraded in days, while larger systems may take several weeks and complex ones longer. An assessment will give you a realistic estimate.
Is upgrading from .NET 8 or 9 to .NET 10 difficult?
It is usually much easier than migrating from .NET Framework, because .NET 8, 9 and 10 share the same modern foundation. The main work involves updating packages, fixing breaking changes, updating hosting and build pipelines, and testing thoroughly.
Can I upgrade directly from .NET 8 to .NET 10?
Yes. You do not need to step through .NET 9. You can retarget straight to .NET 10 and review the breaking changes for the releases in between.
What if one of my libraries does not support .NET 10?
Check for an updated version first. If the package is no longer maintained, you will need to replace it or isolate it. This is one of the most common reasons an upgrade takes longer than expected, so identify these packages early.
Need a hand before the deadline?
Dotnet Professional is a Microsoft-partnered .NET development company with teams in Sydney and Melbourne. We can audit your applications, rank them by risk, and upgrade them to .NET 10 with minimal disruption to your business.
Contact us to book a .NET upgrade assessment before 10 November.