A real .NET Framework app, migrated in the open
The first public sample migration: a working open-source app taken from net48 to net10.0, every commit and the full passing suite out where you can read them.
I'd rather show you than tell you, so this is the long version of the proof on the front page. I took a real, working open-source .NET Framework application — not a toy, not a slide — and moved it onto .NET 10. No client permission required, nothing to take on faith. Every commit is readable and the test suite is green.
The runtime was three years past support, and nobody on the project wanted to be the one to touch it.
Where it started
Fourteen projects, a packages.config graph eighty-six dependencies deep, and a healthy amount of System.Web that the platform no longer ships. The build still ran, which is the trap: working software that can't be deployed to anything supported. Here is the line the assessment drew, before and after.
Characterize first, migrate second
Before a single line moved, I wrote characterization tests that capture what the app actually does today — not what the docs claim, what it does. That suite is the judge for everything that follows. The migration is “done” when it passes green against the new code, and not a moment before.
The mechanical work — project files to SDK-style, packages.config to PackageReference, the rote System.Web to ASP.NET Core transforms — is where the AI earns its place and where the lower price comes from. I review every commit. The model proposes; the tests dispose.
What I'd want you to take from it
Not that the tooling is clever — that the acceptance bar is a test result, not an opinion. That is the whole argument, and it's why “isn't AI migration risky?” has a structural answer rather than a reassuring one. The full writeup and repository link land here alongside this note.
Wondering what your own migration would read like?
Twenty minutes, no pitch. I’ll tell you whether your app is a fit and roughly what the path looks like.