Teaching an AI agent to upgrade .NET, React, and Next.js apps for real — not just talk about it
Every engineering team has that repo. The one running a framework version from three or four years ago. Everyone knows it needs an upgrade. Nobody wants to be the one who breaks production doing it.
That's the problem UpgradePilot — an open-source, multi-agent upgrade pipeline — is built to solve. And this week we shipped the piece that made it stack-agnostic: real, working upgrade automation for .NET, React, and Next.js, including repos that mix a .NET backend with a React or Next.js frontend in the same codebase.
Here's what that actually means, because "AI upgrades your code" is a claim that's earned a lot of well-deserved skepticism.
The design principle: shell out to the real tool, never fake it
The easy version of this feature is an LLM that reads your package.json, guesses at new version numbers, and writes some plausible-looking code changes. That's not what we built.
Every step in UpgradePilot's pipeline calls the actual toolchain:
.NET — real dotnet restore, dotnet build, dotnet list package --outdated, dotnet ef migrations add. Package version bumps are verified by an actual restore, not assumed to work.
React / Next.js — real npm install, npm run build, npm outdated. Codemods run through the actual react-codemod and @next/codemod CLIs — we pulled the real transform names directly from those projects' GitHub repos rather than guessing, because a fabricated transform name just fails at runtime.
Target versions aren't invented. PackageTargetVersions come from dotnet list package --outdated and npm outdated — the same commands you'd run yourself.
Codemod selection isn't invented either. UpgradePilot pulls React's and Next.js's own GitHub release notes, classifies breaking changes, and matches them against a verified catalog of real codemod transforms.
If a step can't do something for real, it says so — with a confidence score and an explanation — instead of pretending.
What's real today, stack by stack
.NET
- NuGet package upgrades across every .csproj in a multi-project solution, not just the first one
- Central Package Management support (Directory.Packages.props) — auto-detected, not assumed
- Target Framework Moniker bumps (net6.0 → net8.0 → net10.0)
- Roslyn-based rename codemods for breaking API changes
- EF Core migration generation, with destructive operations (dropped tables/columns) flagged for review instead of silently applied
- Real dotnet build validation after every change
React
- Real npm install-verified package.json upgrades
- react-codemod integration for known breaking-change patterns (legacy ReactDOM.render → createRoot, PropTypes migrations, deprecated lifecycle renames)
- Jest and Vitest test-summary parsing — real pass/fail/skip counts, not just an exit code
- Real npm run build validation
Next.js
- Everything React gets, plus @next/codemod integration
- Pages Router vs. App Router detection — based on the actual required files each router uses (layout.* vs _app.*), not a guess from folder names
- Build validation that also exercises route compilation, the closest thing to a route smoke test without spinning up a live server
Mixed repos (.NET + React/Next.js in one codebase)
- The backend upgrades and validates first — a frontend calling into backend APIs should be upgrading against an already-working backend, not the reverse
- The frontend half then resolves to React or Next.js automatically and runs through the same real pipeline
- If the frontend can't be confidently identified, that half is explicitly flagged for manual review — never silently skipped, never guessed at
Why this matters more than it sounds like it should
A huge amount of AI coding tooling right now optimizes for demo-ability: something that looks impressive on a green-path example. The failure mode that actually costs teams trust is quieter — a tool that claims success on a real repo but didn't actually verify anything.
Every one of these steps is designed around one question: does this survive contact with a real, imperfect codebase? That's why package bumps are verified by a real restore, why codemods run through the actual official tools instead of hand-rolled regex, and why every gap that isn't solved yet — renaming a method based on a release note, auto-coordinating a genuinely ambiguous mixed repo — is documented in the code as an open limitation, not hidden behind a confident-sounding summary.
It's open source
UpgradePilot is Apache 2.0 licensed, and the agents that run in the free CLI are the same agents that power the hosted product — nothing is held back to make a paid tier look better. If you're maintaining a repo that's overdue for a .NET, React, or Next.js upgrade, the code is here:
github.com/qmmughal/upgradepilot-core
I'd genuinely welcome issues, PRs, and "this codemod catalog is missing X" reports — especially from teams running these upgrades for real. That's exactly the feedback that makes the difference between a tool that looks good in a demo and one you'd actually trust on your own repo.
Top comments (0)