Legacy .NET Framework 1 to 4.7:
Upgrade the oldest .NET, in order.

Applications on .NET Framework 1.0 through 4.7 are in different situations. Versions 1.x, 2.0, 3.0, and 4.0 are long out of support, 4.6.2 has an end-of-support date of January 13, 2027, and 4.8 and 4.8.1 are still supported. The realistic path is a stepwise upgrade to 4.8, then to current .NET, unless one bounded context justifies re-architecture.

Book a free 1-hour consultation →

At a glance

Legacy sources: .NET Framework 1.0 and 1.1 · .NET Framework 2.0 · .NET Framework 3.0 and 3.5 · .NET Framework 4.0 to 4.7 · ASP.NET WebForms · ASMX and .NET Remoting · VB.NET 2003 · ClickOnce and Windows services
Modern targets: .NET Framework 4.8 as a stepping stone · C# on .NET 10 LTS · SDK-style projects · ASP.NET Core · CoreWCF or web APIs · Event-sourced bounded context where warranted
First step: Free 1-hour consultation, then a fixed-scope assessment
U.S. delivery: 100% U.S. citizen workforce, U.S.-soil delivery

What to know before you modernize

What these systems usually look like

Applications on the oldest .NET Framework releases share a recognizable shape. The web tier is ASP.NET WebForms with ViewState and code-behind. Services are ASMX web services or .NET Remoting endpoints. Data access runs through typed DataSets and TableAdapters, often with Microsoft Enterprise Library blocks around them. Reports come from Crystal Reports. Background work is a Windows service, desktop clients ship by ClickOnce or an installer, and COM interop and the Global Assembly Cache (GAC) tie the whole thing to one specific server. Some are in VB.NET from the Visual Studio 2003 era. None of this is wrong. It is a coherent design for its time, and the business rules inside it are usually the most valuable part. The upgrade project exists to move that logic onto a supported runtime without losing it.

Support status by version, with dates

Microsoft's lifecycle pages give these dates. Support for .NET Framework 1.0 at service pack 1 ended on October 8, 2013, and 1.1 SP1 on Windows Server 2003 ended on July 14, 2015. Versions 2.0 and 3.0 ended on July 13, 2011. Version 4.0, 4.5, and 4.5.1 ended on January 12, 2016, and 4.5.2, 4.6, and 4.6.1 ended on April 26, 2022. Version 4.6.2 is listed with an end date of January 13, 2027. Version 3.5 SP1 is listed through January 2029 and is the longest-lived of the old line. Versions 4.7 through 4.8.1 follow the lifecycle of the Windows version they run on, and 4.8 and 4.8.1 are the current releases. Microsoft states that .NET Framework will continue to ship with Windows, with no plans to remove it. Check the exact dates for your operating system before relying on them.

The .NET Framework upgrade overview →

Why 1.x and 2.0 are harder than 4.x

A 4.x application is mostly a retarget. A 1.x or 2.0 application is a recovery project first. Version 1.x has no generics, so the code uses ArrayList and Hashtable with casts and weak typing everywhere. Generics, ClickOnce, and 64-bit support arrived in 2.0. Project files from the Visual Studio 2002 and 2003 era are not in a format current tooling opens cleanly, so projects are rebuilt in the current format with the source files added back rather than converted. Source for some assemblies is often missing, and the dependency list lives in someone's memory. Third-party libraries from that period may no longer have a vendor or a download. Finally, nobody has run the build outside one machine for years. The first deliverable is therefore not an upgrade at all; it is a clean build from a fresh checkout with every dependency accounted for.

Runtime facts that shape the order of work

Several runtime facts decide the sequence. Versions 2.0, 3.0, and 3.5 share one runtime, CLR 2.0, and install as layers of one product, so a 2.0 application can run on a 3.5 installation. Version 4 broke that layering, and 4.5 through 4.8.1 are in-place updates of the 4.x runtime, so an application built for 4.0 or later normally runs on 4.8 without recompiling. Applications that target 2.0 through 3.5 need the 3.5 feature enabled on current Windows. Visual Studio 2022 and later can no longer build projects that target .NET Framework 4.0 through 4.5.1, so those projects must be retargeted or built with Visual Studio 2019. The practical consequence is that retargeting to 4.8 is the cheap first step for any 4.x application, and 2.0 to 3.5 code can usually move to 4.8 with a retarget and a test pass.

