CH
PL
What does "end of support" mean in practice?
An application does not stop working on 10 November. It keeps running, but it no longer receives security updates. Newly discovered vulnerabilities in the runtime or framework libraries remain open. This is especially critical for applications that are reachable from the internet, process personal data or are connected to core systems.
There are regulatory aspects as well. Organisations that fall under NIS2 or work according to ISO/IEC 27001 must demonstrate how they handle vulnerabilities and outdated software. Unsupported runtimes quickly stand out in audits.
Step 1: Take inventory.
The first step is a complete overview. In many companies, it is not immediately clear which applications run on which .NET version. An inventory should include at least the following:
- Name and purpose of the application, plus the responsible person or team
- Target framework in the project and the runtime actually installed on servers
- Hosting environment: on-premises, containers, cloud service
- Reachability: internal, external, connected via interfaces
- Criticality for business operations
It helps to search not only source code repositories but also servers, container images and build pipelines. Older services in particular sometimes run on machines that nobody actively maintains anymore.
Step 2: Check dependencies.
Changing the target framework is often the smaller part of the work. Effort arises from dependencies: NuGet packages not yet updated for .NET 10, internal libraries shared by several applications, or third-party components with their own release cycles.
For each application, a short assessment is worthwhile: Is the switch largely technical, meaning adjust the target framework, update packages, test? Or are breaking changes, obsolete APIs or larger adjustments to be expected? Microsoft documents the changes between versions in detail, and tools such as the .NET Upgrade Assistant support the analysis.
Step 3: Set the order.
Not all applications need to be migrated at the same time. A sensible prioritisation considers two dimensions: risk and effort.
- High criticality, low effort: migrate first. These applications deliver security quickly.
- High criticality, high effort: plan early, reserve resources and define interim measures if necessary.
- Low criticality, low effort: migrate them together in a single sprint.
- Low criticality, high effort: check whether the application is still needed or can be replaced.
The last point is often underestimated. A migration is a good opportunity to clean up legacy systems.
Step 4: Test and roll out
A migration is only complete once the application runs reliably in production. This includes automated tests, a trial run in a production-like environment, and a rollback plan. Load tests for applications with high data volumes and tests of all interfaces to partner systems are particularly important.
Do not forget to build and deploy pipelines. SDK versions, container base images and hosting configurations must be updated as well.
Step 5: Clarify responsibilities
The most common reason for delayed migrations is not technology but a lack of ownership. Who decides on the order? Who provides developer capacity? Who is responsible for testing and acceptance in the business unit?
A simple migration plan with owners, milestones, and dependencies creates clarity. It should be supported jointly by IT management, development, and operations.
Common pitfalls in .NET migrations
From migration projects, we know several patterns that repeatedly cost time:
- Forgotten services: a Windows service or a scheduled task that has been running quietly for years only shows up when the server is updated.
- Shared libraries: an internal library is used by ten applications. If it is migrated, all ten have to follow, or you need an interim version that targets multiple frameworks.
- Missing tests: without automated tests, every change becomes a manual effort. It is often worth building basic tests before the actual migration.
- Unclear configuration: settings, certificates and connection strings are not documented and first have to be reconstructed.
- Knowledge in individual heads: the person who built an application is no longer with the company.
If you ask about these points specifically during the inventory, you can estimate effort and risk far more realistically.
What management should know
For management, a .NET migration is rarely a topic until an audit or a security incident makes it visible. Yet the key points can be summarised in a few sentences: How many applications are affected? Which of them are business-critical? By when will which part be migrated? What capacity and budget are required? And how is the risk assessed for applications that temporarily continue to run?
A short, regular status update in this format builds trust and makes decisions about additional resources easier.
What if time runs out?
Many teams will not be able to migrate every application by 10 November. That is realistic, but it should be a conscious decision. Applications that temporarily continue to run on .NET 8 or 9 need a documented risk assessment and additional safeguards, for example restricted reachability, enhanced monitoring or a web application firewall. There are also vendors offering commercial extended support. Whether that makes sense depends on scope, budget and time horizon.
The key point: interim solutions are bridges, not destinations. They need an end date.
Capacity is the real bottleneck.
In conversations with IT leaders, we rarely hear that knowledge is missing. What is missing is time. Development teams are busy with new features, operations, and bug fixing. A migration runs "on the side" and keeps being postponed.
Additional .NET developers on a temporary basis can close this gap. They take on clearly defined work packages, such as migrating a group of services or building automated tests, while the internal team keeps day-to-day operations running. A clean handover is essential so that the knowledge stays in the company after the project.
Frequently asked questions
Will my application keep running after 10 November?
Yes. The application continues to work technically, but it no longer receives security updates. New vulnerabilities remain open, which increases the risk every month.
Should we move to .NET 10 or to a later version?
For most business applications, .NET 10 as a Long-Term Support release is the obvious step, as it is supported until November 2028. Teams that can update regularly should plan the next switch right away.
Conclusion
The end of support for .NET 8 and 9 is plannable. If you take inventory now, check dependencies, set an order and clarify responsibilities, a mandatory task becomes a manageable project. And if you assess capacity realistically, the migration will not get lost in day-to-day business.
At Suppliance, we support companies with experienced .NET specialists for migration and modernisation projects. Talk to us about your needs.