.NET Modernization

Modernize your legacy .NET Framework applications to .NET 10, .NET 9, or .NET 8, without the body-shop tradeoff. Senior engineers, fixed-scope projects, no offshoring. Web Forms, VB.NET, WCF, and Entity Framework 6 specialists working from Scottsdale, Arizona.

Why .NET Framework Migration Cannot Wait

Microsoft moved the entire .NET Framework line into long-term maintenance starting with .NET 4.8. New CVEs are still patched as part of Windows servicing, but the platform receives no new features, no performance work, and no first-party tooling investment. Every direction the .NET ecosystem has taken since 2020 (cross-platform deployment, container-native hosting, AI integration, agentic frameworks, modern dependency injection) has been built on the side of the line that does not include .NET Framework.

The practical effect is that staying on .NET Framework gets more expensive each quarter. Specialist engineers who understand Web Forms postback semantics or WCF custom bindings retire faster than they are replaced. Cloud providers optimize their pricing around modern .NET workloads. New libraries target .NET 8 as the minimum baseline. What was a stable platform in 2018 has, by 2026, become a slow-motion technical debt accrual.

.NET Framework End-of-Life Timeline

Microsoft does not publish a hard end-of-life date for .NET Framework 4.8: it is supported as a Windows component for the lifetime of the supported Windows versions it ships with. That language reads reassuring but obscures the real timeline:

• .NET Framework 4.5.1, 4.5.2, 4.6, 4.6.1: already past end-of-support. Applications still running on these versions are receiving no security patches.
• .NET Framework 4.6.2 through 4.7.2: supported only as part of underlying Windows versions; no independent service track.
• .NET Framework 4.8 / 4.8.1: current. Maintenance only. No new features expected ever.
• Windows Server 2012 / 2012 R2: host operating system for many legacy .NET deployments. End-of-life October 2023. Extended Security Updates available through October 2026 only.
• Internet Information Services 7.x and 8.x: paired with the Windows Server versions above and inheriting the same EOL clock.

The Cost of Not Modernizing

Three concrete pressures show up on enterprises that delay migration. First, security audit failures: SOC 2, HIPAA, and PCI assessments increasingly flag unsupported framework versions as a finding, even when CVEs are patched at the OS layer. Second, hiring costs: developers entering the workforce in 2026 do not learn Web Forms, classic ASP, or COM interop. Specialist talent commands premium rates and is harder to retain. Third, capability gaps: cloud-native architecture patterns, AI integration libraries, and modern observability stacks treat .NET 8 as a minimum. Each new business requirement that touches one of these areas becomes a custom workaround instead of a configuration change.

Migration Approaches: Lift-Shift, Strangler Fig, or Rewrite

Three viable migration shapes, chosen based on the size of the application, the depth of architectural debt, and the business risk tolerance.

• Lift-shift: port the existing application to modern .NET with minimal architectural changes. Fastest path; preserves existing patterns; lowest improvement on performance and maintainability. Good for applications with sound architecture but stuck on an old framework version.
• Strangler fig: replace the application incrementally, one bounded context at a time, while the legacy system stays online. Lowest risk because each phase is independently shippable and reversible. This is our recommended default for medium-to-large applications.
• Full rewrite: appropriate only when the architecture itself is the problem (e.g., a monolithic Web Forms application that needs to become a microservices platform). Highest risk; longest timeline; requires the strongest justification.

The Migration Path: What Moves From .NET Framework 4.x to .NET 10

Whatever shape the project takes, the road runs in the same order. Each stage has to land before the next one is safe, which is why an honest estimate follows the sequence rather than quoting the whole application at once:

1. Project system: verbose .csproj and .vbproj files plus packages.config become SDK-style projects with PackageReference. This goes first because it immediately surfaces every dependency that has no modern equivalent, which is the single biggest source of surprise later.
2. Shared libraries: class libraries retarget to .NET Standard 2.0 where they have to serve both runtimes during the transition, then move to the current target once the last Framework consumer is gone.
3. Configuration: web.config and ConfigurationManager give way to appsettings.json and IConfiguration, with environment-specific overrides and secrets moved out of the file entirely.
4. Data access: Entity Framework 6 becomes EF Core; hand-written ADO.NET either stays or moves to Dapper. This stage gets the most test coverage because EF Core translates some LINQ differently than EF6 and can change results quietly rather than failing loudly.
5. Hosting and startup: Global.asax and the System.Web pipeline become Program.cs, middleware, and the built-in dependency injection container. HttpContext.Current becomes an injected IHttpContextAccessor.
6. Web layer: Web Forms moves to Blazor or Razor Pages, ASP.NET MVC 5 to ASP.NET Core MVC, and WCF endpoints to minimal APIs, controllers, or gRPC depending on what the consumers need.
7. Identity: FormsAuthentication and OWIN give way to ASP.NET Core Identity, JWT-based schemes, or OpenID Connect against the identity provider you already run.
8. Deployment: IIS-bound publishing becomes a self-contained build that runs in a container or on Linux. Staying on IIS is a valid choice too, and moving the host is a separate decision from moving the runtime.

