Migrating .Net Applications to Azure Services: A Practical Guide

Migrating .Net Applications to Azure Services: A Practical Guide

Microsoft Azure is a cloud platform that provides many services that can be used in software application development and hosting. Azure app services allow developers to build and host web applications, mobile back-ends, and APIs without needing to manage infrastructure. Azure SQL provides a family of SQL Server database engine products in the cloud. Azure also offers many other popular services, such as Azure (serverless code) functions, Virtual Machine hosting, cognitive services, and more.

There are many significant advantages that you could reap by migrating an existing application to leverage Azure’s services, yet there are potential significant constraints. This article reviews the key benefits and constraints of migrating .Net applications to Azure and provides a recommended approach for planning and executing the migration.

Benefits of Leveraging Azure Cloud Services

By using Azure services, there is significantly less maintenance, improved availability, improved security, and available mechanisms to easily add or remove resources to address performance issues and scalability needs. Some of the specific advantages include:

  • Ability to enable deployments from GitHub, Azure DevOps, or any Git Repo
  • Allowance of dedicated environments (not affected by other applications on a shared environment)
  • High Uptime & Availability since there are no infrastructure dependencies
  • No Patching Required; App Service automatically keeps the OS and language frameworks up-to-date, without having to manually patch them
  • Quick and easy dynamic scalability
  • Simple Load Balancing features
  • Ability to use large file storage (using Azure Blob Storage)

Compatibility Constraints to Consider

To gain the maximum benefit from migrating your .Net software application from a physical or virtual environment to Azure, we recommend migrating to Azure using App, SQL, and other relevant services. Many applications have components that are not compatible with these services. Some of the specific constraints are noted below.

Azure App Service

  • 3rd-Party Software cannot be installed (example: Quickbooks SDK)
  • Need to update the application to use 3rd-Party Email Service (example: Sendgrid)
  • Need to update to use persistent File Storage (Azure Blob)
  • Does not support Windows jobs
  • Does not support Windows Services
  • Does not support Assemblies in the GAC (Global Assembly Cache)
  • Need to update references
  • Need to update to manage session state
  • Does not support .NET Framework before 4.7.2

Constraints/ Limitations of Azure SQL Services

  • Does not support SQL email/mail
  • Does not support linked database / cross-database queries
  • Does not support SSIS / DTS Packages
  • Does not support SSRS (SQL Reporting Services)
  • Does not support SQL jobs

While nearly all software applications use some of the unsupported components listed above, many can be easily migrated and only require minor adjustments. There are also options for migrating applications that rely heavily on these components.

Planning the Migration

Prior to the migration, it is important to review the code and create a plan for any known compatibility issues. We recommend the following approach.

Identify architectural constraints

Recognize potential architectural changes that will be necessary prior to performing the upgrade. Below are common architecture changes and recommendations for addressing them.

Is the application .Net Framework <4.7.1?

If so, upgrade to 4.8.

Does the application use SQL Email?

If so, convert to Azure function or Web Job.

Does the application use linked database / cross-database queries?

If so, consider a hybrid approach using Azure App Services and hosted SQL instance.

Does the application use linked database / cross-database queries? 

If so, determine whether you can easily convert to Azure Function or Web Job. If heavily reliant, we recommend a hybrid approach using Azure App Services and a hosted SQL instance.

Does the application use SSRS (SQL Server Reporting Services)?

If yes, we recommend a hybrid approach using Azure App Services and a hosted SQL instance.

Does the application use Windows Jobs or Windows Services?

If yes, make a decision if the feature is necessary and can be converted into an Azure Function or Web Job.

Identify any other architectural constraints and define a plan to address them.

Identify areas of the system that will require code updates

Determine potential code changes that will be necessary prior to performing the upgrade. Below are common code changes to consider.

  • Identify the areas of the system that use functions to send email
  • Identify the areas of the system that use functions to store data
  • Identify the domain names that will need to be set up
  • Confirm the number of SSLs that will need to be set up
  • Identify the areas of the system that have jobs set up
  • Confirm the app and connection configurations

Execute Database and Code Migration Assistant Tools

After identifying known architectural and code compatibility constraints, we recommend using the Azure Migration tools to confirm the compatibility of the code and database.


Executing the Plan

Now that you have identified and planned for architectural and code changes, you are ready to perform the migration. We recommend the following approach.

  • Create the environment; create the resource group, storage account, Azure connection strings, web app, and SQL database
  • Migrate the Database to Azure SQL
  • Deploy and publish the App to App Services
  • Deploy Web Jobs for any jobs you are converting
  • Create Azure Functions for any functions you are converting
  • Configure email service
  • Perform QA / UAT on the migrated application
  • Make any necessary updates from the testing
  • Go-Live
  • Celebrate

Now that you are reaping the benefits of hosting your application in a more scalable, secure, and lower maintenance environment, you can focus your efforts on advancing the application to meet your business’ needs.


How much effort does a typical Azure Migration cost?

The effort for migrating a .Net application to Azure services varies significantly based on the amount of code and architectural changes and your developers’ familiarity with Azure. A typical business application migration performed by an experienced development team may range from 4 – 6 weeks of total effort.

Would you recommend outsourcing the migration if you have in-house developers? If so, how much should I expect to invest?

If your development team does not have expertise in Azure or feel confident in executing an Azure migration, we recommend that you consider a collaborative outsourcing engagement with an experienced partner. Depending on the complexity of the migration, the cost may range from $15,000 to $40,000, yet may be lower or higher depending on the specific needs.

What if my application relies too heavily on components that are incompatible?

We recommend a phased approach whereby you migrate in stages, starting with the lowest risk. This may include (1) migrating the application from a local or third-party hosting facility to Azure Virtual Servers, followed by (2) migrating just the application to App Services while maintaining a Virtual Server for components that still require one, and, finally, (3) rearchitecting the components that are not compatible.

Can you migrate applications that are in technologies other than .Net to Azure?

Absolutely; however, the approach would likely be different than described in this article. We recommend reaching out to a partner who will help consult you on the best approach for your situation.

Do you recommend Azure or AWS for application hosting?

There are many factors that would make one cloud hosting provider better than the other. For .Net applications, we typically recommend migrating to Azure because the migration path is often more seamless.

The post Migrating .Net Applications to Azure Services: A Practical Guide appeared first on Miles Technologies.

This content was originally published here.