How the Intune team moved a .NET Framework service to .NET 8 with Copilot

The Microsoft Intune team used the GitHub Copilot modernization agent to move an enrollment service from .NET Framework 4.7.2 to .NET 8 while hosting it on AKS. The author reports cutting one library's migration from about six weeks to one and a half. The most useful part is the working method: an editable migration plan and progress file kept in the repository, and a clear account of where the agent failed on internal libraries.

Key points

• The service moved from .NET Framework 4.7.2 to .NET 8 and onto AKS, with code and hosting treated as two separate changes.
• Before migrating at scale, check the agent's output against classes you have already migrated by hand.
• Keep migrationplan.md and progress.md in the repository; the agent follows edits you make to them.
• Scope each pull request to one controller, one API path or a small end-to-end scenario.
• For internal libraries the agent could not supply replacements, so record those mappings as a custom skill for the agent.
• At the time of the migration the tool ran in Visual Studio and VS Code; the article says it now also runs in GitHub Copilot CLI, the GitHub Copilot app and GitHub.com.

The Intune enrollment service was still running on .NET Framework 4.7.2. Moving it to AKS also required porting its code to .NET 8. The author used the GitHub Copilot modernization agent in Visual Studio's agent mode and checked its output against a service already migrated by hand before trusting it on new code.

Because the agent did not keep migration state between sessions, the team relied on an editable plan and progress file kept in the repository. Work was split into small pull requests, each scoped to one controller, API path or enrollment flow. One internal library, estimated at six weeks, took about a week and a half. The agent could not supply replacements for Intune-internal libraries, so those mappings remained manual.

Real-world use

• Teams moving an old .NET Framework service or PaaS backend to .NET 8 on AKS.
• Solutions with many internal libraries whose API calls are spread across many files.
• Long migrations that span several sprints and need state kept between working sessions.

Why it matters

Checking the agent against hand-migrated code before a large migration, and keeping an editable plan in the repo, can shorten a .NET Framework to .NET 8 port a lot. Mappings for private internal libraries still need to come from your own team.

Related stories

• Where a .NET 8 repo hides its version before the November 10 end of supportDVDEV Community: #csharpOct 25
• Collection Return Types in C#: Interfaces, Views, and SnapshotsDLNick Cosentino (Dev Leader)2 d ago
• CritterWatch 1.1 groups dead letters by failure cause and acts on each group at onceJXJasperFx (Critter Stack) Blog4 d ago