One Third-Party Component Is Blocking Your .NET Upgrade

When the upgrade analysis comes back clean except for one dependency, that dependency is the project. Common ones: a reporting engine such as Crystal Reports, whose .NET runtime targets .NET Framework; WebForms control suites; PDF and imaging libraries; payment, fax or device SDKs from vendors that no longer ship updates.

There are four options.

1. Buy the current version

Many vendors sell a product for modern .NET. Check whether it is the same API or a different product under the same name. A WebForms grid and the vendor's ASP.NET Core or Blazor grid share a brand and little else, so the license is the small cost and the UI rework is the large one.

2. Replace it

Move to a different library or service. Price it by counting what uses the component. For a reporting engine that means every report, with its parameters, subreports, formulas and export formats. Reports rarely convert automatically, and users will compare the new output to the old one line by line, so include that review in the estimate.

3. Isolate it

Keep the component on .NET Framework in a small separate service, and have the migrated application call it over HTTP. The rest of the system moves forward now.

This works well when the component has a narrow job, such as rendering a report to PDF, and when the service has an owner and a retirement date. It works poorly when the component is woven through the UI, or when the service is left running indefinitely with a second runtime to patch and deploy.

4. Retire the feature

Usage data sometimes shows that the blocked feature serves a few people who would accept an export to Excel or a simpler screen. Ask before pricing the alternatives.

Choosing

Four facts decide it:

• How many places use the component. Search the solution for its namespaces and count.
• Whether the vendor has a supported successor, and how different its API is.
• How often the feature is used. Pull it from logs or ask the users.
• How narrow the interface is. One call that returns a file isolates easily. Controls embedded in forty pages do not.

A narrow interface with heavy usage points to isolating now and replacing later. Wide usage with a supported successor points to buying. Wide usage with no successor is a replacement project, and it should be estimated as its own line next to the migration. Low usage points to retiring the feature.

If the component is a WebForms control suite, the question is larger than one dependency. Rewriting vs. migrating a WebForms application covers that decision.