The stepwise upgrade path

The order we recommend is the same for most of these systems. First, get a reproducible build with all sources and dependencies in version control, and write characterization tests around the behavior that matters. Second, retarget to .NET Framework 4.8, which is supported and stays on Windows, and fix what breaks. Third, remove the technologies that have no future, covered in the next section, behind interfaces. Fourth, convert libraries to SDK-style projects and move shared code to .NET Standard or multi-targeted libraries, upgrading them in dependency order. Fifth, move executables to .NET 10, which is a long-term support release under support until November 14, 2028. Microsoft notes that .NET 8 and .NET 9 both end on November 10, 2026, so they are not good targets for new work. Each step ships to production on its own, so the system is never mid-migration for long.

Technologies that are unavailable on current .NET

Some of what these systems use has no equivalent in current .NET, and each item needs a decision. .NET Remoting and AppDomains are not supported; Microsoft recommends pipes, HTTP, or a JSON-RPC library instead. Code access security is gone. System.EnterpriseServices (COM+) is not supported. Windows Workflow Foundation is not supported, with CoreWF as an open-source alternative. Windows Communication Foundation server code can run through the CoreWCF packages. ASP.NET WebForms has no page-model equivalent in ASP.NET Core, so pages and their ViewState are rewritten as Razor Pages, MVC, or a front-end client over an API, usually screen by screen. ASMX services are replaced by web APIs or CoreWCF. For Crystal Reports, GAC-installed assemblies, and COM interop, the inventory records each dependency and the replacement is chosen per item. Some of it is better left on 4.8 in a separate process.

Tooling, and what it does not do

Microsoft's .NET Upgrade Assistant is officially deprecated. The replacement is the GitHub Copilot modernization agent, included with Visual Studio 2026 and Visual Studio 2022 17.14.16 or later, which analyzes projects, produces a migration plan, and commits each change. For web applications, Microsoft's guidance is that moving from ASP.NET Framework to ASP.NET Core is non-trivial for most production apps and that incremental migration, an implementation of the strangler fig pattern, is the preferred approach for large or continuously running systems. A new ASP.NET Core application is placed beside the old one and routes are moved across one at a time. Tools like these are useful for the mechanical edits. They do not recover missing source, decide what to do with Remoting, or confirm that the numbers on a report are the same. Those remain engineering and testing work.

Testing and parity

These applications rarely have automated tests, so the test strategy is built during the upgrade. Characterization tests record what the current system produces for real inputs: calculations, report output, exported files, web service responses, and database writes. The same inputs then run against each upgraded step, and every difference is either a defect to fix or a deliberate change to approve. Reports deserve special attention because layout and rounding differences are easy to miss. Where the system has a database full of business logic in stored procedures, the tests run at that boundary too. For ASMX and Remoting interfaces, capture the real request traffic from callers before changing anything, because the list of callers in documentation is often incomplete. A parallel run of old and new against live inputs, with the old one still authoritative, is the last gate before cutover.

Plain upgrade, or event-sourced re-architecture of one context

A plain upgrade is the right default. It keeps the working behavior, changes the runtime, and finishes sooner. Choose it when the system's problems are mostly the platform: out-of-support runtime, missing build, unavailable libraries. Re-architecture belongs in a narrower case: one bounded context where the business needs the history of what happened and why, where audits or disputes require reconstructing past state, or where reporting load fights the transactional schema. In that context, an event-sourced core with read models can replace the overwritten-in-place records, while the rest of the application stays a conventional upgraded CRUD model. Do not event-source a whole legacy system. Do not do it where nobody asks the questions that history answers. The assessment names the one context, if any, where the extra work is justified, and the other pages cover the two routes.

Event sourcing in an existing .NET system →

When to stay on .NET Framework

Staying put is sometimes correct. Microsoft's documentation says you do not need to migrate .NET Framework apps and that the framework continues to ship with Windows. If an application is on 4.8 or 4.8.1, runs on a supported Windows version, has no pending feature work, and a few people understand it, a move to current .NET may not pay back. In that case the money goes to tests, a build server, dependency cleanup, and dropping anything still on 1.x through 4.6.1. The case for moving is feature work that needs current libraries, a Linux or container deployment, a hiring problem, or components that have lost support. The date to watch for 4.6.2 is January 13, 2027. After the upgrade, support dates for the .NET runtimes themselves matter, and they are covered on the end-of-support page.

