.NET Framework applications age in a particular way, and the specifics matter more than generic modernization advice does.
We have been building on C# and .NET since long before the split, which means we have worked on both sides of it: the Framework applications that still run businesses, and the modern .NET systems they need to become.
What usually needs to move
.NET Framework to modern .NET. Framework 4.8 is the end of that line. It is still supported, but it is not getting anything new, and the ecosystem has moved. Most of the difficulty is not the language, it is the dependencies that assumed Framework only.
Web Forms. There is no migration path, because there is no Web Forms in modern .NET. Web Forms applications have to be re-expressed, usually as MVC or Razor Pages, sometimes Blazor where the interaction model genuinely suits it. The postback and ViewState model does not translate, so this is a rewrite of the presentation layer even when the business logic survives intact.
WCF. Also absent from modern .NET. Services move to ASP.NET Core, typically as REST or gRPC. Where external consumers depend on the existing SOAP contract, CoreWCF can hold the interface steady while everything behind it changes.
System.Web dependencies. HttpContext.Current and the static access patterns around
it are pervasive in older codebases and have no modern equivalent. Untangling them is
usually the single largest mechanical task in the migration.
Configuration and hosting. web.config gives way to the modern configuration and
dependency injection model. Applications hosted in IIS can stay in IIS, which matters
when the hosting arrangement is not something you want to change at the same time.
How we sequence it
The order below exists because each step de-risks the next.
- Upgrade in place first. Move to the latest Framework version, bring packages up to date, and get the build reproducible before changing anything structural.
- Extract what is portable. Business logic, domain models and data access usually move to .NET Standard or modern .NET with far less friction than the surrounding plumbing. Getting them out early shrinks what is left.
- Replace the seams. Configuration, dependency injection, logging and the
System.Webdependencies, so the remaining code stops assuming Framework. - Re-express the presentation layer. Web Forms and WCF, the parts with no direct path, done last when everything underneath is already modern and tested.
Throughout, a routing layer sits in front so migrated capability goes live in slices rather than all at once, and any slice can be routed back if it misbehaves.
Where the surprises usually are
Third-party dependencies. A Framework-only component with no modern equivalent, and no source, is a genuine blocker. Finding these belongs in week one of the assessment, not in month six of the migration.
Behaviour that was never specified. Framework defaults around culture, date parsing, string comparison and serialisation changed in modern .NET. Code that relied on the old defaults without saying so will behave differently, quietly, and usually in the direction of subtly wrong data rather than an exception.
Tests that do not exist. Older codebases frequently have little automated coverage, and the migration is exactly when you need it. We add characterisation tests around the parts being moved: not to prove the code is right, but to prove the new behaviour matches the old.
What we would ask you first
Which Framework version you are on, whether Web Forms or WCF are involved, what your third-party dependencies are, whether you must stay on IIS, and what your appetite is for running both versions side by side for a period. That last answer shapes the sequencing more than any of the technical ones.