What a Legacy .NET Migration Involves, for Non-Technical Stakeholders

A .NET Framework to .NET 8 migration replaces the platform an application runs on. It is not a version upgrade, and the difference explains why the estimate is larger than stakeholders expect.

An upgrade is what happens when a phone moves to a new operating system release: the software keeps working, some details change, operations continue. A platform migration is closer to replacing the plumbing and wiring in an occupied building. The building stays where it is and looks the same afterward. Everything behind the walls is different, service cannot be interrupted for long, and the condition of what is back there is unknown until the walls are opened.

Where the time goes

Four categories, in ascending order of unpredictability.

Dependencies. The application uses third-party components: a PDF library, a reporting engine, charting controls, an authentication package. Each needs a version compatible with modern .NET. Most have one. Some do not, because the vendor discontinued the product or is no longer in business, and those components must be replaced.

Replacing a reporting engine is not a migration task. It is a separate project with its own testing, its own user-visible changes, and its own training requirement, and it is frequently the largest single line in the estimate.

Windows-specific functionality. .NET Framework is tied to Windows, and older applications used that freely: the registry, COM components, Windows-only cryptography, server-side Office automation. Modern .NET is cross-platform, so this code is rewritten against different mechanisms.

The volume is countable in advance, which makes this the most predictable category in the estimate.

Configuration and infrastructure. Configuration files, deployment process, authentication, and logging all changed between platforms. The work is mechanical and rarely difficult. It is where the schedule meets other departments, because it requires people who do not report to the project: network, identity, and infrastructure teams working on their own queues.

Plan for this dependency explicitly. It is the most common source of idle time on an otherwise healthy migration.

Verification. Almost always the largest category, and the first one cut when the number needs to come down.

Moving the platform is half the work. Demonstrating that the application still behaves identically is the other half. Where automated tests exist, the mechanism for demonstrating it exists. Most applications of this age have few or none, which means someone must first establish what correct means (which reports produce which figures, which workflows produce which outcomes) and then verify each one.

That is why the estimate looks disproportionate to the change. A large share of it is not moving the application. It is building the ability to determine whether the move succeeded.

What separates a two-month estimate from an eight-month one

Three variables, all measurable before committing to a number.

• How many third-party dependencies have no supported successor. A single replaced component can double a small migration.
• How much Windows-specific code exists. A team can count this in a few days.
• Whether meaningful automated test coverage exists. This is the largest single factor. The same application with and without tests differs by a factor of two to three, because verification is otherwise built from nothing.

Any estimate produced without measuring those three is a guess. A short paid assessment of one to two weeks converts a range into a defensible figure, and it is the least expensive risk reduction available on this type of project.

The scope discipline that determines completion

This project type has a specific failure mode. Developers working inside a codebase untouched for a decade will find genuinely poor code: bad structure, obvious inefficiency, features built awkwardly. The instinct to correct it while in there is sincere and frequently correct on the technical merits.

It is also the mechanism by which a four-month migration becomes a nine-month rewrite. Every improvement introduces a behavior change, every behavior change requires verification, and verification is already the largest category.

The rule that gets migrations finished: the migration changes the platform, not the behavior. If the application calculated something incorrectly before, it calculates it incorrectly afterward. Everything found along the way goes on a written list, and that list becomes the next project, funded separately, executed on a supported platform where the same work costs substantially less.

This is unsatisfying to engineers, and it is the discipline that distinguishes migrations that complete from migrations that stall.

The definition of finished

A migration that compiles is not finished. That state is common, and it is how projects stop at ninety percent: the application builds on the new platform, runs on a developer's machine, and cannot be deployed, because deployment, identity configuration, and verification were the remaining half.

Finished means all five of the following:

• The application runs in production on a supported platform
• The internal team can deploy it without the migration engineer present
• The figures it produces have been checked against the figures the old system produced, with the comparison documented
• Monitoring and alerting are in place and have been tested
• The improvements identified during the work are written down as a funded next step rather than half-implemented

The last item carries more weight than it appears to. The value of a migration is not the runtime version number. It is that the system now sits on a platform where the next piece of work is affordable.