We must prepare our Azure to set the correct permissions and prepare the on-premises Hyper-V hosts and VMs for server assessment and migration.

We need to create a new migration project on the access and migrate server section.

Create a new migration project

Next, we need to add the tools for the migration assessment. Click on the add tools button.

Add Migration Tools

After that, we need to create a new Azure migration project. Enter the details of the subscription, resource group, and project name. Also, we need to create a region where our migration needs to deploy.

Improve your organization's infrastructure and migrate on-prem to Azure with AIS.

Adding Migration Tooling

Next, we need to select the assessment tool we want to use. This can be the Microsoft tool or any third-party provider. In this case, we are using the Microsoft assessment tool.

Assessment Tools

Next, we can select the migration tool we want to use. In this case, we used Microsoft tool one. We can skip this step and select the migration tool after assessing our environment.

Adding Migration Tools

Click on add tool. This will create the Azure migration project with the selected tool.

Create Azure Migration

Now we need to start assessing our Hyper-V VMs.

Now that we have completed the Azure migration project setup, we can discover and assess the Hyper-V virtual machines for migration. We need to download the Azure Migrate appliance from the Azure portal. Click on “Discover” and select yes with Hyper-V. This will prompt us to the download link to the VHD file, with that we can create a new virtual machine on your Hyper-V server.

Download Azure Migrate appliance

Set Up and Register the Appliance

Register a new appliance

We must import a new Hyper-V using this existing VHD file and set the VM switch. After your virtual appliance machine runs, you can open a browser on a computer that can connect to the appliance VM and open the URL of the appliance web app: https://appliancename-or-IPAddress:44368. Now you can configure the appliance, like setting connection details, time sync, and install updates.

Set up discovery for Azure Migrate

In the next step, we need to register the appliance with Azure Migrate.

Register Appliance with Azure Migrate

Begin Continuous Discovery

Specify credentials to connect to Hyper V

We can now set up and configure continuous discovery by connecting the appliance to Hyper-V hosts or clusters and start VM discovery. The appliance will begin collecting and discovering virtual machines. It can take up to 15 minutes until the discovered VMs appear in the Azure portal. If you want to use performance data in your assessment, we recommend that you create a performance-based assessment after 24 hours or more.

Hyper-V Migrate Discovered Servers

Create and Review the Assessment

After the servers have been discovered, you can now create a new assessment for the specific virtual machines you want to assess.

Review Assessment

After the assessment is complete, you will see a report showing you the Azure readiness and monthly cost estimation for compute and storage.

Azure Readiness

The report will provide you with details info about the readiness and will let you know about the VM status:

  • Ready for Azure: Azure Migrate recommends a VM size and cost estimates for VMs in the assessment.
  • Ready with conditions: Shows issues and suggested remediation.
  • Not ready for Azure: Shows issues and suggested remediation.
  • Readiness Unknown: Used when Azure Migrate can’t assess readiness due to data availability issues.

Assessment Cost Details

It will also give you more information on the cost of running VMs in Azure:

Cost estimates are based on the size recommendations for a machine and its disks and properties. Create the report after 24 hours or more if you want more accurate performance data.
Estimated monthly costs for compute and storage are shown.
The cost estimation is for running the on-premises VMs as IaaS VMs. Azure Migrate Server Assessment doesn’t consider PaaS or SaaS costs.

Migrate Hyper-V VMs using Azure Migrate

Migrate Hyper-V VMs

After you have done your assessment and you know which Hyper-V virtual machines you want to migrate, you can now start with the migration process.

Prepare Host Servers

The Azure Migrate Server Migration runs a lightweight Hyper-V VM appliance. This is the same VM used to assess the Hyper-V environment (Azure Migrate Server Assessment tool). If you didn’t use the assessment tool and went directly to migration, you will need to download and set up the appliance, like in the assessment process. If you already have that VM from the assessment, you can use the existing virtual machine.

Replicate Hyper-V VMs

To start the replication, you can now select the virtual machines you want to replicate to Azure. You can choose to apply them directly from the Azure Migrate assessment.

Replicating Hyper VMs

We can configure the target settings like resource group and virtual network in the Azure environment.

