Legacy .NET + SQL Server Modernization: 2026 Decision Tree

Every CTO has at least one system that a few engineers quietly maintain, that runs something important, and that was written in a stack no one on the team still loves. The 2026 modernization conversation is better than previous years,.NET 10 LTS is stable, SQL Server 2025 is shipping, and Azure Arc makes hybrid plausible. But "modernize everything" is still the wrong answer. Here is a decision tree that makes the conversation concrete.

Five Outcomes, Not Two

The common framing, "rewrite vs leave alone". Is a false dichotomy. Legacy systems fall into one of five outcomes:

Refactor in place. Upgrade runtime (.NET Framework to.NET 10), refactor hotspots, leave architecture intact. Lowest risk, modest upside.
Wrap behind an API. Keep the legacy behind a modern façade. Useful when the system works but you need modern clients to talk to it without touching its internals.
Strangler-fig replace. Route specific capabilities to a new service, shrink the legacy over time. The default choice for systems with active roadmap pressure.
Full rewrite. Only when every capability needs change and the domain model itself is broken. High cost, high risk. And often the wrong answer even when it feels right.
Archive. The outcome teams talk themselves out of most often. If the business value is shrinking faster than the maintenance cost, freeze it, document it, and spend the budget elsewhere.

The Decision Tree

Apply these questions in order. The first "yes" wins.

Is the business value declining? → Archive. Reallocate the maintenance budget.
Is the roadmap pressure zero? → Refactor in place. Get on supported runtime, fix security hotspots, stop there.
Do modern clients need to integrate but internals are fine? → Wrap behind an API. Extract contracts; leave the core.
Are a few capabilities under active pressure but the rest stable? → Strangler-fig replace. Peel off the pressured parts; leave the rest.
Is the domain model itself wrong and every capability is under pressure? → Rewrite. Accept the cost; plan for 18–24 months

Database First, App Second

The dirty secret of most legacy.NET applications is that the real legacy is the database schema. The app can be rewritten in a quarter; the schema has thirty years of accreted business logic in stored procedures. Modernize the database layer with expand-contract migrations so both old and new applications can run against it simultaneously.

-- Phase 1: EXPAND — add new shape alongside old
ALTER TABLE Customers ADD CONTRACT_NUMBER NVARCHAR(64) NULL;
-- Backfill asynchronously; old code is unaffected.

-- Phase 2: MIGRATE — dual-write from the app
-- New app writes CONTRACT_NUMBER + legacy CUSTOMER_ID;
-- legacy app still writes CUSTOMER_ID only.

-- Phase 3: CONTRACT — once all reads migrated
ALTER TABLE Customers ALTER COLUMN CONTRACT_NUMBER NVARCHAR(64) NOT NULL;
DROP INDEX IX_Customers_CustomerId ON Customers;
-- Legacy reads have been switched over. Safe to remove old column next release.

The Strangler-Fig Pattern in 2026

A strangler-fig migration routes traffic through an intermediary. New capabilities are implemented in the modern service; old capabilities pass through to the legacy. Over time, you move routes across until the legacy handles nothing. YARP and Azure Front Door both work; pick whichever fits your deploy story.

// YARP routing — new capability handled by modern service
{
  "Routes": {
    "modern-customer-create": {
      "ClusterId": "modern",
      "Match": { "Path": "/api/customers", "Methods": ["POST"] }
    },
    "legacy-fallback": {
      "ClusterId": "legacy",
      "Match": { "Path": "/api/{**catch-all}" }
    }
  }
}

Observability Is the Migration's Safety Net

Instrument both systems with the same trace IDs before starting the migration. When a regression shows up, you need to know whether it is the legacy or the new service at fault, and at what exact boundary. OpenTelemetry with Application Insights is the Azure-native choice; export to a vendor-agnostic backend if you have any chance of leaving Azure later.

Rollback Realism

"We can always roll back" is the lie teams tell themselves at the start of a modernization. Rollback is only real if you have: versioned schema with both shapes live, feature flags scoped at the route level, and data-reconciliation jobs that can reconcile a split-brain state. Do the work to make rollback real before the first cut-over, or accept that you are doing a one-way migration.

The Timeline Nobody Wants to Hear

For a non-trivial legacy system. Roughly 500k LOC, 20+ stored procedures of real business logic, moderate roadmap pressure. Strangler-fig migrations realistically take 12–18 months with two small teams working in parallel. A full rewrite takes 24–36 months and fails more often than it ships. The realistic timeline is what separates modernization programs that complete from ones that die in a renamed repo two years later.

Legacy .NET and SQL Server in 2026: Modernization Decision Tree