Two things do not move on their own and need naming in the plan: COM interop and other unmanaged dependencies, which block cross-platform deployment until they are replaced or isolated behind a service, and any third-party component whose vendor never shipped a modern build. Both are found in the assessment, not halfway through the migration.

AI-Readiness: What Modern .NET Unlocks

The most-asked modernization question in 2026 is not about performance or hosting cost: it is about AI integration. Modern .NET unlocks a set of capabilities that .NET Framework cannot meaningfully access:

• Native AI SDKs: Azure OpenAI client libraries, Anthropic and OpenAI SDKs, vector database clients, and embedding pipelines target .NET 8 as a minimum. On .NET Framework, AI integration requires HTTP-only access without the safety, retry, and tooling provided by the official libraries.
• Semantic Kernel and agentic frameworks: Microsoft's orchestration framework for multi-step AI workflows is .NET 8+. Agentic patterns that combine LLM reasoning with tool use, structured outputs, and human-in-the-loop approvals all assume modern .NET runtime semantics.
• Modern ML.NET, ONNX, and embedding models: running embedding generation, classification, or local inference inside the application is supported on .NET 8+; on Framework these workflows require an out-of-process service.
• AI-assisted development workflow: Copilot integrations, AI-driven test generation, and modern refactoring tools are first-class on .NET 8+. On Framework these tools work less reliably or not at all because the project format and language features predate them.

The pattern is consistent: AI integration on .NET Framework is possible but expensive, while on modern .NET it becomes a configuration concern. For most enterprises planning AI-augmented features in their existing applications, the modernization project is a prerequisite, not a parallel track.

Legacy Patterns We Specialize In

We have hands-on production experience with every major legacy .NET pattern. The mapping below shows the source pattern and the modern equivalent we typically migrate to:

• ASP.NET Web Forms with postback lifecycle and ViewState: converted to Blazor Server, Blazor United, or Razor Pages depending on interactivity requirements.
• VB.NET codebases: converted to modern C# with proper async/await, nullable reference types, pattern matching, and idiomatic dependency injection.
• WCF services with custom bindings, message contracts, and SOAP: replaced with ASP.NET Core minimal APIs, controllers, or gRPC endpoints depending on consumer requirements.
• Entity Framework 6 with database-first scaffolding: migrated to EF Core 9 with code-first migrations, modern DbContext patterns, and updated query translation behavior.
• Windows Services built on ServiceBase: migrated to BackgroundService and IHostedService for container-friendly deployment with health checks and graceful shutdown.
• ASP.NET MVC 5 with Unity DI: modernized to ASP.NET Core MVC with the built-in DI container, options pattern, and modern middleware pipeline.
• Classic ADO.NET with manual SqlConnection management: replaced with EF Core or Dapper depending on whether the codebase wants ORM ergonomics or direct SQL control.
• FormsAuthentication / OWIN authentication: replaced with ASP.NET Core Identity, JWT-based authentication, or OpenID Connect integration with modern identity providers.

The .NET Upgrade Tooling Stack

Modernization is not a manual rewrite. We use the official Microsoft tooling combined with custom analyzers and scripts developed across past projects. The .NET Upgrade Assistant handles the mechanical conversion of project files, package references, and routine API changes. Roslyn analyzers identify deprecated patterns at compile time and propose modernization fixes. The API Compatibility tools surface platform-incompatible calls before runtime. We supplement these with custom Roslyn rules tuned to the specific legacy patterns most common in enterprise codebases: code that the official tooling marks as "needs review" but that we can usually convert deterministically because we have seen the pattern many times before.

What Gets Modernized: Component-by-Component

A complete modernization touches every layer. Project files convert from verbose .csproj XML to the modern SDK-style format. Package references migrate from packages.config to PackageReference with updated, vetted NuGet packages. Deprecated APIs are replaced systematically: System.Web becomes ASP.NET Core middleware; ConfigurationManager becomes IConfiguration with appsettings.json; Global.asax becomes Program.cs with the modern minimal hosting model; HttpContext.Current becomes injected IHttpContextAccessor. Authentication moves from FormsAuthentication or OWIN to ASP.NET Core Identity or JWT-based schemes. Entity Framework upgrades to EF Core with the updated DbContext lifecycle and query translation differences accounted for. Serialization moves from Newtonsoft.Json to System.Text.Json where compatible. Deployment changes from IIS-dependent publishing to self-contained executables that run in Docker containers, on Linux, or in serverless hosts.

