Take a hypothetical wholesale distributor whose order-entry application runs on a Windows Server 2016 virtual machine. The web front end is an ASP.NET site in IIS 10 that targets .NET Framework 4.6.2. On the same VM, a Windows service picks up supplier price files from a file share, and a scheduled task emails the overnight backorder report. The order database lives on its own SQL Server. Microsoft's list of products reaching end of support in 2027 gives Windows Server 2016, "IIS 10 on Windows Server 2016" and ".NET Framework 4.6.2" the same date, January 12, 2027, after which there will be "no new security updates" for them. The distributor's deadline work is moving the application to a newer Windows Server, and the first decision in that move is which .NET runtime the new server will carry.
Why .NET Framework 4.8 on the same server buys no time
The tempting plan is to update the runtime now and move the server later. In Microsoft's lifecycle table, among 4.6.2 and the versions after it, only the 4.6.2 row has an end date. The .NET Framework lifecycle FAQ says "We recommend customers upgrade to .NET Framework 4.8", and the versions table marks 4.8 as a version that "doesn't come installed but can be installed" on Windows Server 2016.
The support date stays put. The FAQ says .NET Framework from 4.5.2 on "is defined as a component of the Windows operating system (OS)" and "follows the lifecycle policy of the underlying Windows OS on which it is installed." Its 4.8 entry repeats that rule and lists Windows Server 2016 among the supported servers. So 4.8 on the distributor's VM is supported for as long as Windows Server 2016 is, and that ends on January 12, 2027. The .NET Framework lifecycle page is consistent with that rule: the 4.6.2 row carries an end date, the rows for 4.7 through 4.8.1 leave the end date blank, and the FAQ gives each of those later versions the support dates of the Windows version it is installed on.
Version 4.8.1 is off the table on this server. The versions table lists it for Windows Server 2025, where it is installed by default, and Windows Server 2022, where it can be installed. No older server appears in that row, and the FAQ's 4.8.1 entry names the same two. That makes 4.8 the newest .NET Framework supported on Windows Server 2016, with support ending alongside the server.
Installing 4.8 is still worth doing once, on a clone of the VM. The FAQ calls 4.6.2 and later versions "compatible, in-place updates" over the earlier 4.x releases, says "Recompiling of apps to target these versions is not necessary," and recommends trying a newer runtime "in a pre-production environment first". On the clone, with a test configuration that points at a copy of the database, a test file share and a test mail recipient, the distributor runs order entry, one supplier price file and the backorder report at 4.6.2 first and records the results. Then it installs 4.8, leaves the site's target framework at 4.6.2 and runs the same three again. A new failure after the update points the investigation at the runtime change, since the OS and the build stayed the same.
Microsoft also notes that some fixes "will only be enabled if you choose to recompile your application against them" and calls them retargeting changes, so a rebuild against 4.8 is a separate test pass. The clone tests the runtime on the old OS only; the destination server gets its own test later.
What the 2016 server actually runs
The inventory comes from the server itself. A scheduled task or service configured by hand can be missing from the repository and the deployment scripts, so the list compares what is installed on the VM with what the scripts deploy. For the distributor that means each IIS site with its application pool, bindings and certificate, each Windows service with the account it runs under and the share it reads, each scheduled task that is not part of Windows, and any SQL Server instance installed on the VM.
Which runtime is installed is recorded in the registry. Microsoft's version check page names the Release REG_DWORD under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. On Windows Server 2016 the value for 4.6.2 is 394802, and after a 4.8 install it is 528049, the value the page gives for "all other Windows operating systems". Writing the value down for the production VM and the clone shows which runtime each test actually ran on.
A local SQL Server instance changes the plan. Replacing the VM then means moving that database as well, and if the instance is SQL Server 2017 it has its own row in the same 2027 list, ending support on October 12, 2027. The distributor's database sits on its own server, so its VM can be replaced without moving data.
Which runtime should the new server carry?
For an application whose only problem is the date, we would keep it on .NET Framework and choose the destination by runtime. Windows Server 2022 comes with 4.8, the runtime the clone rehearsal tested. Windows Server 2025 comes with 4.8.1, so choosing it adds 4.8.1 to the destination test. Microsoft's versions page says ".NET Framework will continue to be included with Windows, with no plans to remove it." For the distributor we would pick Windows Server 2022 and keep the runtime the rehearsal already exercised.
A port to .NET 10 is a separate decision, made for its own reasons. Our article on .NET 8 and .NET 9 end of support covers what moving to modern .NET involves for a business application. A .NET 10 project also audits transitive packages during restore by default, and "If your project treats warnings as errors, this behavior can cause restore failures," which NuGet Audit in .NET 10 covers. If a port is justified, we would ship it as its own release after the server move. Changing the operating system and the runtime family on the same night leaves a failed order-entry page with two possible causes and a rollback that has to undo both.
The cutover leaves the database where it is
Microsoft's Windows Server upgrade overview supports an in-place upgrade from Windows Server 2016 to 2019, 2022 or 2025 using installation media. That upgrade "Installs a newer version of Windows Server over the existing one, keeping your settings, server roles, features, and data", and the page warns that "Not all roles support in-place upgrade". We would build a new Windows Server 2022 VM beside the old one, so the 2016 VM stays as it is, ready to start again if the cutover fails.
On the new VM, the team installs IIS, deploys the same build of the site with its bindings and certificate, installs the Windows service under the same account with access to the share, and recreates the backorder task, leaving the service stopped and the task disabled except while a test runs. It runs the three workflows with the test configuration and records the imported file's name and result and the report task's outcome. Then it switches the configuration to the production database, supplier share and mail settings, and confirms the service account can reach each one before anything runs against them.
Unless the importer claims each file before processing it, two running copies of the service could both pick up the same supplier file, so only one VM may run the service and the task at any moment. At cutover, the team stops the service on the 2016 VM and sets it to Disabled, disables the backorder task, and checks that no import or report run is still in progress. Only then does it start the service and enable the task on the new VM, and move the site's DNS name.
Rollback runs the same handoff in reverse: start the 2016 VM and check the site answers on it, stop and disable the service and the task on the new VM and confirm nothing is still running, then re-enable and start them on the old VM and move the name back. It stays available while both VMs can run the same build against the same database. The first release that changes the schema in a way the old build cannot read closes that option, and our legacy application modernization guide covers where rollback gets expensive once data changes shape. We would keep the old VM powered off and unchanged, and close the fallback window before January 12, 2027, the end-of-support date for Windows Server 2016.
How IKRC would plan the move
For a business in the distributor's position, the .NET development work produces four records, each one checked before the next step starts:
- An inventory of the 2016 VM: sites with bindings and certificates, services with their accounts and shares, hand-made scheduled tasks, any local SQL Server instance, and the Release value.
- A rehearsal record from the clone, before and after 4.8, with the result of each workflow.
- A destination test record from the new Windows Server 2022 VM, run with the test configuration. The VM can be on premises or an Azure virtual machine; Microsoft's Windows VM quickstart builds one that "runs Windows Server 2022 Datacenter" and installs IIS on it.
- A cutover sheet with the production settings confirmed, which VM runs the service and the task at each step, the DNS change, the rollback steps and the date the fallback window closes.
Related Reading
.NET 8 and .NET 9 end of support covers the modern .NET side of this decision, the legacy application modernization guide covers phased replacement and rollback, and NuGet Audit in .NET 10 covers a restore failure that a move to .NET 10 can bring.