Modernization

Keep shipping while old and new .NET applications coexist

Moving the first feature creates a second responsibility: operating two applications while the product continues to change. Make ownership, shared-state rules and the end of temporary support part of the delivery plan.

Updated October 5, 2026 · AI disclosure

A customer needs an urgent fix, a new screen writes data the old application reads, and nobody is sure which release must go first.

The team needs room for:

Planned enhancements and urgent production fixes
Clear ownership of each feature and its data
Compatible releases across both applications
Support capacity until old dependencies are removed

Microsoft's incremental approach puts an ASP.NET Core application alongside the existing ASP.NET application on .NET Framework, using YARP (Yet Another Reverse Proxy) to forward requests to it. It also identifies shared concerns such as authentication, session, caching and monitoring. Those connections become ongoing delivery responsibilities. Incremental migration setup

Give each feature a current owner

Maintain a short ownership record for every feature being moved. This illustrative dispatch-list record makes the responsibilities concrete:

Serving implementation: Core for the pilot warehouse; Framework elsewhere
Authoritative writer: existing dispatch service, called by both applications
Incident owner: named on-call lead; release engineer operates authorized routing changes
Recovery limit: return traffic only while Framework can read current data; reconcile completed dispatch actions separately
Retirement evidence: no legacy list callers and agreed production criteria met. Keep the old host until its writer and bridges are also replaced

Route ownership and data ownership are separate decisions. A modern screen can still rely on legacy code to update a business fact. Choose one authoritative write path for that fact and make other callers use it until a deliberate ownership transfer is ready.

The feature migration guide explains conditional routing and staged exposure. The ownership record keeps that arrangement understandable as releases accumulate.

Decide where the next change belongs

Suppose an urgent fix changes which orders appear on the dispatch list. If some users still receive the Framework version, shipping the fix only in Core leaves inconsistent business behavior.

At intake, identify every implementation that must support the revised rule. Update the acceptance scenarios, then deliver the change to those implementations. Include Framework when it remains an agreed recovery destination and must still serve that behavior.

A Core-only enhancement may be reasonable once its affected customers no longer depend on Framework. If returning them to Framework would remove the enhancement, make that tradeoff explicit before release. Product owners decide whether to delay the enhancement, support it temporarily in both versions or end that recovery option.

Reserve capacity for this overlap. Track duplicate changes and compatibility work against the migration budget; an expanding backlog is a reason to reduce concurrent migrations or revisit the retirement plan.

Let the data contract determine release order

Separate deployments do not make shared data independent. Microsoft notes that applications sharing a schema must coordinate changes that affect their readers and writers. Shared-data coupling

Consider an illustrative DispatchNote field added by the modern application:

Introduce storage that preserves existing records and accepts the old application's writes.
Deploy readers that tolerate missing notes. Check that legacy updates preserve notes they do not understand.
Enable the modern writer after those compatibility checks pass.
Remove old representations or impose stricter requirements only after their remaining consumers retire.

An additive column alone does not prove compatibility. Stored procedures, positional mappings, exports and batch jobs may make assumptions the screen does not reveal. Test the supported combinations of old and new application versions against the schema that will actually be deployed.

A routing change cannot reverse saved notes, sent messages or completed dispatch actions. Keep data repair and reconciliation steps in the release plan where needed. Microsoft's deployment guidance explicitly calls out the complexity of reversing stateful changes. Stateful deployment recovery

Make temporary bridges visible to support

Shared session deserves its own decision. ASP.NET on .NET Framework and ASP.NET Core have different serialization and locking behavior. Remote app session can bridge them through a Framework endpoint, which leaves the old application on that feature's request path. Record who operates the endpoint and what happens when it is unavailable. Session migration choices

Apply the same discipline to authentication, shared caches and scheduled jobs. Record implementation and release identifiers in diagnostic evidence so support can identify which path failed. Rehearse recovery with the versions, configuration and stored data that will coexist, including the effect of work already running.

Finish the overlap deliberately

Review the ownership record before starting another feature. Check users, scheduled jobs, reports and other callers. Agree a representative production observation period and distinguish retiring one feature from retiring the host it still depends on.

The business owner approves the end of legacy support and its recovery window. Then remove the old implementation and unnecessary routes, flags, jobs and bridges. Keep required records and data under their retention rules.

The useful measure of progress is a feature that can now change with fewer dependencies and one supported implementation. Count the temporary responsibilities removed alongside the features moved.