Target Settings for Migration

In the compute tab, you can change the VM size, OS disk, availability set, disks, and VM name.

Changes to Target VM sizes

We can start replicating the virtual machines if all the configuration is done. Azure Migrate will automatically provision other Azure resources for the migration, like a Service bus, gateway storage account, log storage account, and key vault. The initial synchronization will take a while, depending on the size of the virtual machines and the available internet bandwidth.

Test and Migrate Hyper-V VMs

Virtual Machine Replicated

When the virtual machine is replicated, you can now start to migrate it. However, in most cases, you first want to test the virtual machines before you completely migrate them. With Azure Migrate, you can first initiate a test migration to test the VM.

If you click on the virtual machine, you are replicating, and you get more information about the server details, migration status, and replication settings.

Replicating Servers

We can click on “Replicating servers,” right-click on the machine you want to migrate and click on “Migrate,” or you can click “Migrate” on the server overview page. Azure Migrate will not remove or delete the on-prem Hyper-V virtual machine. But by default, Azure Migrate shuts down the on-premises VM and runs an on-demand replication to synchronize any VM changes since the last replication occurred. This ensures no data loss.

Microsoft Azure Planned Failover

When the job is finished, you can view and manage the VM like any other Azure virtual machine.

Azure Migrate Post-Migration and Cleanup

Complete the migration.

  • After the migration is done, right-click the VM > Stop migration. This stops replication for the on-premises machine and cleans up replication state information for the VM.
  • Install the Azure VM Windows or Linux agent on the migrated machines. Perform post-migration app tweaks, such as updating database connection strings and web server configurations.
  • Perform final application and migration acceptance testing on the migrated application now running in Azure.
  • Cut over traffic to the migrated Azure VM instance.
  • Remove the on-premises VMs from your local VM inventory.
  • Remove the on-premises VMs from local backups.
  • Update any internal documentation to show the new location and IP address of the Azure VMs.

Post Migration Best Practices

  • Keep data secure by backing up Azure VMs using the Azure Backup service.
  • Keep workloads running and continuously available by replicating Azure VMs to a secondary region with Site Recovery.
Over the last couple of years, I’ve moved from serious SharePoint on-premise development to migrating web applications to Azure.  My exposure to Azure prior to the first application was standing up SharePoint development virtual machines that pretty much just used the base settings.  Trial by fire tends to be the way I learn things best which is good because not only was I having to learn about Azure resources, but I also had to refamiliarize myself with web development practices that I haven’t had to work with since .Net 2.0 or earlier.

One of my first tasks, and the focus of this post, was to migrate the SQL Server to Azure SQL (Platform as a Service) instance.  The databases generally migrated well.  Schemas and the majority of the stored procedures were compatible with Azure SQL.  Microsoft provides a program called Azure Data Migration Assistant. This program not only analyzes but can migrate the database.  The analysis will return any suggested or required changes.  There are several types of issues that could arise including deprecated features, incompatible features, and syntax blockers.

Deprecated Field Types

There are three field types that will be removed from future versions: ntext, text, and image. This won’t hold up migrating from SQL server to Azure, but I did change the fields to future-proof the database. The suggested solution is to use: nvarchar(max), varchar(max), or varbinary(max).

Azure SQL Database

T-SQL Concerns

Now let’s get into some of the Azure SQL server limitations. I ran into several issues in scripts. Some had simple solutions while others required some redesign.

  • ISSUE: Scripts can’t connect to multiple databases using the USE statement.
  • SOLUTION: The scripts that did use the USE statement didn’t need it as it was only meant to connect to a single database.
  • ISSUE: Functions such as sp_send_dbmail are not supported. The scripts would send notification emails rather than sending from the application.
  • SOLUTION: This required an involved redesign. I created a table that logged the email and a scheduled Azure Web Job to send the email and flag the record as sent. The reference to sp_send_dbmail was replaced with an INSERT INTO Email command. If the email needed to be sent near-instantly, I could have used an Azure Queue and had the Web Job listen to the Queue then send the email when a new one arrives.
  • ISSUE: Cross-database queries are not supported. A couple of the apps had multiple databases and data from one was needed to add or update records in the other.
  • SOLUTION: This was another major design change. I had to move that logic into the application’s business layer.T-SQL Concerns

