Most established organisations operate at least one system that supports a critical process, was developed by staff who have since left, has limited automated test coverage, and cannot be modified with confidence. These are typically ASP.NET Web Forms applications, occasionally classic ASP with later .NET components.
A parallel rewrite must reach feature parity with a system that continues to change during development, and must be complete before any of it can be used. Incremental migration avoids both constraints.
Applying the strangler fig pattern
A routing layer is placed in front of the existing application, and functionality is migrated behind it one route at a time. The legacy system continues to serve production throughout, and each increment is independently reversible.
Sequencing determines whether the approach succeeds. Beginning with the most problematic module is common and counterproductive, because those modules are usually the most tightly coupled. We begin with a high-traffic, low-coupling route, frequently a read-only view or report. This validates routing, deployment, the authentication bridge and monitoring without exposing data to risk.
The first route validates the infrastructure rather than delivering business value. It should be selected for low blast radius. Business value begins with the second and third increments.
Two problems require design attention
The remainder of the migration is largely mechanical. These two are not.
Shared authentication
Users move between legacy and migrated pages within a single session and must not be required to re-authenticate. Depending on the legacy stack this requires bridging Forms Authentication cookies to claims-based identity, sharing a machine key, or introducing a gateway that issues tokens accepted by both applications. This should be prototyped in the first week, as the chosen approach constrains subsequent decisions.
Shared data during transition
Both applications will read and write the same database for an extended period. This is manageable where ownership of each table is explicitly assigned. Where both must write, writes are routed through a single service. Unmanaged dual-write produces data inconsistencies that typically surface long after the change that caused them.
Database migration governs the timeline
Legacy .NET systems commonly include wide tables, business logic implemented in triggers, and stored procedures that are no longer documented. Neither wholesale replacement nor indefinite deferral is viable.
We introduce views and synonyms as an anti-corruption layer. Migrated code reads from a clean projection while the underlying schema changes incrementally. Logic held in triggers is moved into application services one behaviour at a time, each preceded by a characterisation test that records current behaviour, including defects that downstream systems may depend upon.
Characterisation tests should be written before the existing code is fully understood. They document current behaviour, which is frequently the only specification available.
Expected duration
A line-of-business system of approximately forty screens and a hundred stored procedures typically requires nine to eighteen months of incremental migration alongside continued feature delivery. A rewrite quoted at six months rarely completes within that period, and delivers no usable output until it does.
The principal risk is loss of momentum. At around sixty per cent migrated, the remaining routes are the most complex, the operational pain has largely receded, and attention moves elsewhere. A partially migrated estate carries two deployment paths and two operational models indefinitely. The final forty per cent should be budgeted and scheduled before the first increment begins.