How Kloia used Porting Assistant for .NET to accelerate EposNow API modernization

By Turgay Özgür – Software Consultant at Kloia
       Onuralp Taner – Software Consultant at Kloia
       Prasad Rao – Sr. Partner Solutions Architect at AWS

Many organizations must modernize their .NET Framework legacy applications to .NET Core to take advantage of the performance, cost savings, and robust ecosystem of Linux. It’s why AWS recently launched Porting Assistant for .NET, an analysis tool that scans .NET Framework applications and generates a .NET Core compatibility assessment, helping you port applications to Linux faster.

EposNow had a tight timeline to modernize their EposNow API legacy application, which was written in .NET Framework. Trusted by over 30,000 customers, EposNow is a cloud-based software provider that designs and manufactures electronic point of sale (EPOS) technology for retail and hospitality businesses. The technology runs on a REST API interface so that developers can develop applications and features on top of their cloud-based point of sale (POS) platform. To help with the migration, EposNow engaged Kloia, an AWS Partner Network (APN) Advanced Consulting Partner with competencies in DevOps and Microsoft workloads.

In this post, we provide a tutorial in using the Porting Assistant for .NET to modernize your applications. We will also describe how Kloia accelerated EposNow API’s modernization using Porting Assistant to port their .NET Framework based code to .NET Core.

Considerations in porting a .NET Framework application to .NET Core

Before migrating a .NET Framework application to .NET Core, you should:

1. Assess compatibility with .NET Core
2. Identify and prioritize parts of the application to  start the migration that have least impact on the overall application
3. Identify lines of code to be replaced by finding replacements for incompatible .NET Core APIs and packages

These considerations help us facilitate minimum disruption to ongoing development. Therefore, accurate analysis and assessment are imperative to avoid issues and to optimize your migration.

Step 1: Running a compatibility assessment for EposNow API

The EposNow API was a multi-layered and comprehensive application developed in .NET Framework, with more than 20 projects bundled into one single solution. To get started on porting the application to .NET Core, we used Porting Assistant for .NET to run a compatibility analysis.

The current version of Porting Assistant for .NET is available as a standalone tool. After verifying that the prerequisites were in place, we installed the tool following the steps to install Porting Assistant for .NET.

On the Setup page, you have the option to enter your AWS CLI profile information. This helps the Porting Assistant collect metrics to flag issues with the software. You have the option to disable this telemetry gathering at any point during the tutorial.

To assess a new solution, we must choose the solution file of the.NET Framework-based application, then choose Assess.

The assessment takes few minutes to complete and shows the following summary dashboard of the assessment report:

The Assessed solutions dashboard shares the following details about each solution:

• Ported projects — the number of projects in the solution that have been ported
• Incompatible packages — the number of packages in the solution that are incompatible with .NET Core
• Incompatible APIs — the number of API calls in the solution that are incompatible with .NET Core
• Portability score — the portability score indicates how portable an individual project is. It is represented as a fraction of compatible APIs/non-compatible APIs within the solution

Step 2: Diving into the assessment dashboard

Choose View Details to see the full compatibility assessment report. The full assessment report can be downloaded and shared with other developers or decision makers in the organization for offline viewing and analysis. In this step, I show you how to use this assessment to decide which projects to start porting the application. I also explain all the features of the tool, even though some features may not be used in porting every application.

The assessment report is divided into five sections, with one tab for each section. The sections are Projects, Project references, NuGet packages, APIs and Source files.

2.1 Choose a project to port using the Projects tab

The Projects tab lists projects included in your solution. Within your projects, you also see each Target framework, number of Referenced projects, number of Incompatible packages, number of Incompatible APIs, Portability score, and Port status (ported or not ported).

The Portability Score helps to determine which project to choose to begin the transformation. The project with highest Portability Score is the least effort to port. However, we validate least dependency on the ported project to have minimal impact on the overall application. Start from the project with least dependencies (least number of referenced projects) and highest compatibility scores.

2.2 Check project dependencies using Project references tab

Using the graph in the Project references tab, select a node to review your selected project’s dependencies. By examining a visual representation of each project, you can select the one with the least dependencies without scanning the source files manually.

For EposNow, Kloia started the transformation using the project with the least dependencies. As we see in the graph, Api.Global.Sdk.Models and Api.Global.Contracts are not dependent on any other project. They were good starting points for the code-level migration. The Api.Global.Services and Api.Global.Hosts.PublicRestService projects had too many dependencies, and were not suitable to start the transformation.

