The Business Case Problem
Modernizing a legacy .NET application is easy to justify to an engineering team and hard to justify to a CFO. "We're on .NET Framework 4.7" does not land the same way as "our infrastructure costs are 3x what they could be." This post is a checklist you can use to identify the signs that modernization is needed, and translate each one into a business-language cost.
Sign 1: You Are Running .NET Framework (Not .NET Core / .NET 5+)
.NET Framework's mainstream support ended in 2019. Microsoft still ships security patches, but no new features, no performance improvements, and no cloud-native capabilities. More practically: .NET Framework is Windows-only. You cannot containerize it, cannot run it on Linux (which is significantly cheaper on Azure and AWS), and cannot take advantage of the performance improvements that .NET 5, 6, 7, and 8 brought to the runtime.
The business cost: you are locked to Windows Server pricing on your VMs, unable to containerize, and your engineers are working with a toolchain that has not received performance investment for five years.
Sign 2: You Are Running on Windows Server 2012 or 2016
Windows Server 2012 reached end of support in October 2023. Running on unsupported operating systems creates compliance exposure (PCI, HIPAA, and SOC 2 all require you to run supported software) and security risk. Windows Server 2016 reaches end of support in January 2027.
If your application requires a specific Windows Server version to run, it is usually because it depends on .NET Framework, IIS, or Windows-specific APIs. Modernizing the application unlocks the ability to run on supported infrastructure.
Sign 3: You Have WCF Services
WCF (Windows Communication Foundation) is not supported in .NET Core or .NET 5+. If your application uses WCF for service communication, those services are tied to .NET Framework. They cannot be containerized, cannot run on Linux, and cannot participate in a modern API-first architecture without migration.
We migrated the UN-DGACM's WCF services to ASP.NET Core REST with zero downtime. The patterns for doing this incrementally are well-established.
Sign 4: No CI/CD Pipeline
If deployment requires an engineer to manually copy files to a server, run a deployment script by hand, or use a deployment wizard in Visual Studio, the risk and time cost of every deployment is higher than it needs to be. Manual deployments are where human error introduces production issues. They also make rollbacks slow and stressful.
The absence of CI/CD is usually a symptom of a codebase that is fragile enough that automation felt risky to set up. That fragility is the underlying problem to address.
Sign 5: Test Coverage Below 20%
Low test coverage means that every change to the application carries unknown risk. Engineers become risk-averse. Features take longer than they should because developers are manually testing edge cases that could be automated. Regressions reach production and take days to diagnose because there is no test suite to run against a new build.
Low coverage is also a consequence of code that was designed to be difficult to test: tight coupling, static methods, direct database access in business logic, and no dependency injection. Modernization that adds test coverage requires restructuring the code to be testable, not just adding tests to the existing structure.
Sign 6: Deployment Takes Hours
A deployment process measured in hours is not a deployment process, it is a manual procedure with known risks at every step. The longer a deployment takes, the less frequently teams deploy, and the larger each release becomes. Larger releases mean more things that can go wrong and harder rollbacks when they do.
Modern .NET deployment pipelines with containers or Azure App Service slots enable deployments in minutes, with blue-green deployment for zero-downtime cutover and automated rollback on health check failure.
Sign 7: Onboarding a New Developer Takes Weeks
If a new engineer cannot make a meaningful contribution in their first week, the codebase has a documentation and structure problem. Undocumented tribal knowledge, complex environment setup, and tightly coupled code that requires understanding everything before you can change anything are modernization problems, not just developer experience problems. They have a direct cost in hiring efficiency and staff retention.
What Modernization Actually Means
Modernization is not a rewrite. The strangler fig pattern, migrating one component at a time while the application continues running, is the right approach for most legacy .NET applications. Start with the components that are blocking the most value: the WCF services that prevent containerization, the tightly coupled authentication that prevents SSO integration, the synchronous processing that is creating performance problems.
FriendsBit has delivered .NET modernization work including a zero-downtime WCF to REST migration for the United Nations and incremental .NET Framework to .NET 8 migrations for enterprise clients. If your application shows these signs and you need to build the business case for modernization, get in touch and we can help you identify the highest-value starting points.