From .NET Framework 4.7 to .NET 8 with Codemod

Most .NET migrations don't fail because the runtime upgrade is impossible.

They fail because the process turns into chaos.

You get dozens of engineers opening massive PRs across multiple repos. Every team structures the migration differently. Reviewers can't tell what's mechanical versus risky. CI breaks constantly. Eventually leadership stops trusting the rollout.

We've seen the opposite happen too.

One engineer starts a Codemod campaign. The migration rolls out through safe, standardized PRs with green CI checks, distinct commits, and predictable diffs that are actually reviewable.

You can see an example here:

Example migration PR with distinct codemod commits

In this demo application, Codemod could fully handle the migration end-to-end.

In real production systems, some parts still require engineering judgment and human oversight. The purpose of this article is to show the migration approach and how Codemod can standardize and automate the repetitive transformation layer safely at scale.

That's the difference between "every team upgrades itself manually" and "the organization runs a controlled transformation."

A .NET Framework 4.7 → .NET 8 migration usually includes the same categories of work repeatedly:

• converting legacy .csproj files
• moving from packages.config to PackageReference
• multitargeting libraries
• replacing framework-only APIs
• modernizing configuration
• moving Web API / OWIN patterns into ASP.NET Core

Most of this work is repetitive and mechanical. And repetitive work creates inconsistent PRs when dozens of engineers do it by hand.

That's where Codemod fits.

Rather than having every team come up with its own migration process, you use a standardized workflow built from a set of smaller, focused codemods. (These Pro codemods are available to enterprise prospects and customers. Contact us for access.)

The recipe chains together nine codemods in sequence:

1. dotnet-sdk-style-netfx Converts legacy .csproj files to SDK-style projects.
2. dotnet-packagereference-migrate Migrates packages.config to PackageReference.
3. dotnet-lib-multitarget-net8 Adds net8.0 to library TargetFrameworks.
4. dotnet-portable-framework-apis Replaces framework-only APIs like HttpUtility → WebUtility.
5. dotnet-efcore-port Scaffolds EF Core DbContext constructor updates.
6. dotnet-aspnetcore-endpoints Ports Web API 2 controllers toward ASP.NET Core.
7. dotnet-owin-host-to-minimalapi Migrates OWIN self-host patterns into ASP.NET Core minimal hosting and WebApplicationFactory.
8. dotnet-appconfig-to-appsettings Converts App.config and Web.config into appsettings.json and removes obsolete .NET Framework config sections.
9. dotnet-net8-cutover Finalizes the migration to <TargetFramework>net8.0</TargetFramework> and removes #if NET8_0 branches.

The sequencing matters.

For example:

• SDK-style projects unlock newer tooling and simplify builds
• multi-targeting reduces migration risk during rollout
• final cutover should happen only after compatibility work is complete

You can run individual codemods when needed, but the recipe gives every repo the same repeatable migration workflow.

It was trust.

Before Codemod:

• bloated PRs
• inconsistent migration patterns
• risky merges
• reviewers exhausted by noisy diffs
• dozens of engineers coordinating manually

After Codemod:

• standardized PRs
• clear commit boundaries
• green CI before review
• predictable changes
• one campaign owner orchestrating the rollout

Reviewers could focus on actual application behavior instead of parsing thousands of mechanical edits.

That's what made the migration scale.

This part matters.

Codemod handles the repetitive transformation layer. It does not magically solve:

• unsupported dependencies
• System.Web assumptions
• deployment redesigns
• authentication changes
• EF behavioral differences
• missing test coverage

Some applications are mostly mechanical migrations.

Others require substantial architectural redesign.

You still need engineers making decisions.

But now those engineers spend time on the hard problems instead of manually rewriting project files for three months.

That's usually the goal.

Small diffs.

Green CI.

Predictable commits.

Standardized workflows.

Clear ownership.

No migration should require heroics from 40 engineers making the same edits in slightly different ways.

The best migrations feel operational, not chaotic.

Codemod helped us get there.