Linked Servers

Some of the applications had other databases, including other solutions like Oracle, that the application accessed. They use Linked Server connections to execute queries against the other data sources. So far, they’ve just been read-only connections.

Linked Servers are not available in Azure SQL. To keep the functionality, we had to modify the data layer of the application to pull the resources from the external database and either:
A. Pass the records into the SQL Stored Procedure, or
B. Move the logic of the Stored Procedure into the application’s data layer and make the changes in the application

One of the applications had a requirement that the external database was staying on-prem. This caused an extra layer of complexity because solutions to create a connection back to the database, like Azure ExpressRoute, were not available or approved for the client. Another team was tasked with implementing a solution to act as a gateway. This solution would be a web service that the Azure application would call to access this gateway.

SQL Agent Jobs

SQL Agent Jobs allow for out-of-process data manipulation. A couple of the applications used these to send notification emails at night or to synchronize data from another source. While there are several options in Azure for recreating this functionality such as Azure Functions and Logic Apps, we chose to use WebJobs. WebJobs can be triggered in several ways including a Timer. The jobs didn’t require intensive compute resources so it could share resources with the application in the same Azure App Service. This simplified the deployment story because it could be packaged and deployed together.
SQL Agent Jobs
Database modifications tend to be one of the major parts of the migration project. Some of the projects have been simple T-SQL changes while others have needed heavy architectural changes to reproduce functionality in a PaaS environment. Despite the difficulties, there will be major cost savings for some of the clients because they no longer need to maintain an expensive, possibly underutilized, server. Future posts in this series will cover Automation & Deployment, Session State, Caching, Transient Fault Handling, and general Azure lessons learned.

Sound Familiar?

It’s not a sentiment you would expect from most IT decision-makers. However, it’s something we hear from an increasing number of organizations.

The benefits of a well-thought-out cloud transformation roadmap are not lost on them.

  • They know that, in an ideal world, they ought to start with an in-depth assessment of their application portfolio, in line with the best practice – “migrate your capabilities, not apps or VMs”.
  • They also realize the need to develop a robust cloud governance model upfront.
  • And ultimately, they understand the need to undertake an iterative migration process that takes into account “organizational change management” best practices.

At the same time, these decision-makers face real challenges with their existing IT infrastructure that simply cannot wait months and years for a successful cloud transformation to take shape. They can’t get out of their on-premises data centers soon enough. This notion isn’t limited to organizations with fast-approaching Data Center (DC) lease renewal deadlines or end of support products, either.

So, how do we balance the two competing objectives:

  • Immediate need to move out of the DC
  • Carefully crafted long-term cloud transformation

A Two-Step Approach to Your Cloud Transformation Journey

From our experience with a broad range of current situations, goals, and challenges, we recommend a two-step cloud transformation approach that addresses both your immediate challenges and the organization’s long-term vision for cloud transformation.

  1. Tactical “Lift-n-Shift” to the Cloud – As the name suggests, move the current DC footprint as is (VMs, databases, storage network. etc.) to Azure
  2. Strategic Cloud Transformation – Once operational in the cloud, incrementally and opportunistically move parts of your application portfolio to higher-order Azure PaaS/cloud-native services

Tactical “Lift-n-Shift” to the Cloud

Lift n Shift Approach to Cloud Transformation

On the surface, step #1 above may appear wasteful. After all, we are duplicating your current footprint in Azure. But keep in mind that step #1 is designed for completion in days or weeks, not months or years. As a result, the duplication is minimized. At the same time, step #1 immediately puts you in a position to leverage Azure capabilities, giving you tangible benefits with minimal to no changes to your existing footprint.

