Azure Migrate - Modernizing your .NET apps to Windows containers on Azure Kubernetes Services
Published Jan 31 2024 06:36 AM 5,523 Views
Microsoft

In this blog, we’ll go over how you can modernize a legacy ASP.NET web app using Azure Migrate and run in on Windows containers on Azure Kubernetes Service. You’ll walk away with an understanding of how to: 

 

  1. Discover your ASP.NET web apps running on-premises 
  2. Generate a Business case detailing the TCO comparison of running your apps on-premises vs on Azure and cost savings 
  3. Assess the cloud readiness of your apps and generate a migration path 
  4. Containerize and re-platform your apps without code changes to AKS 

 

We’ll cover each topic in depth below with technical details, providing you with a step-by-step guide for modernizing your web app. 

 

Azure Migrate Overview 

 

Azure Migrate is the one-stop tool for your migration and modernization journey to Azure. It tackles each phase of the migration journey for infrastructure and workloads – Discovery and inventory, TCO comparison and savings, assessments and migration path recommendations and migration or modernization. 

 

Azure Migrate supports multiple workloads – servers, SQL databases, ASP.NET, Java Tomcat and Spring boot apps. It also provides integration with several ISV offerings. 

 

Azure Migrates provides an end-to-end migration experience for ASP.NET web apps to Windows container targets such as AKS and App Service for containers, doing the heavy lifting for complex tasks at-scale and reducing the amount of manual intervention needed from customers. 

 

Modernize a legacy .NET web forms app to Windows on Azure Kubernetes Service 

 

Background

In this blog, we’ll work with a legacy ASP.NET web forms app called eShop running on a VMware server. 

eShop is an internal back office app that employees use to maintain their product catalog. They can add products, edit and delete them. 

 

anraghun_0-1706079570182.png

 

 

eShop uses a SQL database to store this data, more details on the architecture as well as the source code can be found here. 

 

Prerequisites

Before starting discovery, you’ll need to create an Azure Migrate project. Follow this quick start guide. 

 

Discover eShop on Azure Migrate 

Let’s start by discovering our app on Azure Migrate. To do so, we’ll need to deploy the migrate discovery and assessment appliance for VMware. The appliance can be deployed either using an OVA template or a PowerShell script. 

Follow this guide to deploy the appliance with an OVA template. If you wish to instead use the PowerShell script, ignore this section and refer to this article. 

 

Once deployed, the appliance needs to be configured using the appliance configuration manager which is automatically deployed along with the appliance. Appliance configuration involves providing both the hypervisor and guest VM credentials which allows the appliance to discover web apps, SQL servers and other workloads running on servers. 

 

Discovery time depends on many factors such as number of servers, workloads and network bandwidth. Workloads such as web apps and SQL servers may take up to 24 hours to get discovered and reflect on the portal, although it should more likely happen much sooner. 

Once discovered, you should be able to see the server and web app on Azure Migrate: 

 

  1. Open Azure Migrate on the Azure portal and select Servers, databases and web apps. You should start seeing the discovered inventory here. Select Servers running web apps. 

    anraghun_4-1706079718382.png

     


  2. You should see a list of servers. Click on the Web apps hyperlink for the server containing eShop. This drill down shows the set of web apps running on that server. We can see eShop has been discovered with additional details such as URLs, protocols, connection strings and app directories. 

    anraghun_5-1706079740434.pnganraghun_6-1706079747465.png

     

Next, let’s generate a business case.

 

TCO comparison and Savings 

Azure Migrate allows you to generate a business case detailing TCO comparisons, cashflow projections and associated savings. Today, business cases can only be generated at the project level and will surface these insights across all the workloads discovered in that project. It’s essentially a datacenter level operation. 

 

You can generate a business case very easily by following this. Once generated, you’ll see the recommended target for your web apps in the Azure PaaS report. Business case intelligently picks an Azure target based on your migration strategy. It also bubbles up the recommended SKUs for your apps which are also surfaced in Azure Migrate assessments in more detail. 

 

anraghun_7-1706079869408.png

 

This report has estimated the cost savings by moving your on-prem workloads, including eShop, to Azure Paas. Business case shortens time for business decision makers significantly to give a go/no-go to migrations. Once committed, the buck is passed to the IT admins and cloud architects to come up with a migration plan. 

 

Let’s generate an assessment to make this easier. 

 

Assessing eShop for Azure Kubernetes Service 

Azure Migrate allows you to create an assessment for .NET web apps for various targets – Azure App Service code & containers, AKS. An assessment generates the following insights: 

 

  1. The cloud readiness for the assessed apps for each target 
  2. Target configuration such as SKU details, mapping apps to target instances (for example, mapping apps to the recommended node pools for AKS) 
  3. Associated cost of running these apps on Azure month over month. 

 

Follow this guide to assess ASP.NET web apps for AKS migration. Azure Migrate allows you to configure assessment details such as preferred SKUs (storage optimized, isolation, GPU...), select savings options (reserved instances, Azure savings plan), custom discounts and accordingly provides recommendations and costs. 

 

