Migrate Legacy .NET to Modern .NET

Project Scope

Migrate your web application from any legacy version of the .NET framework to the latest modern version available. Stakeholders can choose either a Long-Term Support (LTS) version, which includes even-numbered major versions, or the latest feature builds.

  • We validate the code to ensure it compiles and runs correctly, noting that some exceptions apply.
  • We switch any NuGet packages to versions compatible with the new framework whenever possible. Some packages may need replacement with alternatives that offer similar features due to deprecation. In extreme cases, refer to the NuGet Package Migration add-on.
  • We organize solution code to ensure we apply best practices. This includes meeting StyleCop rules and following recommendations from ReSharper’s analysis engine, which identifies issues like memory leaks in managed resources. We will refactor very little code to change method processes; our focus is on improving formatting for readability.

Please note that we focus solely on the back end of your project, which is written in C# with ASP.NET. We do not address User Interface elements, such as XAML, WPF, WinForms, Angular, or React. Any overlapping code that requires updates should migrate to separate libraries. If the latest .NET version supports areas like XAML, WPF, or WinForms, we will take reasonable steps to set them up for building in that version and reference the other code as libraries. However, we will not emphasize rewriting those areas to meet the latest .NET practices.

Contact Us today for a quote »

Add-ons

NuGet Package Migration (each)

Sometimes, applications rely on specific NuGet packages that lack direct compatibility with the latest .NET version, and suitable alternatives may not exist. I will use decompiling tools to recreate the package targeting the same framework. This process must adhere to the licensing structure established by the package owner. I may contact the owner for permission or assist them in creating a modern framework-compatible build.

If the license or package owner expressly forbids this, you may need to leave the application in a non-functional state until your internal team can build the necessary features directly into your application.

In-Code DocXML Documentation

We will insert DocXML formatted documentation into all files, including file headers, classes, methods, properties, and fields. This output will generate XML files at build time, containing documentation for all tagged code elements, which can then integrate with other documentation reader tools. We can adjust the specific format of these DocXML comments based on client preferences, including line wrapping and separator lines.

This documentation significantly aids future support and maintenance of your application. It facilitates onboarding new developers and revisiting areas that haven’t been addressed in years.

Extended Architecture Documentation

We will create documentation using industry standard formats for data flow, infrastructure, and diagrams of the structure of the application components. These will assist developers and stakeholders with understanding where they are today so determining how to get where you need to be tomorrow is less stressful and more comprehensive.

Leave a Comment