Here are a few examples of benefits:

  • Improve the security posture – Once you are in Azure, you tap into security capabilities such as intrusion detection and denial of service attack solely by being in Azure. Notice that I deliberately did not cite Security Information and Event Management (SIEM) tools like Azure Sentinel. Technically you can take advantage of Azure Sentinel for on-premises workloads.
  • Replace aging hardware – Your hardware may be getting old but isn’t old enough for a Capex-powered refresh. Moving your VMs to Azure decouples you from the underlying hardware. “But won’t that be expensive, since you are now paying by usage per minute?” you ask. Not necessarily and certainly not in the long run. Consider options like Reserved Instance (RI) pricing that can offer an up to 80% discount based on a one- or three-year commitment.

Furthermore, you can combine RI with Azure Hybrid Benefits (AHUB) which provides discounts for licenses already owned. Finally, don’t forget to take into account the savings from decreased needs for power, networks, real estate, and the cost of resources to manage all the on-premises assets. Even if you can’t get out of the DC lease completely, you may be able to negotiate a modular reduction of your DC footprint. Please refer to Gartner research that suggests that over time, the cloud can become cost-effective.

AMP Move out of Data Center

Source –

  • Disaster Recovery (DR) – Few organizations have a DR plan setup that is conducive for ongoing DR tests. Having an effective DR plan is one of the most critical responsibilities of IT. Once again, since geo-replication is innate to Azure, your disks are replicated to an Azure region that is at least 400 miles away, by default. Given this, DR is almost out-of-the-box.
  • Extended lease of life on out of support software – If you are running an Operating System (OS), such as Windows Server 2008 or SQL Server 2008, moving to Azure extends the security updates for up to three years from the “end of support” date.
  • Getting out of the business of “baby-sitting” database servers – Azure managed instances offer you the ability to take your existing on-premises SQL Server databases and move them to Azure with minimal downtime. Once your database is an Azure SQL Managed Instance, you don’t have to worry about patching and backup, thereby significantly reducing the cost of ownership.
  • Take baby steps towards automation and self-service – Self-service is one of the key focus areas for most IT organizations. Once again, since every aspect of Azure is API driven, organizations can take baby steps towards automated provisioning.
  • Get closer to a data lake – I am sure you have heard the quote “AI is the new electricity”. We also know that Artificial Intelligence (AI) needs lots and lots of data to train the Machine Learning (ML) algorithms. By moving to Azure, it is that much easier to capture the “data exhaust” coming out the applications in a service like Azure Data Lake. In turn, Azure Data Lake can help turn this data into intelligence.

Strategic Cloud Transformation

Strategic Cloud Transformation

Once you have completed step #1 by moving your on-premises assets to the cloud, you are now in a position to undertake continuous modernization efforts aligned to your business priorities.

Common approaches include:

  • Revise – Capture application and application tiers “as-is” in containers and run on a managed orchestrator like Azure Kubernetes Service. This approach requires minimal changes to the existing codebase. For more details of this approach, including a demo, read Migrate and Modernize with Kubernetes on Azure Government.
  • Refactor – Modernize by re-architecting to target Platform as a Service (PaaS) and “serverless” technologies. This approach requires more significant recoding to target PaaS services but allows you to take advantage of cloud provider managed services. For more information, check out our “Full PaaS” Approach to Modernizing Legacy Apps.
  • Rebuild – Complete rewrite of the applications using cloud-native technologies like Kubernetes, Envoy, and Istio. Read our blog, What Are Cloud-Native Technologies & How Are They Different from Traditional PaaS Offerings, for more information.
  • Replace – Substitute an existing application, in its entirety, with Software as a Service (SaaS) or an equivalent application developed using a no-code/low-code platform.


The following table summarizes the various approaches for modernization in terms of factors such as code changes, operational costs, and DevOps maturity.

Compare App Modernization Approaches

Azure Migration Program (AMP)

Microsoft squarely aligns with this two-step approach. At the recent Microsoft partner conference #MSInspire, Julia White announced AMP (Azure Migration Program).

AMP brings together the following:

Wrapping Up

A two-step migration offers a programmatic approach to unlock the potential of the cloud quickly. You’ll experience immediate gains from a tactical move to the cloud and long-term benefits from a strategic cloud transformation that follows. Microsoft programs like AMP, combined with over 200+ Azure services, make this approach viable. If you’re interested in learning more about how you can get started with AMP, and which migration approach makes the most sense for your business goals, reach out to AIS today.