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:
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 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.
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.
eShop uses a SQL database to store this data, more details on the architecture as well as the source code can be found here.
Before starting discovery, you’ll need to create an Azure Migrate project. Follow this quick start guide.
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:
Next, let’s generate a business case.
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.
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.
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:
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.
Let’s unpack this:
You can view the report details by clicking the link below Overview on the left column.
Both the apps are Ready and the report surfaces the recommended node SKU, a 2 core 8 gig Dpds_v5 series. A web app can be Ready with conditions or Not ready. In such cases, the assessment provides migration warnings, errors and remediation steps.
Navigating to the Cost details tab, you see the cost breakdown across the various node pools.
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.
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:
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:
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!
Refer to the official documentation for more granular details around replication job creation and migration.
In this blog, you learnt:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.