2.3 Check for incompatible Nuget Packages with Nuget packages tab

The NuGet Packages tab helps users to identify the incompatible Nuget packages, and their replacement suggestions.

The Replacement suggestions are generally up-to date. The Porting Assistant for .NET’s API replacement engine improves as it gets more information about incompatible packages and APIs.  For the EposNow API, the incompatible packages were mostly private ones.

2.4 Check for incompatible APIs with APIs tab

Within the APIs tab, scan for any incompatible APIs listed under each APIs Status. In practice, this step is performed during the porting instead of the assessment. This is because of the manual effort and knowledge required to search through the code to find incompatible APIs. Knowing this level of information at the assessment stage helps inform accurate effort estimations.

2.5 Use Source files tab to find replacement code suggestions

Choose a source file to view the Incompatible API calls and replacement suggestions in the source code. For example, if an email client, and the equivalent implementation, is not in .NET Core, we can find which one or more code files are using these implementations. Inline details are highlighted about the suggested change as well.

Step 3: Use Portability score to assess effort in porting the application

Use the Portability Score in the dashboard to identify which parts of the application port require more manual effort. This effort estimation is required for effective planning and execution of the project. The Portability score does provide a high-level idea of incompatibility. A more in-depth analysis of the assessment report is required to assess the effort required in porting to .NET Core.

For the EposNow API, the incompatible packages were mostly private ones. Based on the complexities, Kloia estimated that the overall estimation of this project was four months, including splitting the monolithic repository to domain services.

Step 4: Port the application using assisted porting

There are many repetitive tasks involved in porting, like making all .csproj files compatible with .NET Core and updating the third party and internal packages with.NET Core equivalents. Thankfully, Porting Assistant automates these tasks.

After analyzing the assessment report for the EposNow API, Kloia started porting the application using Porting Assistant. We started porting the first project Api.Global.Sdk.Models (as it is not dependent on the other projects) by choosing it in the Projects tab, and then choosing Port Project.

The Porting Assistant enables us to choose the porting location. The first option is “Copy to new Location” that allows you to choose a new location where you want to save the porting result. The second option is “Modify source in place” which overrides the existing code base. We selected the “Modify source in place” option to compare changes using the git version control system.

Choose Save. Under Port settings, on the Port Projects page choose a target framework version (.NETCoreApp 3.1.0 or .NETStandard 2.1.0). If your project has an application layer dependency (HTTP, MVC) or an executable project, select .NETCoreApp. Otherwise, select .NETStandard.

Note: When we port a project, the code is not refactored. The packages are upgraded to their latest compatible version, while relevant project reference files are updated to the format compatible with .NET Core. Additional source code changes may be required to resolve the incompatibilities.

Step 5: Compare code changes and build ported projects

We can verify which files were changed automatically by the Porting Assistant.

As packages.config is not used in .NET Core, it has been removed. Additionally, there are changes within the Assembly.info and .csproj files to make it compatible with .NET Core.

The following images show the changes to the .csproj file:

If following conditions are met, the ported project should build successfully:

• The ported project’s dependencies are all successfully ported.
• The unresolved incompatibilities of the project have been resolved by manual code changes

Depending upon the complexity of the ported application, you can choose to either port one project at a time and progress iteratively, or port the entire application and resolve all incompatibilities in one step.

With EposNow API, we took an iterative approach. We chose this approach to ensure that the current development teams were not impacted by the parallel refactoring on the same code base.

Conclusion

In this post we walked through Porting Assistant for .NET, going through the entire compatibility assessment and the effort estimation for modernization. Porting Assistant for .NET helps you prepare for modernization, as it speeds modernization from several days to a few hours. Additionally, it guides you through the porting process to significantly reduce manual effort. Though using Porting Assistant does not eliminate the need for source code changes, it does accelerate the pace at which the .NET legacy applications can be transformed.

Modernizing your legacy .NET applications can be transformative. Choosing trusted providers with niche expertise in this space is critical to achieving the desired value-add and results. We at AWS, and our partner Kloia, are interested in hearing about your application modernization approach, as well as the challenges you face and the solutions that work for you. Contact Kloia, an AWS Advanced Consulting Partner, to learn how they can help your organization transition to modern application development and deployment to meet your company’s needs.

AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your migration journey today.