.NET modernization paths

“Modernize the .NET application” names a wish. The applications behind that request are usually one of four shapes, and the shape decides the work. Name the shape before anyone picks a target framework.

This is the branching for a first conversation. How much of the current code you will keep comes after someone has read a transaction.

Name the application you have

Answer these before anyone writes a destination version on a slide:

• Runtime today. VB6, classic ASP, ASP.NET on .NET Framework, WCF, Web API, or a mix that one solution file happens to contain.
• UI today. Web Forms, MVC, an AngularJS client talking to that API, a desktop executable, or a SharePoint page someone still has to open to finish the job.
• Other callers. A nightly job, a partner, a Siebel workflow, a spreadsheet a manager refreshes on Monday.
• System of record. If this application is a window onto something else, rebuilding the window leaves the record where it already lives.

Write the answers down. They are the scope. “Move to a current .NET” is a sentence you earn after them, not before.

Also name who can build it. A solution that compiles only on one developer’s laptop is the first defect to fix.

Four paths that are actually different

Leave it, and put a boundary around it. This is the right path when the application is stable, someone can still run it, and the pain is at the edges: another system needs a contract, or a security review wants a smaller surface. A thin API in front of the behavior others need, a written contract, and a decision not to restyle the interior. That is a project. It is also the honest recommendation more often than a rewrite. Calling the boundary a “phase one of the rewrite” is how the boundary never ships.

Strangle one workflow. Pick one transaction. Implement it beside the old application, on a current runtime, with tests that describe that transaction. Route only that transaction. Leave the rest on the old path until it earns its own project. This fits when a single workflow is the one that hurts — an intake form, a billing handoff, a pricing exception — and the rest of the system is tolerable. It fails when the first release tries to strangle five workflows because they were all on the same whiteboard.

Rehost the UI and keep the rules. Common when the server side is C# a current developer can still read, and the client is AngularJS, Web Forms, or a desktop UI that browsers and security reviews have run out of patience for. Move the screen. Do not rewrite the rules in the same release. Entity Framework mappings, WCF contracts, and Web API controllers are where “while we are here” hides a second project. If the rules are the part nobody understands, you are not in this path. You are in a reading project, and the UI can wait.

Bridge, then retire. VB6 and other desktop code that still posts into the business — a counter, a shop-floor tool, a buyer’s application — often cannot be rewritten in one cut. A bridge that lets the new application and the old executable share the same records is the path. The bridge is temporary on purpose. Name the date you will look again at what is still on the old side. Without that date the bridge becomes the system, and the next team inherits two.

A .NET service that sits beside Siebel — an interface, a document step, a sync — follows the same branching. Do not fold it into a Siebel upgrade weekend unless that service is on the Monday path and one person owns both sides. An upgrade window is a bad place to discover that a WCF contract and a Siebel workflow disagree about a status.

What to look at before estimating

• The project that is the real entry point. Large solutions collect unused class libraries. Pretending every project is in scope is how an estimate collapses in week two.
• One vertical of data: the tables or services that one transaction touches, including the stored procedure nobody listed because “Entity Framework handles it.”
• How identity works today. Windows auth, forms auth, a header a reverse proxy injects, or a service account shared with a job. A new UI on an unexplained identity story is a production incident with a nicer stylesheet.
• What “done” means for the first release. One workflow in production, used by the people who do that job, with the old path still available if you said it would be. Adoption slides are not that definition.

What the first deliverable is

The first deliverable is a named path through the code you have. If the code is the system of record and nobody can walk a transaction, the first work is reading it with the person who will own it afterward.

.NET application consulting here is one of those four paths, written down, with a handoff. A standing team to tend every internal app is a different firm.

When the build still depends on one machine, repeatable environment builds and deploys belong on the path: Ansible, Terraform, GitHub Actions or GitLab CI. That is build automation, kept inside the application project.