Your .NET Application Is Running on a Windows Server Version Nobody Can Patch

Moving the server and upgrading the framework are two separate projects. .NET Framework 4.8 runs on current Windows Server versions, so an application can leave an unsupported server without a migration to modern .NET. If the deadline is about the operating system, do the server move alone. It is the smaller project.

Three checks to run this week

1. Inventory what runs on the old server. IIS sites and application pools, including bitness and identity. Windows services. Scheduled tasks and the account each runs as. Installed programs. Certificates in the machine store.
2. Find the machine-specific assumptions. Search configuration and code for drive letters, UNC paths, server names, IP addresses and registry keys.
3. Check the framework version. An application targeting 4.5 or 4.6 should be retargeted to 4.8. That is usually a small change, and it also brings current TLS defaults.

What tends to break on the new server

• 32-bit dependencies. An application pool that needs "Enable 32-Bit Applications", or an old ODBC or OLE DB driver with no 64-bit version.
• COM components that were registered by hand years ago, including Office automation.
• IIS modules and ISAPI filters installed separately: URL Rewrite, old authentication modules.
• File paths and shares. Hard-coded drive letters, and NTFS permissions that were granted on the old machine. The 401 pattern on a new IIS setup is a common one.
• Certificates and private key permissions for the application pool identity.
• TLS. Newer Windows versions disable old protocol versions, which affects calls to older partners and database servers.
• Outbound access. Firewall rules, SMTP relay permissions and IP allowlists at third parties that name the old server.
• Scheduled tasks that depend on a local account or on running in a set order.

The order of work

Inventory first. Build the new server from a written list, and keep that list as documentation. Install prerequisites, deploy a copy of the application, and point it at a copy of the database. Fix what fails. Run both servers side by side. Cut over with DNS or the load balancer so that rollback is one change. Keep the old server powered off but intact for a few weeks.

Verification

With no automated tests, comparison is the test. Run the same inputs through both servers and compare outputs: the main reports, exports, generated PDFs, emails sent, and the results of each scheduled job. Have the heaviest users walk their daily workflows on the new server before cutover. This step usually takes longer than the build.

For a mid-size internal application with a handful of integrations, expect weeks. The count of items in the inventory sets the number. If modern .NET is the next step, see the migration timeline.