Here’s the assessment created for eShop. 

 

anraghun_8-1706079954792.png

 

Let’s unpack this: 

  1. We can see the assessed entities are eShop and another web app deployed on the same web server. 
  2. We can see that both these apps are ready to migrate, meaning there are no migration warnings or errors. 
  3. The monthly cost estimate to run these apps on Azure is ~$228, which includes the cost of AKS standard tier pricing. 

 

You can view the report details by clicking the link below Overview on the left column. 

 

anraghun_9-1706080001635.png

 

Both the apps are Ready and the report surfaces the recommended node SKU, a 2 core 8 gig Dpds_v5 seriesA web app can be Ready with conditions or Not ready. In such cases, the assessment provides migration warnings, errors and remediation steps. 

 

anraghun_10-1706080057696.png

 

Navigating to the Cost details tab, you see the cost breakdown across the various node pools. 

 

anraghun_11-1706080120237.png

 

In this case, there are 2 pools recommended, a system node pool and a user node pool to host eShop. With the assessment complete, we can now look at migrating eShop to AKS. 

 

Migrating eShop to Azure Kubernetes Service 

Azure Migrate allows containerizing and migrating web apps at scale to AKS. You can follow a step-by-step wizard to provide configurations using which the platform generates key artifacts such as Dockerfiles and Kubernetes manifests, thereby reducing significant time in containerizing your apps. Let’s look at how this happens: 

 

  1. Open Azure Migrate on the Azure portal and select Servers, databases and web apps. In the migration and modernization tool, select Replicate. 

    anraghun_12-1706080293131.png

     


  2. On the Specify Intent screen, select ASP.NET web apps, Azure Kubernetes Service (AKS), VMware vSphere as your workload, target and virtualization type respectively. Then select your appliance.

    anraghun_13-1706080311834.png

     

  3. Now, search and select the apps you want to migrate. You can also parameterize and configure connection strings and app directories. Refer to this for more details.

    anraghun_14-1706080327873.png
  4. After selecting your apps, select the desired container registry to save the docker files and the AKS cluster to which you want to deploy the apps to. 
  5. In the deployment settings, you can specify the image details, ports, replicas and service type for your apps. This information will be used to bootstrap the Dockerfile and Kubernetes manifests. We’re going to leave it to the defaults. 

    anraghun_15-1706080340061.png

     


  6. In the advanced settings, you can choose to store your app configurations either as a native Kubernetes secret or on Azure Keyvault. You can also copy app directories to Azure file share. Refer to this for more details. 
  7. Review your configurations and start replication. 

 

Azure Migrate will create a replication job for each app selected for migration. The app binaries are copied onto a temporary storage account. The replication job allows you to: 

  1. View and edit the Dockerfile and Kubernetes manifests. The dockerfile uses the .NET framework 4.8 on windows server core as the base image. It also downloads the IIS web deploy tool. During the image build the ApplicationArtifacts_Placeholder is replaced with a SAS URI to the storage account containing the replicated binaries. The Entryscript simply unzips the copied binaries and uses web deploy to spin up the site.

    anraghun_16-1706080416450.pnganraghun_17-1706080424168.png

     

  2. Build your container image. The image is then stored in the selected ACR. 
  3. Do a test migration. This will deploy the app onto the AKS cluster. You can ensure that it spins up correctly. You can also use the Clean up test migration option to remove the deployed workloads. Typically, you can create the replication job with a test cluster, do a test migration and then change the target settings to point to your production cluster. 
  4. Once you’ve tested that the app is working fine, you can select the Migrate option to deploy it onto your production cluster. 
  5. The Azure Migrate service authenticates itself to you AKS clusters using its first party managed identity. 


After migration, you can visit the AKS cluster on the Azure portal, select Services and ingresses, search and view the service that just got created for your app. Click on the assigned external IP to view your app! 

 

anraghun_18-1706080463691.png

 

anraghun_19-1706080469520.png

 

Refer to the official documentation for more granular details around replication job creation and migration. 

 

Conclusion 

In this blog, you learnt:  

  1. How to discover your ASP.NET web apps hosted on-prem on a VMware server. The appliance allows you to discover your apps at-scale. 
  2. Project savings and compare the total cost of ownership from migrating your apps to AKS. An automated business case makes it easier for your business decision maker to confidently commit to Azure. 
  3. Create cloud readiness assessment and understand migration blockers as well as the recommended AKS configuration to run your apps. 
  4. Finally, containerize and migrate your apps to AKS. Auto-generation of key artifacts such as Dockerfile and Kubernetes manifests allow you to significantly cut down on your migration effort and time. 

 

For more scenarios such as discovery on other stacks such as Hyper-V or bare metal, assessments and migration to App Service and what’s new, checkout our official documentation. 

Version history
Last update:
‎Jan 31 2024 06:36 AM
Updated by: