March 2022 – Susheel Dakoju's Blog

This blog post summarizes various options available for migrating .net framework applications to Azure or AWS.

Approach 1: Deploy existing .NET apps as Linux containers only
Approach 2: Deploy existing .NET apps as Linux containers or EC2 or Azure VMs
Approach 3: Deploy existing .NET apps as Windows containers only
Approach 4: Deploy existing .NET apps as Native Cloud Services

Comparison of all approaches

	Linux containers only	Linux Containers and EC2 or Azure VMs	Windows Containers only	Native Cloud services
Porting to .net core	Required	Required for Linux containers Optional for EC2 or Azure VM-hosted apps.	Not required	Not required
End-to-End Migration time	Very high	High	Low	Medium
Ease of migration	Very Complex(Application need to be targeted to .net core and lot of code refactoring)	Complex(Apps that cannot be containerized will be hosted on EC2)	Easy(Supports Lift and Shift with some code refactoring)	Moderate(Might require some code refactoring based on the adopted service)

High-level steps of migration: Applies to all the above approaches.

Step 1: Run portability analysis using the following tools, a better approach would be to use both options a and b for analysis to get the best of both tools.

.NET Upgrade Assistant
1. The .NET Portability Analyzer – .NET
AWS Porting assistant for .net
1. Porting Assistant for .NET – Amazon Web Services

Step 2: Identify roadblocks, some of the features that are leveraged in .NET Framework apps may not be supported by .NET core when ported. Please find more information at .NET Framework technologies unavailable on .NET Core and .NET 5+

Step 3: Identify functionalities that need to be refactored to work seamlessly on Cloud, following are some of the items to consider.
- Session State: Applications should be stateless to scale/switch at will. Session state should be persisted outside the app using services like Redis Cache etc. Especially with containers that get dropped and recreated more often than less maintaining Session state is critical.
- Logging: If the apps are logging to file systems locally, these apps need to be updated to log to the native logging service within AWS or Azure.
- LDAP-Queries: If the apps are querying LDAP stores such as AD, these applications should use AWS Cognito or Azure AD.
- Authentication: If the app relies on Windows Authentication or on-Premise AD this might require additional changes to the application.
- File-Persistence: If the apps have uploading files that need to be persisted these files have to be persisted outside the app.
- Miscellaneous:
  - On-Premise dependencies.
  - Email functionality.
  - Custom Domains
  - Apps using GAC (Global Assembly Cache)

Step 4: Fix the issues from Step 1, 2 and 3
Step 5: Containerize the app- Add supporting YAML configuration, make project changes, etc.
Step 6: Build, test locally and deploy.

Approach 1: Deploy existing .NET apps as Linux containers only

.NET Framework applications must run on Windows, porting these .NET Framework apps to Linux containers requires these apps to be re-targeted to the .NET core. This makes this approach the most time-consuming and complex among all of the approaches.

Note: As of this writing, .Net 5 is the latest stable version that supports Linux containers. .NET 5.0 is the next major release of .NET Core following .NET core 3.1.

Microsoft released .NET 5.0 instead of .NET Core 4.0 for two reasons:

Skipped version numbers 4. x to avoid confusion with .NET Framework 4. x.
Dropped “Core” from the name to emphasize that this is the main implementation of .NET going forward. .NET 5.0 supports more types of apps and more platforms than .NET Core or .NET Framework. [1]
NET Framework 4.8, released in April 2019, is the last major version, “all future investment will be in .NET Core.”[2]

.Net 6 is still in Release candidate (RC) releases that provide early access to features and are feature complete. These releases are supported for production use since they have a go-live license.

Please find this white paper on what it takes to convert a simple .NET Framework to .NET Core to run on Linux containers.

Modernize .NET Applications with Linux Containers

Pros:

Upgrading to .Net 5 makes it easier for future upgrades.

Cons:

Requires a lot of changes to the project structure to retarget to the .NET 5 framework.
Porting Windows apps, .net libraries to .NET 5 can be relatively easy compared to ASP.NET Web applications.
ASP.NET web applications require quite a lot of code refactoring, changes to project structure, and how the configuration is read and written, as well as source code changes may be required for unresolved incompatibilities.
If there are no compatible NuGet packages for .NET 5, the application has to wait until a compatible NuGet package is released or find alternatives which can sometimes be tedious and time-consuming.
Any changes to the application require a deep understanding of the app and how it’s intended to function, this could be challenging for a team that is just responsible for migrations.
Applications well covered by unit tests are safer to port as there is a better chance of finding differences in behavior that may cause unexpected results.
Some of the features may not be supported in .net core, if the application uses any of these features, the application may have to be rewritten. Please see the complete list of .NET Framework technologies unavailable on .NET Core and .NET 5+

Following is just a sneak peek of .NET Portability Analyzer in action, Micorosft has heavy documentation regarding the tool. Please see more at The .NET Portability Analyzer – .NET

Run the .NET Portability Analyzer.

The sample out of the Analyzer can be found at

SamplePortabilityReport Download

The tool is available as a Visual Studio extension, following screen capture shows how to target .NET 5.0

After the extension has been installed, the Portability analysis can be performed as shown below.

Approach 2: Deploy existing .NET apps as Linux containers or EC2 or Azure VMs:

This is similar to Approach 1 but accommodates all use cases. If there are any issues with porting to .NET Core or if an app cannot be containerized, in such cases these apps can be hosted within AWS EC2 or Azure VM instances.

Approach 3: Deploy existing .NET apps as Windows containers only

A .NET Framework application must run on Windows, period. If existing .NET Framework applications have to be containerized, you can’t or don’t want to invest in migration to .NET Core or later (“If it works properly, don’t migrate it”), the only choice you have for containers is to use Windows Containers. [3]

Pros:

Aligns well with Rehost migration strategy, applications can be ported as Windows containers easily with very less turnaround time.
If there is no need for full-fledged Container orchestration Azure has low-cost managed services that support both Windows and Linux-based containers.
Applications can benefit from windows containers, as the main dependency for the .NET Framework in Windows.
Also, applications having secondary dependencies, like IIS, and System.Web in traditional ASP.NET benefits from using Windows containers.

Cons:

Each application warrants changes to the project structure to support containerization.
Architecture and maintenance can get complex depending on the choice of container orchestration between managed vs. self-managed.
Code may need to be refactored if the functionality is compromised due to hosting it within a container.

Approach 4: Deploy existing .NET apps as Native Cloud Services

Microsoft introduced Cloud Adoption Framework that recommends how to migrate various applications to Azure. A good strategy should include multiple migration/design choices catering to the application needs with the least amount of migration time and modifications to the applications.

Please see the flowcharts below to get a high-level understanding of Microsoft’s recommendation of migrating applications and their supporting data sources within Azure.

Flow chart to select a candidate to compute service.

Flow chart to select a candidate data service.

Note: This section covers Azure services only, a similar flowchart can be devised for AWS as well. It’s important to establish a clear plan and scope upfront for all the applications, the team should not come to the drawing board for each application.