Your application still opens. Orders are processed, staff can sign in, and the reports arrive. Then someone asks whether it uses .NET 8 and whether it will still be supported.
Microsoft lists November 10, 2026 as the end of support for .NET 8. After that date, normal Microsoft servicing for that release ends, including security updates. A .NET 8 to .NET 10 upgrade gives an existing business application a route onto a supported platform while keeping its useful workflows.
The application does not automatically stop working on the deadline. Continuing to operate, however, is different from having a supported runtime underneath it. The practical goal is a tested upgrade with clear ownership, a controlled release, and a way to recover if something goes wrong.
This guide covers what business staff should request from a software vendor, what developers need to investigate, and how to proceed if you are reading it in December 2026 or during 2027.
When does .NET 8 support end, and why choose .NET 10?
The .NET 8 support deadline is November 10, 2026. .NET 10 is a long-term support release, commonly called LTS, with a published support end date of November 14, 2028. Remaining supported also requires keeping current with applicable servicing updates and running on a supported operating system.
Those dates belong to the release. Installing .NET 10 in 2027 does not start a new three-year support period for your application.
Moving to .NET 9 does not solve this particular deadline. Microsoft lists the same November 10, 2026 support end date for .NET 9. Check the current Microsoft lifecycle and your vendors' compatibility requirements when approving the destination, especially if you are reading this later.
Also establish which product you actually have. .NET 8 and .NET Framework 4.8 are different platforms with different support rules. An application described as "a .NET system" could use either, or several technologies together. Our .NET Framework modernization guide covers that separate assessment.
LTS vs. STS: what is the difference?
LTS means Long Term Support. Under Microsoft's current .NET policy, an LTS release receives support and patches for three years from its release. STS means Standard Term Support, with a shorter, two-year support window under the current policy. Check the published end date for the specific version when making a decision.
Both are production releases. STS does not mean a preview or an experimental edition, and LTS does not mean a higher-quality or automatically more secure product. The main distinction is how long Microsoft supports the release. Both tracks require current patches and a supported operating environment.
For a business application that is expensive to retest or difficult to schedule for major upgrades, LTS can provide more time between required platform transitions. STS can suit a team with a planned, more frequent upgrade schedule when that release meets its technical needs.
Ask the software vendor to state the proposed release, whether it is LTS or STS, its exact support end date, who applies servicing updates, and when the next major upgrade is expected. An LTS choice still needs routine maintenance and application testing.
If it is already December 2026 or 2027, start here
Missing the support deadline calls for a prompt, organized response. It does not establish that the application has been compromised, and it does not make an untested production upgrade a good idea.
Reading this in December 2026
Ask the person responsible for the software to confirm the runtime used by each live application component. Get a written answer about what is unsupported, where it runs, and whether it accepts internet traffic or processes sensitive information.
Then agree on the next actions:
If there are signs of an active security incident, handle that through the incident response process as well. A framework upgrade is not an investigation or a remedy for every possible compromise.
Reading this during 2027
The November 2026 deadline has already passed. Do not wait for a visible failure or assume that another year of normal operation proves the platform is safe to keep indefinitely.
Recheck the proposed destination, its remaining support period, your hosting platform, and vendor component support. .NET 10's published support window extends into November 2028, so it can still be a practical destination during 2027. The business should also receive a maintenance plan for the next lifecycle transition.
Ask whether any promised upgrade actually reached production. A branch in the source repository, a developer's installed SDK, or a staging demonstration does not establish what the live system is running.
For packaged software, obtain the vendor's supported application release and upgrade instructions. If the original vendor is unavailable, confirm that another company has the rights and access needed to maintain the application before commissioning changes. Missing source code or an unsupported third-party component can change the scope substantially.
A guide for business owners and staff without an IT background
Start with the application and the work it supports. You do not need to identify a runtime by inspecting files yourself.
Write down the system name, vendor, web address or desktop shortcut, main users, and what would happen if it were unavailable. Include activities that run without someone opening the app, such as nightly imports, reminder emails, scheduled reports, and accounting transfers.
Send the vendor a concrete request:
Please confirm whether any part of our production system uses .NET 8. Identify the affected components, propose a supported upgrade destination, and provide a scope covering compatibility, testing, deployment, recovery, cost, and ongoing patching. Explain what our staff need to test and what evidence we will receive when the live upgrade is complete.
| Ask the software vendor | Ask for this evidence |
|---|---|
| Which parts of our live system use .NET 8? | A production inventory covering the website, APIs, background jobs, desktop clients, and deployment locations. |
| What will move to .NET 10, and what will stay behind? | An itemized scope, remaining unsupported components, and the reason for each exception. |
| What could change for staff or connected systems? | Compatibility findings and a test plan for the business workflows, permissions, reports, and integrations you use. |
| How will you release it and recover from a problem? | A rehearsed deployment plan, stop conditions, recovery steps, and a way to preserve transactions created after launch. |
| What will we receive when it is finished? | The release identifier, deployed runtime evidence, test results, updated operating instructions, and maintenance responsibilities. |
An answer such as "our servers are up to date" needs more detail. The application may carry its own copy of the runtime, or a background service may still use an older version even after the main website changes.
Likewise, a maintenance contract with a software company does not automatically extend Microsoft's support for .NET 8. Ask the vendor to distinguish its application support commitment from the support status of the platform and dependencies.
Business staff can contribute by defining the outcomes that must stay correct: an invoice total, an approval limit, a customer search, a printed report, or a file delivered to another system. Those examples make an upgrade estimate and acceptance plan more useful.
Developer step 1: inventory the application that is actually deployed
Identify every executable component: ASP.NET Core applications, APIs, worker services, scheduled tools, Windows services, and desktop clients. Record their owners, target frameworks, hosting locations, deployment mode, and release identifiers.
Inspect project files, central build settings, package references, publish profiles, and any global.json SDK selection. Compare the repository with the artifact and configuration that are running in production.
dotnet --info
dotnet --list-sdks
dotnet --list-runtimesThese commands show SDKs and shared runtimes visible to the selected dotnet installation. They do not prove that a particular application uses them, and they do not inventory a runtime bundled inside a self-contained application.
Check the application's runtime configuration, deployment files, container image where applicable, and running-process evidence available in your environment. Account for multiple server instances and architectures. A command run on a developer laptop says nothing conclusive about the production worker on another machine.
Distinguish framework-dependent deployment, which uses a compatible shared runtime installed in its environment, from self-contained deployment, which bundles the application's runtime. That distinction affects both the upgrade and future security servicing.
Developer step 2: establish a reproducible baseline
Build the current application from a controlled checkout before changing its framework. Record the toolchain, package sources, configuration requirements, and deployment procedure. Keep secrets in the appropriate secret store.
Run existing tests and capture representative business results. If useful automated coverage is missing, start with the calculations, permissions, data exchanges, and workflows most likely to cause harm if they change. Our regression testing guide for existing applications explains how to choose that first coverage.
Use a staging environment that represents the production operating system, hosting arrangement, identity setup, database behavior, and external interfaces. Test data should be appropriate for that environment, and outbound email, payments, or partner submissions need controlled destinations.
A screenshot of the current home page is a weak baseline for a system whose important work happens in scheduled jobs and integrations.
Developer step 3: assess the changes between .NET 8 and .NET 10
Review the relevant breaking changes in both .NET 9 and .NET 10, along with the ASP.NET Core changes for a web application and the database library changes for your chosen versions.
You can target .NET 10 directly without first deploying a .NET 9 release. Reviewing the intervening changes still matters because the application crosses those compatibility boundaries.
Build a dependency list that includes packages brought in indirectly, commercial controls, database providers, reporting libraries, authentication components, and native operating-system dependencies. Confirm supported combinations instead of assuming that every package should receive the same version number.
When updating Entity Framework Core, check provider compatibility, generated queries, mapping behavior, and any proposed schema migrations. A newer application runtime does not by itself require moving the database to a new server or redesigning its tables.
Look at behavior as well as compilation. For example, ASP.NET Core 10 changes cookie authentication behavior for recognized API endpoints: unauthenticated or forbidden requests receive 401 or 403 responses rather than a redirect to a login page. A client that depended on the older response needs testing.
Other application-specific checks may include serialization, culture-sensitive dates and numbers, background processing, certificate use, reverse-proxy configuration, and document rendering. Record the findings that affect this application rather than attaching an unexplained list of every platform change.
Developer step 4: update the project and its deployment environment
Install a supported .NET 10 SDK for development and build agents, and update any SDK selection in global.json. Update the target framework and the package versions that need to change for a supported combination.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>
</Project>Desktop projects may require a platform-specific target such as net10.0-windows. Other workloads and vendor components have their own compatibility requirements. The example above is a conventional web-project setting, not a universal replacement for every project file.
Edit the relevant settings in the existing project, preserving the other configuration it needs. Once the agreed changes are in place, restore dependencies, build, run the project's tests, and publish a candidate artifact.
dotnet restore YourSolution.sln
dotnet build YourSolution.sln -c Release --no-restore
dotnet test YourSolution.sln -c Release --no-build
dotnet publish src/YourApp/YourApp.csproj -c Release -f net10.0 --self-contained false -o ./artifacts/upgrade-candidateThis example creates local build and publish output. It does not deploy to production or establish that the candidate works under the intended hosting configuration. Test that published artifact in staging as well as testing the source.
Make the deployment plan match the publish mode:
Do not uninstall shared .NET 8 components until you have checked whether other applications still require them. Runtime removal and application migration are different actions.
Keep unrelated redesigns and feature requests in an explicit scope. A framework upgrade can become difficult to assess when it also changes the database, identity system, screens, and business rules without separate acceptance criteria.
Developer step 5: prove the business behavior still works
A successful build establishes that the selected source compiles. The release also needs to prove the outcomes people depend on.
Include the following in the agreed testing:
Include a realistic way to exercise month-end and other infrequent processes in the test environment. Waiting for the next live month-end to find out whether a report still works leaves an avoidable gap.
Give business users expected results they can verify. Our user acceptance testing checklist provides a structure for recording the scenario, role, expected result, actual result, and release decision.
Release the upgrade with a plan for new transactions
Rehearse the deployment, identify the responsible people, and agree on conditions that would pause or reverse the rollout. Where parallel operation is appropriate, control which instance can send notifications, charge customers, or perform other actions with real consequences.
If database changes are included, establish whether the previous application can still use the changed database. Keep application deployment and database migration decisions explicit.
Recovery must account for valid work created after the switch. Restoring an earlier database could erase orders, payments, or approvals entered since then. Define how those records will be preserved or reconciled before calling the plan complete.
After release, verify the deployed artifact and actual runtime across the intended components. Check live health, key workflows, background processing, and errors under the agreed safeguards. Honor Tech's go-live support service can help coordinate this readiness and transition work.
What should a .NET upgrade proposal include?
A useful proposal identifies the applications in scope, the proposed supported versions, dependency findings, required changes, testing responsibilities, deployment, recovery, and post-launch support.
Ask the vendor to separate the cost of compatibility work from optional improvements. Estimate drivers include source-code quality, test coverage, commercial controls, hosting changes, connected systems, and the number of independently deployed components.
An estimate should also identify unknowns and how they will be resolved. A focused assessment may be needed before the vendor can responsibly price the whole upgrade. Our software discovery deliverables checklist describes what that investigation should leave you with.
At handover, request the release record, deployed-version evidence, test outcomes, updated operating instructions, and the owner of ongoing servicing. Framework-dependent hosts, bundled runtimes, container images, and third-party packages all need an appropriate update process.
Common questions about upgrading .NET 8
Can a .NET 8 application keep running after end of support?
It may continue to run. That does not restore Microsoft's normal support or security servicing for .NET 8. Assess the application, its exposure, and a supported upgrade path rather than treating continued operation as evidence of support.
Does installing .NET 10 automatically upgrade a .NET 8 application?
No. Installing .NET 10 alone does not retarget, rebuild, test, and redeploy the application. Major-version roll-forward settings can affect runtime selection, but they are not a substitute for an assessed and tested migration.
Do we need to rebuild the entire application?
Not necessarily. Some applications need focused framework, package, and deployment changes. Others face substantial compatibility work. Ask which specific dependency or business requirement justifies a wider rebuild before accepting that scope.
Who should handle the upgrade if we do not have developers?
Start with the vendor responsible for the application. For custom software, a qualified maintenance company can assess the source, rights, dependencies, and deployment access. Business users still need to define and verify the workflows that must remain correct.
Get your business application onto a maintainable platform
Whether the deadline is approaching or already behind you, start with verified production facts and a defined release plan. The valuable outcome is working business software on a supported foundation, with someone responsible for keeping it that way.
Honor Tech's application support and maintenance service can help assess an existing application and scope compatible upgrades, testing, and continuing support. Tell us what the application does, who maintains it, and which versions you know.