Choose the first .NET feature worth moving

Name the result before choosing the code

Choose a business action, such as finding a shipment's latest recorded status. “Move the controllers” describes implementation work but does not establish what a user will gain.

Define the action's beginning and end, its users, permissions, data and exceptions. Microsoft's domain-analysis guidance organizes boundaries around business capabilities and examines their dependencies. That principle is useful here even when the destination remains one ASP.NET Core application rather than microservices. Business capabilities and boundaries

Then ask why migration is needed. If a small change in the existing application delivers the same result, compare that option. A move can still be justified by a blocked roadmap item or an expiring dependency, but name that constraint and its evidence separately from the proposed feature improvement.

Compare candidates against the actual constraint

Consider this hypothetical distributor. Staff switch between two screens to answer shipment questions. Product wants a clearer status view, while engineering must keep delivering already-committed changes.

Three candidates emerge:

• Shipment-status lookup: a frequent support task with an observable result. It reads recorded shipment events but still needs customer authorization and agreed freshness.
• Delivery-address changes: useful to customers, but writes shared order data and interacts with warehouse cutoffs and carrier notifications.
• Pricing calculation: central to sales, but depends on discounts, contract rules and order creation. A small coding estimate would not cover that business boundary.

For these stated constraints, investigate shipment lookup first. Its dependency boundary appears narrower and its benefit is easier to check. That is a provisional choice: a hard deadline affecting address changes could reverse it.

Use three gates before scoring preferences: can the team reach the relevant dependencies, verify the business result and support coexistence within the available capacity? A candidate failing a gate needs preparatory work or a different boundary. A high value score does not remove an inaccessible dependency.

Put a defensible scale on the payoff

Continue the example with explicit assumptions: 600 eligible lookups per week and a proposed reduction of 40 seconds of active handling per lookup. The arithmetic is 600 × 40 ÷ 3,600, or roughly 6.7 staff-hours a week.

This is an estimate to validate, not an observed saving or a promise of lower payroll. Measure the existing task, distinguish active effort from unattended waiting, and check how often the proposed view removes the extra work.

Compare the benefit with the full investment: implementation, shared infrastructure, acceptance tests, rollout, temporary support and retirement. If the assumptions fall to 150 eligible lookups and 15 seconds saved, the estimate becomes about 0.6 hours weekly. That sensitivity may make a smaller legacy improvement the better first purchase.

The business owner decides whether the benefit, strategic constraint or learning value warrants the cost. Avoid hiding an uncertain estimate inside a precise-looking ranking.

Inspect the boundary before committing the build

Trace the shipment lookup beyond its URL. Does it read a stable record, reconstruct state from session, call a carrier on every request or invoke a library tied to System.Web? Who can change each dependency, and what would that work displace?

Microsoft's migration guidance recommends addressing the libraries required by the selected routes rather than upgrading every supporting library at once. It also identifies cross-cutting concerns that must be considered early. Use that dependency check to turn the apparent feature size into a credible delivery scope. Incremental dependency planning

For this example, a bounded proposal might include authorized lookup of recorded shipment events and the last-updated time. Carrier polling and address changes remain outside it. If customers require live carrier status, however, excluding that dependency would also exclude the promised value. Change the scope or choose another candidate.

Approve one decision-sized commitment

Turn the comparison into a decision record. For the hypothetical example above:

• Candidate and result: shipment lookup; remove avoidable screen switching
• Constraint: protect already-committed delivery work
• Dependency uncertainty: establish whether recorded events meet freshness needs or live carrier access is required
• Cost range: not yet established. Engineering must provide a low/high estimate including tests, rollout and temporary support
• Decision: proceed with a bounded dependency and effort assessment; defer build approval until freshness and cost are acceptable

The business owner approves the budget limit, review date, acceptance evidence and eventual legacy retirement. Once the feature earns a build decision, use the feature migration guide for implementation, testing and controlled release. Let the first feature's evidence shape the next investment.