Is GitHub Copilot app modernization free?

The .NET upgrade agent works with every GitHub Copilot plan, including Copilot Free from Visual Studio 2026 version 18.1. It is built into Visual Studio 2026 and Visual Studio 2022 version 17.14.17 or later, and it also runs in VS Code, the Copilot CLI and on GitHub.com. It needs an internet connection and a local Git repository. Larger solutions will use a lot of agent time, so check your plan’s limits.

Can Copilot migrate Web Forms to Blazor automatically?

It has a Web Forms to Blazor Server scenario that converts pages, controls and code-behind into Blazor components and sets up the project. It does not redesign the user interface. Microsoft also ships separate skills for Blazor Server problems such as a null HttpContext, a null Session and lost wizard state, which shows where converted apps tend to break. Plan for review and testing.

Is AWS Transform for .NET free?

AWS lists its managed .NET transformation as free, with up to 50,000 agent minutes a month at no additional charge. Unused minutes do not roll over. It ports .NET Framework applications to cross-platform .NET 8 or .NET 10, aimed at Linux. It supports C# and VB.NET, including MVC, Web API, Web Forms, WCF services and desktop projects. Web Site projects without a project file must be converted first.

What percentage of a .NET migration can AI tools automate?

Vendors quote high numbers. GAPVelocity, which sells a service for finishing stalled migrations, says AI tools convert 85 to 95 percent of a legacy codebase. AWS quotes customers reporting 80 and 90 percent. These measure converted code. The remaining share contains the unusual behaviour, third-party controls and integration edge cases, which is where most of the project risk and calendar time sit.

Do we still need tests if the upgraded solution builds?

Yes. A clean build proves the code compiles against the new framework. It says nothing about whether invoices, permissions or reports behave as they did. AWS itself warns that a project that builds may still have issues. Record the current behaviour with characterisation tests before the tool changes anything, then run them against the upgraded version on real inputs.

Copilot App Modernization for .NET: Where a Rewrite Begins

GitHub Copilot app modernization and AWS Transform for .NET will assess a .NET Framework codebase, write an upgrade plan and carry out much of the mechanical code change, for little or no licence cost. What they leave to you is deciding what the old system is meant to do and proving the new one still does it. You also own the UI and service code with no clean modern equivalent, plus the data migration and cut-over. Use the tools as the production line and put your budget and senior attention on the rest.

I have read the documentation for both, along with Microsoft’s own walkthrough. Below is what each tool does, where it stops, and how I would use them on a real estate.

What does GitHub Copilot app modernization do for .NET?

Naming first, because it keeps changing. Microsoft Learn now calls the .NET part “GitHub Copilot upgrade”, an agent that replaces the .NET Upgrade Assistant, which Microsoft has deprecated. Moving an app onto Azure services is handled by a separate GitHub Copilot modernization agent. The upgrade agent runs in Visual Studio 2026, Visual Studio 2022 version 17.14.17 or later, VS Code, the Copilot CLI and GitHub.com. It works with every Copilot plan, including Copilot Free.

The workflow is sensible. It asks you to create a Git branch, then runs three stages and writes each one to Markdown files under .github/upgrades:

Assessment lists breaking changes, API compatibility problems, deprecated patterns and scope, and asks you to choose a strategy: bottom-up, top-down or all at once.
Planning turns those choices into a plan with dependency paths and risk mitigations.
Execution works through a task list with validation criteria and makes a Git commit for each task, so you can review, cherry-pick or roll back.

It upgrades .NET Framework (any version) to .NET 8 or later, and older .NET Core and .NET versions to .NET 8 or later. It handles C# and Visual Basic across ASP.NET MVC and Web API, Web Forms, WinForms, WPF, Azure Functions, class libraries and test projects. Its built-in skills cover the dull work well: SDK-style project conversion, EF6 and LINQ to SQL to EF Core, OWIN to ASP.NET Core middleware, server-side WCF to CoreWCF, and a YARP proxy for running old and new side by side. There is even a skill that generates behaviour-locking tests before an upgrade.

Microsoft is honest about the limits in its FAQ. The suggestions are not guaranteed to follow best practices. Fixes you make during one upgrade are not remembered for the next. Microsoft’s August 2026 walkthrough, which upgrades a sample forms-over-data app to .NET 10, is blunter. It says the agent “doesn’t upgrade the UX for you”, notes the result looks exactly the same, and warns it may not work the first time.

What does AWS Transform for .NET do, and is it free?

AWS lists its managed .NET transformation as free, with up to 50,000 agent minutes a month at no additional charge. Unused minutes do not carry over. It takes .NET Framework 3.5 and later, .NET Core 3.1 and .NET 5 onwards, and produces .NET 8 or .NET 10. It supports C# and VB.NET, including MVC, Web API, Web Forms, WCF services, ASMX services and WinForms and WPF projects. It validates the result with a local build, runs your unit tests and checks Linux readiness.

Its documented limits are specific. It does not transform Win32 DLLs that lack .NET-compatible libraries, and Web Site projects without a project file must first be converted to Web Application projects. Its Web Forms to Blazor UI porting, described by AWS in December 2025, skips .asmx, .svc and .ashx files, service references and third-party UI control libraries. AWS says you handle those yourself or with an AI code companion, and that a project that builds may still have issues.