.NET end of support dates →

Start with an assessment for a legacy .NET Framework codebase

The read-only assessment inventories the target framework of every project, the Visual Studio and MSBuild versions needed to build it, and whether all source and dependencies are present. It lists every NuGet and hand-referenced assembly with its vendor and support status, the WebForms pages and ViewState use, ASMX, Remoting, WCF, and COM interop surfaces, DataSets and TableAdapters, Enterprise Library blocks, Crystal Reports files, Windows services, ClickOnce deployments, GAC dependencies, configuration, the database and its stored procedures, and existing tests. Nothing is run and nothing in production is touched. The result is a written recommendation: stay and harden, stepwise upgrade, incremental migration, or targeted re-architecture, with an ordered plan. Price and schedule are fixed after the assessment, and its fee is creditable toward the project that follows.

About the assessment →

Deliverables

  • Dependency and source inventory, with every missing item identified
  • Reproducible build from a fresh checkout, in version control
  • Characterization tests that define parity for each upgrade step
  • Stepwise upgrade to .NET Framework 4.8, then to .NET 10, in dependency order
  • Decision per unavailable technology: Remoting, ASMX, WebForms, WF, COM, Crystal Reports
  • Written recommendation on plain upgrade versus event-sourced re-architecture of one bounded context

Common questions

Is .NET Framework 4.6.2 still supported?

Microsoft's lifecycle page lists an end of support date of January 13, 2027 for .NET Framework 4.6.2. Versions 4.7 through 4.8.1 follow the lifecycle of the Windows version they run on, and 4.8 and 4.8.1 are the current releases. Retargeting a 4.6.2 application to 4.8 is normally a small change.

Are .NET Framework 1.1, 2.0, and 3.5 still supported?

Version 1.0 at SP1 ended October 8, 2013, and 1.1 SP1 on Windows Server 2003 ended July 14, 2015. Versions 2.0 and 3.0 ended July 13, 2011. Version 3.5 SP1 is listed through January 2029, as a standalone product on Windows 10 1809 and Server 2019 and later. Support depends on the operating system, so confirm yours.

Should I upgrade to .NET Framework 4.8 or go straight to .NET 10?

For a 4.x application, retargeting to 4.8 is the cheap, low-risk first step and gives a supported baseline. Moving on to .NET 10 depends on how much System.Web, Remoting, and other unavailable technology the code uses. For 1.x and 2.0 code, we recommend getting a reproducible build and tests before choosing.

What do we do about .NET Remoting and ASMX services?

Remoting is not supported on current .NET, so those interfaces are replaced by HTTP APIs, pipes, or a JSON-RPC library. ASMX services are replaced by web APIs or CoreWCF. Before changing either, capture real traffic to learn who the callers are, then run old and new interfaces side by side until callers have moved.

Can we keep the application running while we upgrade it?

Yes. Each step in the path ships on its own, and web applications can be migrated incrementally with a new ASP.NET Core application placed next to the old one and routes moved across one at a time. The old system stays authoritative until a parallel run on live inputs shows matching results.

What if we have lost the source for some assemblies?

The assessment lists every assembly without source. Each is handled by recovering the source from backups or the vendor, decompiling it and rebuilding it under test, replacing it with a maintained library, or isolating it in a separate process on .NET Framework 4.8. Which one applies depends on what the assembly does.

How long will an upgrade take and what will it cost?

It depends on scope: the framework version, how much source and dependency recovery is needed, and how much WebForms, Remoting, and reporting there is. Every engagement starts with a free 1-hour consultation. Price and schedule are fixed after the fixed-scope Legacy Software Assessment, whose fee is creditable toward a later project. Work ranges from a few weeks to several months.

Do we have to rewrite the whole application?

No. A plain upgrade keeps the business logic and replaces the runtime and the unavailable technologies. Re-architecture, such as an event-sourced core, is proposed only for a single bounded context where the business needs its history or where reporting conflicts with the transactional model. Everything else stays a conventional upgraded application.

Sources

Not sure where to start?

Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.