This document is primarily a mentor's guide that is intended to assist technical implementation consultants with the steps to begin onboarding an end customer or organization to Microsoft Azure. Leveraging the "Setting the Scene – Successful Migration Scenarios" documents, along with the structured checklist provided in the "Master Engagement Plan/Checklist" document, this guide is the typical process a consultant would go through to drive successful initial workload migrations.
This guide includes links to existing Microsoft technical step-by-step implementation resources and associated training materials that will help an implementation consultant of varying Azure experience and expertise to navigate the process of workload migrations to Azure. This document should be used as a reference guide to become familiar with Azure and the various possible migration options for workloads from onpremise to Azure.
One of the first steps an organization does in integrating an on-premise datacenter to Microsoft Azure is to stretch the on-premise datacenter network to Azure. This connectivity is accomplished through a Site to Site VPN, which provides a security boundary so that the servers and workloads running in Azure are integrated with the stretched network of the on-premise datacenter. The network in Azure appears as part of the on-premise network, allowing servers/VMs in Azure to be joined to the onpremise Active Directory and also allow servers/VMs in Azure to be patched, monitored and managed as if they were within the on-premise datacenter.
A virtual network is required for the Azure Virtual Machines running in the cloud to cross a VPN gateway and connect back to the on-premises network. If a Virtual Machine in Azure is not part of a virtual network, or if the virtual network does not have a gateway, the Azure Virtual Machine will still work but it will not be able to connect back to the on-premises network directly.
Starting with Step 1 of the Microsoft online documentation that shows how to "Create a VNet with a Site-to-Site connection using the Azure Portal," this guide walks through the creation of an Azure network and a gateway as well as the creation of the VPN tunnel.
With the Azure Virtual Network created and a site-to-site link established with the onpremises network, the first workload can now be migrated to Azure. For this example, a standalone IIS Web Server will be migrated. Once the Virtual Machine is created in Azure, creating the web server is identical to an on-premises server.
Following the guide, create a Windows Server 2016 Virtual Machine. This document walks through the creation of a Virtual Machine on the Azure Resource Manager as well as the networking of the Virtual Machine.
Once the virtual machine is created and online, it is accessible for remote access through the steps outlined in the creation document. A DNS entry should be made for the Virtual Machine in your internal DNS server to allow connectivity for testing purposes.
At this point, Windows Server roles and applications can be installed on the newly created virtual machine, such as installing Microsoft IIS through Server Manager (stepby-step documentation is available here if needed). With IIS installed and running, HTML code can be pushed to the server either over the Site-to-Site VPN from the onpremises network using a simple \\servername\sharename SMB connection or copying through the remote desktop session.
Once the web application and code has been installed on the server, the Virtual Machine can be tested to ensure functionality:
At this point, with a successful validation, the DNS name for the on-premises Web server (www, web, etc.) can be failed over to point to the Azure Virtual Machine to complete the migration and begin to have the Azure Virtual Machine serve requests rather than the on-premises server.
Now that there is a virtual network, a site-to-site VPN, and the first workload running in Azure, other functions can be explored.
Azure native options should also be explored as well. Options such as the Operations Management Suite (OMS) which can also be integrated with System Center Operations Manager (SCOM). These tools can handle log collection, monitoring, and system updates all within Azure itself.
Now that the first workload is working and some basic Azure functions have been covered, the second workload can be migrated. This example will be similar to the first workload, with the exception of this server being an IIS Server and with an integrated SQL Server backend on the same Virtual Machine. Follow the instructions in the first workload as far as building the Virtual Machine. This machine will need to be larger than the first workload because of the SQL Server, so this machine should be an A3 Azure instance or higher.
Following the previously mentioned guide here, create a Windows Server 2016 Virtual Machine on the virtual network previously created. Connect to the Virtual Machine, install Microsoft SQL Server, and install the Microsoft IIS role as done in the first workload (documented here). Backup the existing SQL database through SQL Server Management Studio. Copy the HTML code from the on-premises machine (documented here) to the Azure Virtual Machine over the network. Restore the database in SQL Server running on Azure and install the HTML code into IIS.
Once the database is mounted and the HTML code is installed, the Virtual Machine should be tested to ensure functionality:
Another common scenario for a second workload that could be targeted for the migration to Azure would be a two-server configuration that comprises of a Web server and a separate SQL server as part of the configuration. In this example, an IIS server with a SQL backend will be migrated, but SQL Server will be on a separate Virtual Machine. Overall, this configuration is not much more complicated than the first and second workloads we migrated. The only addition is needing to validate the network connectivity between the two machines.
Following the previously mentioned guide here, create two Windows Server 2016 Virtual Machines on the Virtual Network previously created. On the Virtual Machine created for SQL, install the relevant SQL Server version to the app being migrated. Backup the database from the on-premises SQL Server and restore it onto this Azure SQL Server Virtual Machine. On the Virtual Machine created for IIS, install IIS (documented here) and copy the HTML code from the on-premises workload being migrated. With everything now copied to the Azure Virtual Machines, test the workload functionality by accessing the Web server in the same ways the first and second workload were tested.
This migration method copies the Virtual Machines from on-premise to Azure using Azure Site Recovery (ASR). Virtual Machines are then failed over to Azure using the Test Failover feature to start the Virtual Machines in Azure and validate their functionality. There will be more setup involved here as either Hyper-V or VMware environments will need to be prepared to copy the Virtual Machine to Azure.
ASR setup and configuration guides, along with guides for different virtualized environments, are part of the content framework all program partners have access to. Please refer to those documents for more information on setting up ASR in different environments. Additionally, the following docs have instructions depending on the environment you are coming from:
Follow the guide that suits your environment to replicate the Virtual Machines to Azure. This example below assumes a Hyper-V environment with VMM, so please refer to that guide when reviewing the following steps.
In a potential initial migration scenario where the servers are standalone systems, there may not have been a need to add a Microsoft Active Directory domain controller in Azure if there's no AD authentication needed. However, as migrated workloads get more complex, the servers may need to be joined to Active Directory and/or having a domain controller in Azure may be required.
To add a domain controller in Microsoft Azure, it is simply a matter of creating a Windows Server Virtual Machine (matching the appropriate version of Window Server on-premise Active Directory domain controllers in the organization), and promoting the server to becoming a domain controller. The process of creating a domain controller in Azure is as follows:
It is at this point that the customer will have one or two workloads and likely an Active Directory Domain Controller (potentially 3-5 total Virtual Machines) running in Microsoft Azure. The customer should integrate these Azure Virtual Machines into their normal server and application administration & management process that includes patching, monitoring, and ongoing maintenance.
The links in this guide have not only shared deployment guidance, but also Microsoft Azure training resources that are helpful for customers who are new to Azure and are just getting up to speed on familiarizing themselves with the ongoing maintenance and management of Azure workloads.
With these initial workloads running in Azure, the next step is to quickly identify the next 12-15 servers that will be migrated to Azure, and continue on in advancing the migration of Virtual Machines to Azure via tools and automation.