A C# business application can compile, pass its tests and still show customers the wrong thing, because a business rule was never mapped before the screens, tables and APIs were designed.
Consider a request for a customer portal. Customers want to see order status. On inspection, the status they may see depends on credit holds, contract terms, inventory rules and account permissions, and some of those rules exist only in an older application. A C# team that can build the portal but does not find those rules will ship a portal that shows the wrong thing.
The questions a strong team asks early
Listen for questions about the awkward parts. Which system is the source of truth for the customer record? Which users can see pricing exceptions? What happens when an approval is late? Which reports get corrected in Excel before leadership sees them? Where does support look when a customer says the system is wrong?
These questions say more about fit than a list of frameworks. ASP.NET Core, Blazor, SQL Server and background workers are ordinary tools for this work; what distinguishes a team is whether it can find a rule like the credit hold before the data model is fixed. IKRC's .NET development work sits in operational systems, portals and integration layers of this kind.
Should the old application be rewritten?
The older application that everyone complains about may also hold years of pricing rules, customer exceptions and report logic. A partner who proposes replacing it before reading it is proposing to rediscover those rules in production.
Microsoft's own guidance for large ASP.NET Framework applications describes a middle path. Its incremental migration guide recommends a new ASP.NET Core application that proxies to the original through YARP: routes that have been migrated are handled by the new application, and unmatched requests fall back to the old one. Shared class libraries are upgraded only when a migrated route needs them, leaf dependencies first, and the System.Web adapters let a library be called from both applications during the transition. The old system keeps serving the screens nobody has moved yet.
That is not the only option. Sometimes the first step is stabilizing deployment, or adding an API so the new portal can call the old system without copying data through spreadsheets. A rebuild can still be correct. The Legacy Application Modernization Guide covers how to compare old and new behavior before switching.
A characterization test around the credit hold
Ask a candidate how they would expose the old order-status logic through a new portal API without changing what it decides. A good answer starts with tests that pin the current behavior: an account on credit hold is denied the shipped-order detail, an account in good standing sees it, and the edge case the finance team mentions (a hold lifted after the order was placed, for instance) behaves the way it does today. Those tests run against the old code first, then against the API.
The answer to watch for is specific. It names the record, the rule and the test, and it says what happens if a test shows the old behavior is itself wrong: the business decides, and the fix is recorded as a deliberate change to the port.
Related Reading
For the November 10, 2026 end of support for .NET 8 and .NET 9, read What .NET 8 and .NET 9 End of Support Means for Your Business.