Move the application forward.
Account for the work it already does.

What is the reason for moving?

A migration may be prompted by a hosting change, a dependency that can no longer be maintained, difficulty releasing updates or a requirement the existing design cannot accommodate. Establishing that reason helps decide which work belongs in the first phase.

Moving runtime, redesigning the interface and changing business processes are different tasks. Combining them all can make it difficult to tell whether an unexpected result comes from the migration or a new requirement. We separate those decisions in the scope.

Older .NET is not one uniform starting point.

A move between modern .NET versions differs from moving an ASP.NET Framework application to ASP.NET Core. Web-specific dependencies, authentication, session behaviour and third-party controls may need changes rather than a simple project-setting update.

We review the actual project before selecting a target. Runtime support, hosting compatibility and required components are checked at that point rather than relying on a version number in a marketing page.

Technical background: Microsoft’s ASP.NET Framework-to-Core migration guidance.

A dependency and workflow picture

Record application components, database connections, scheduled tasks, file storage and external integrations. Identify the tasks staff and customers rely on, including less frequent work such as year-end reports or data exports.

Review the parts tied to the current framework: request handling, session, identity, configuration and third-party libraries. For a CMS, include content types, publishing behaviour and media rather than comparing the public pages alone.

An agreed route with open questions

Set out the proposed target, work boundaries, dependencies and acceptance criteria. Identify unknowns that need a small technical trial before an estimate can be reliable.

The scope should explain what stays, what changes and what is excluded. Record responsibility for hosting, licences and any systems outside our control. List each unresolved dependency alongside the check needed to resolve it, so that the estimate has a stated basis.

DATA AND BUSINESS BEHAVIOUR

A page loading is only one check.

Use representative records and agreed examples to compare the old and proposed application. Check calculations, statuses, permissions, searches, exports and scheduled processing where they fall within the scope.

For a data move, define how records and relationships are mapped and reconciled. Totals and record counts can be useful checks, but they do not by themselves prove that every field and business rule has been preserved. Access to production data should be limited to the agreed purpose and environment.

ILLUSTRATIVE PLANNING EXAMPLE

A booking system has more than a booking page.

A sample migration brief might include date handling, prices, cancellation states, email notifications and an administration report. A release checklist needs examples for each agreed workflow, including unsuccessful or incomplete requests.

This is an illustration of how to scope testing, not a claim that we migrated a named client's booking system. Our rental-system experience and internal application work are documented separately with their confirmed contributions.