Your server can show a supported .NET runtime while an internal application still carries an unsupported copy of its own. Closing an upgrade ticket from the server's installed-software list can therefore leave the application unchanged.
Microsoft says support for .NET 8 and .NET 9 ended on 10 November 2026: applications can continue running, but those releases no longer receive its security updates or technical support. The useful decision now is who must change each deployed application, and what proves the change reached production.
The checks below are our operational recommendation for teams responsible for internal tools, portals and background services. They focus on the deployed runtime rather than a general migration schedule; our PHP upgrade planning guide covers the broader dependency-and-target exercise in another ecosystem.
Find the runtime that belongs to the running application
A developer's workstation and a production host can have different installations, so collect evidence where the application runs. Start with the service definition, deployment record and publish settings. Record the application owner, environment, package identifier and the location from which the process starts.
Microsoft documents dotnet --list-runtimes for installed runtimes and dotnet --list-sdks for installed SDKs. Use those commands as an inventory aid. They do not, by themselves, establish which package your deployment system launched or whether the application bundles its runtime.
Ask the maintainer to connect the installation inventory to the application's publish configuration and deployed package. If the evidence stops at a screenshot from a laptop, leave the task open. For a managed platform, ask the operator how it identifies the runtime used by your application rather than assuming its host inventory is available to you.
The technology lead should leave this check with a named application and a traceable deployment, not a general statement that “the server is updated.”
Separate host maintenance from application releases
A self-contained application carries its runtime in its published output, while a framework-dependent application uses a runtime installed in its execution environment. Microsoft describes both modes in its application publishing documentation, including the need for a new application release to upgrade a self-contained runtime.
Use the deployment mode to assign responsibility. The table is a suggested handoff, not a rule imposed by Microsoft.
| Deployment you identify | Who should own the next action | Evidence to request |
|---|---|---|
| Framework-dependent application maintained internally | Application maintainer together with the hosting owner | Supported application target, required host runtime and deployed package |
| Self-contained application maintained internally | Team that publishes and releases the application | Replacement package with the supported runtime, plus proof it was deployed |
| Application supplied by an external vendor | Vendor, coordinated by your application owner | Supported replacement release and its installation procedure |
| Deployment mode or package origin unknown | Application owner | Publish configuration or vendor confirmation before choosing a remedy |
Do not treat installing a supported major runtime beside an old one as proof that the application migrated. Microsoft's upgrade guidance covers application target changes as well as development, continuous integration and hosting updates.
The operations owner should assign an application release or a vendor request wherever a host-maintenance ticket cannot demonstrate the required change.
Choose a supported target that your dependencies allow
The newest release is not automatically the target your application team can support. Microsoft's current support policy, updated on 10 November 2026, lists .NET 10 as LTS and .NET 11 as STS, with both supported through 14 November 2028. Check that table again when approving the change.
For a maintenance upgrade, our recommendation is to evaluate the supported target your libraries, hosting platform and vendor integrations already accommodate. Choosing the established LTS release can be reasonable; choosing the newer supported release can also be reasonable when its compatibility evidence is stronger. Record the reason instead of relying on the label alone.
Build success is only part of that evidence. Microsoft distinguishes source, binary and behavioural incompatibilities in its .NET 10 breaking-change catalogue. Use the documentation for your chosen target to select tests for the application's actual dependencies and business paths.
Have the maintainer propose the target and the product or operations owner identify the workflows that must work before release approval.
Follow a background worker through the whole handoff
Consider a hypothetical order-export worker published as a self-contained application on the unsupported runtime. The infrastructure team updates the machine and reports that a supported runtime is installed. The worker's release package remains unchanged.
Because its runtime travels with its application package, the corrective action belongs to the worker's release process. Ask its maintainer to prepare a replacement, test it in an isolated environment and identify the exact package intended for production. Treat this as a separate application change even if the server maintenance happened in the same window.
For the business check, use a representative export with safe test data. Check the destination record, field mapping and failure handling. A process that starts successfully but sends an incomplete order has not met the operational acceptance criteria.
If the worker writes to another system, agree how to pause it and account for work already processed before any rollback. Keep the previous package available, but do not assume reinstalling it reverses business data changes.
The release owner should attach the deployed package identifier and the workflow result before the operations owner closes the task.
Close the task with evidence from the deployed service
A deployment log can establish that a release step ran; connect it to the service now doing the work. Before accepting completion, ask for this short record:
- The application, environment, owner and deployment mode.
- The chosen supported target and the reason it fits the dependencies.
- The package or image identifier actually deployed, with its runtime information.
- The hosting change, where the deployment requires a shared runtime.
- A business workflow result and any unresolved compatibility issue.
- The recovery action and the person authorised to invoke it.
If the supplier controls the package and cannot provide an updated release, an infrastructure change is not a substitute. Record the unresolved dependency, obtain the supplier's proposed route and put a decision date against it. Any temporary containment is a separate risk decision; it does not restore Microsoft's support for the old runtime.
Start with the application whose deployment mode you cannot currently explain. Ask its owner to fill in the record above, then use our legacy-system inventory guide to extend the same ownership map across the rest of the estate.
Sources
- Microsoft, .NET 8 and .NET 9 end-of-support announcement, 29 June 2026.
- Microsoft, .NET Support Policy, updated 10 November 2026.
- Microsoft Learn, .NET application publishing overview, current documentation consulted November 2026.
- Microsoft Learn, Check installed .NET versions, current documentation consulted November 2026.
- Microsoft Learn, Upgrade to a new .NET version, current documentation consulted November 2026.
- Microsoft Learn, Breaking changes in .NET 10, current documentation consulted November 2026.