Our Migration Process

Every migration follows the same six-phase shape, scoped to the size of the application:

1. Assessment: audit the existing codebase, identify framework dependencies and third-party libraries, map deprecated APIs, estimate migration complexity and effort for each component, and produce a written report with the recommended migration shape (lift-shift, strangler fig, or rewrite).
2. Planning: create the phased migration roadmap. Each phase has explicit entry and exit criteria, tested rollback procedures, and a defined risk profile. Business priorities and dependency order determine the sequence; risk minimization sets the pace.
3. Incremental migration: execute phase by phase. Shared libraries first, then data access, then business logic, then the web layer. Each component is independently testable and deployable. The application stays running and revenue-generating throughout.
4. Testing: automated regression testing at each phase boundary. Performance benchmarking against the original application. User acceptance testing with stakeholders before each production cutover. We do not gate on subjective sign-off when an objective benchmark is available.
5. Deployment: parallel deployment with controlled traffic shifting, monitoring for regressions in real time, and documented rollback procedures at every stage. Blue-green and canary patterns are used where the application architecture supports them.
6. Training and knowledge transfer: your in-house team learns the modern .NET patterns, the updated development workflows, and the CI/CD pipeline. The goal is that AgaveIS becomes optional after the migration completes, not a permanent dependency.

What It Costs and How Long It Takes

No one can price a migration from a web page, and any firm that quotes you before reading the code is guessing with your budget. What we can give you up front is the shape of the engagement, so you know exactly what you are buying at each step:

• Initial consultation, free: a conversation about the application, the stack it runs on, and what is forcing the move now. No cost and no commitment.
• Assessment, paid: we read the codebase, inventory every dependency, map the deprecated APIs, and hand back a written report with the recommended migration shape and the phase plan. The report is yours whether or not you continue with us.
• Migration, fixed scope and fixed fee: the assessment produces one number and one timeline. Hourly billing rewards a longer project; a fixed fee rewards finishing.
• Phased delivery: you get a running, deployable application at every phase boundary, so the value arrives during the project rather than only at the end.

What actually moves the number: the size of the codebase, third-party and COM dependencies with no modern equivalent, how much automated test coverage already exists, how far the architecture has drifted from anything the framework supports, and whether the database moves alongside the application. Test coverage is the biggest single swing factor. A codebase with real tests can be migrated aggressively; a codebase without them has to be migrated carefully, and careful takes longer.

For duration, the honest range is wide on purpose. A small Web Forms application with straightforward data access finishes in weeks. A large enterprise system with WCF services, COM interop, and tightly coupled architecture runs to months. The assessment turns that range into a date. Teams outside the United States usually write it as .NET modernisation rather than modernization, and we work with them on the same terms; the spelling changes, the engagement does not.

Why AgaveIS: Senior Engineers, No Body Shop

The market for .NET modernization services in 2026 is dominated by two patterns: large consultancies that bill hourly through tiered staffing models, and offshore body shops that quote aggressively low rates. AgaveIS is structurally different on every dimension that matters for a migration project:

• Senior-only engineering: every line of migration code is written by an engineer with deep production experience on the source pattern. We do not assign juniors to billable hours, we do not subcontract, we do not offshore. The engineer who scopes the project writes the code.
• Founder-led, 30 years on the Microsoft stack: Jason has been writing .NET since the framework was in beta. The legacy patterns we modernize are patterns we built with for a decade or more. That makes pitfalls obvious and migration paths fast.
• Fixed-scope, fixed-fee projects: the assessment phase produces a written quote with a fixed timeline and a fixed cost. Hourly billing aligns the consultant's incentive with project duration; fixed scope aligns it with completion.
• Local presence in Scottsdale, Arizona: in-person meetings, on-site code reviews, and direct accountability when needed. Distributed work for the implementation phase, in-person for the moments that benefit from it.
• No subcontracting clauses: the work stays inside AgaveIS. Code reviews happen between named senior engineers. Architectural decisions get debated, not handed to a separate team for execution.

Modernization Risk Inventory

Every migration carries risk. Honest practice means naming the risks before scoping the work. The most common are: behavioral drift in EF Core query translation versus EF6, where SQL that worked correctly under EF6 produces different results under EF Core; ViewState dependencies in Web Forms that hide complex state-machine logic in the framework rather than the application code; WCF custom bindings that have no direct ASP.NET Core analog and require manual translation; COM interop and unmanaged code dependencies that block cross-platform deployment; date and time handling differences across runtime versions; and integration tests that depend on legacy hosting behavior. We mitigate each of these through specific tooling and process choices documented at the assessment phase. Rollback procedures are written before deployment, not after. Parallel environments stay online throughout the migration so any unexpected issue triggers a revert, not a downtime incident.

Frequently Asked Questions