Note the direction of travel. AWS Transform aims your app at Linux and can convert Azure service calls to AWS equivalents. Copilot routes cloud work to its Azure agent. Both are useful, and both are also sales channels.

How much of a migration do these tools automate?

The vendor figures are high. GAPVelocity, which sells a service for finishing stalled migrations, says AI migration tools “convert 85–95% of your legacy codebase” and that the remaining 5 to 15 percent is where projects stall for months. AWS quotes customers reporting 90 and 80 percent automation. Treat all of these as vendor views. GAPVelocity earns its money on the remainder, and AWS chose its own case studies.

I find the shape of the claim more useful than the number. The converted share is the regular code. The remainder is where the application does something unusual, and that is exactly where the risk sits. Ten percent of the lines can easily hold most of the calendar time.

Where does the remaining work sit?

Area	What the tool does	What it leaves to you
Assessment	Lists breaking changes, incompatible APIs, deprecated patterns and scope	Deciding which findings matter to the business and which modules to retire
Plan and tasks	Picks an upgrade order, writes tasks with validation criteria, commits each step	Fitting the work around releases, freezes and sign-off
Projects and packages	SDK-style conversion, package references, central package management	Little beyond review
Data access	EF6, EDMX and LINQ to SQL to EF Core	Checking query results and performance against production-sized data
Web Forms	Converts pages, controls and code-behind to Blazor Server	Third-party controls, session and state behaviour, the UX, and whether Blazor Server is the right target
WCF	Converts server-side services to CoreWCF (Copilot)	Clients you do not control, unsupported bindings, and the choice between CoreWCF, gRPC and REST
Desktop	Retargets WinForms and WPF to modern .NET	Any UX redesign. The app stays a Windows desktop app.
Validation	Builds, runs existing tests, can generate baseline tests	Deciding what correct behaviour is, and user acceptance
Data and cut-over	Outside the .NET upgrade scope	Data migration, parallel running, rollback and the switch itself

Web Forms and desktop UI

Converting a Web Forms page to a Blazor Server component is mechanical. The behaviour afterwards needs more care. Blazor Server keeps a live connection per user, and Microsoft ships dedicated skills for the problems that follow: a null HttpContext during the connection, a null Session, threading errors in DbContext, lost wizard or basket state. AWS lists third-party UI control libraries as unsupported, and Copilot’s documentation does not mention them. Whether Blazor Server is even the right destination is a separate decision, which I cover in choosing between Blazor, Razor Pages and React.

WCF and service boundaries

CoreWCF is designed to let existing SOAP clients keep calling the same service, which is often the right first step. It does not decide whether those contracts should survive. Partners’ systems, old desktop clients and message formats you cannot change set the real constraints. See WCF migration options for the trade-offs.

COM, ActiveX and native code

AWS Transform does not transform Win32 DLLs that lack .NET-compatible libraries, and Copilot’s published skill list has nothing for COM or ActiveX. Someone has to find a replacement, wrap the component behind a service, or keep that part on Windows.

Proving behaviour has not changed

Both tools check that the code builds and that existing tests pass. Most legacy applications have few tests, and the tests they have rarely cover the rules that matter, such as rounding, permissions and month-end reports. Copilot’s baseline-test skill helps, but a person still has to decide which current behaviour is correct and which is a bug the business has learned to live with. That is the job of characterisation tests, written before the tool touches anything.

Data, cut-over and the retire-or-rewrite decision

Neither tool’s .NET upgrade moves production data, runs old and new in parallel, or plans a rollback. Microsoft sends database migration to its separate Azure agent, which assumes Azure is the destination. And no tool will tell you that a module nobody has opened in two years should be switched off rather than migrated. Those are judgement calls, and they decide the budget more than any conversion rate.

How should a team use free migration tools?

Treat them as the production line and keep people on quality control:

Run the assessment early. Do it on a branch even if you are not ready to migrate. The assessment file is a free inventory of what will break.
Write characterisation tests first. Cover the flows that earn money or carry legal risk before execution starts.
Let the agent do the mechanical work. Project files, packages, EF, configuration and middleware. Review every commit as you would a junior developer’s pull request.
Go module by module. Use the YARP side-by-side pattern so old and new run together and traffic moves one module at a time.
Teach the tool your fixes. Copilot saves session preferences to its instructions file and reads custom skills from .github/skills. Capture repeated fixes there, because they are not otherwise remembered between upgrades.

When is the tool enough on its own?

For .NET Core or .NET 5 to 9 code moving to .NET 10, often yes. That is a version upgrade, and a capable team can run it with these tools. The same can hold for a well-tested ASP.NET MVC or Web API application on .NET Framework.

Web Forms, WCF, VB6 or COM-heavy applications with thin tests, or data nobody fully understands, are a different job: a rewrite. That is the work my legacy modernisation service is built around. The fixed-price Blueprint migrates one real screen or service with passing characterisation tests, so the remaining work is priced from your own code rather than a guess.

GitHub Copilot App Modernization for .NET: What It Does, and Where a Rewrite Begins