Azure Migration Guide — Microsoft Azure Openhack: Migrating workloads to Azure
Another Microsoft Openhack, this one came quick off the heels of the DevOps Openhack. It was useful to validate the steps and processes involved in a successful Migration to Azure.
I took some notes throughout the 3 days, which quickly snowballed into a rather lengthy migration guide!
The guidelines detailed below outline the steps to migrate to Azure from on-premises or datacentre, and point out some general things to take into account at each stage for anyone looking to migrate workloads to Azure.
All successful migrations require serious thought at the planning and assessment stages. Points to consider:
- Choose the tools and technologies you will use to migrate the existing servers to Microsoft Azure. (Azure Migrate or Azure Site Recovery) and (Data Migration Assistant DMA tool or Azure Database migration service).
- Choose the tools and technologies to show server application dependencies (Azure Migrate agentless discovery)
- Choose the tools and technologies you will use to migrate any existing on-premises identities (users and groups) to Microsoft Azure. (Azure AD Connect)
- Choose and design the target topology for any migrated servers in Azure, including resource groups, virtual networks and subnets, and any other Azure resources required to execute the migration.
- How much will the migration cost (Pre-assessment budgetary cost — Azure Cost Calculator, more accurate cost provided after Azure Migrate Assessment, this will include bandwidth, month end processing etc.)
2. Assess Workloads for Migration
Setup the Azure Migrate service in Azure in order to assess the VMs to be migrated, view dependencies, resize VMs appropriately, and estimate cost…but first prepare the server you will be migrating from and setup the user accounts with required access. In the Openhack we had a Hyper-V server. The steps for this are outlined in the tutorial below:
- Prepare the Hyper-V server for migration (run a script provided in tutorial link)
- Create user accounts with appropriate access
- Setup Azure Migrate and download the appliance to the VM server.
- To setup dependency visualisation for Hyper-V servers the dependency agent will need to be installed manually (it can be done agentless with VMWare).
- Ensure the network design limits communication between application tiers to only the required ports and protocols while limiting lateral movement within the network (use network security groups)
3. Implement Hybrid Identity
Implement Azure AD (AAD) Connect to sync on premise AD identities to AAD.
You can sync AD identities with a .local domain, but when synchronised they will appear as an onmicrosoft.com address in Azure AD. Ideally you should setup a vanity domain and sync using that — you can purchase one direct through Azure. Once purchased, add it to Azure AD custom domains, verify it and make it the primary domain. This will involve updating Azure DNS with the TXT or MX record shown in the Azure portal.
Once your custom domain is setup, you should run the IDFix tool to correct any errors with existing identities.
You are then ready to install AAD connect and start syncing the identities to Azure!
AAD Connect should not be installed on a domain controller, it should be installed on a separate domain joined server.
User groups required to install and configure AAD Connect are ‘Enterprise Admin’ and ‘Global Admin’ in AD.
Using Domain and OU filtering:
AAD Connect does not have a supported HA topology, however a Staging server can be deployed:
AAD Connect supports multiple authentication models, including password hash synchronization (PHS) and pass-through authentication (PTA):
In either case, on-premises identities are synchronized to AAD using AAD Connect and UPNs will remain consistent.
4. Implement hybrid networking and resilient authentication
Establishing hybrid connectivity between on-premises and Azure will allow domain controllers to be placed in Azure, making infrastructure for allowing users and service accounts to authenticate to Active Directory more resilient. Having domain controllers in Azure will also reduce latency for authentication to the domain.
- Resiliency should include the ability to continue to authenticate to the domain should any hybrid connectivity fail (Setup 2 DCs in Azure)
- High availability includes the ability to continue to authenticate should a single domain controller not be available. (Setup 2 DCs in Azure)
- To ensure the domain is available, a minimum SLA of 99.95% of virtual machine availability is required for any domain controllers hosted in Azure. (Setup 2 DCs in an availability set in Azure)
Best practice guidance on DCs in Azure:
To create a VPN connection between Azure and on-premises use the following guide:
- The VPN connection should implement IKEv2 encryption. (use a route based configuration for the VNET gateway)
- Consider EXPRESSROUTE for larger scale deployments with a requirement for high-bandwidth / low latency.
- In the Openhack a legacy RRAS server existed on-premise, this should ideally be replaced in favour of an appliance (e.g. firewall, dedicated VPN gateway). If you are using an RRAS server there is a guide below:
5. Test migration
By validating not only your architecture but also your approach, you can make sure that trust is built with the business, and the business is a partner in the move to the cloud.
This will require testing in isolation so that the existing on-premises environment is not impacted. As part of this, testing can be conducted, feedback can be provided, and the migration can be performed as many times as needed if required.
Once the Hyper-V server is registered with Azure migrate, start the replication process so the disks copy up to Azure. Once that’s done you can perform a test migration to spin up the servers. Its best to do this to an isolated VNET as not to effect production. You can replicate the production VNET and subnets / NSGs to provide an isolated environment for the test, you could also even stand up a domain controller here to enable authentication for the other servers on the test network
Once happy with the test migration, its also a good time to think about introducing PaaS services (like a load balancer in front of the web servers for example).
The run command may be useful here for using PowerShell to execute scripts on the VMs for testing.
6. Finalise migration
Planning for the final migration in the Openhack consisted of the following pre-migration steps:
- Validate that the on-premise VMs are healthy
- Validate that the on-premise database is healthy, and check consistency.
- Plan the order of the server migration.
- Consider using traffic manager in front of applications with a priority routing method. This will enable you to point the traffic to the on-premise services, then you can manually switch the priority of the record once you are happy the machine have been migrated, maximising uptime.
Go ahead and Migrate!
If you check the option during migration the on-premise servers should auto-shutdown during the process.
Once migrated its wise to check the following:
- check traffic manager is switched to point to the Azure URL
- change the backend pools of any load balancers to point to the newly migrated servers
- check database disks are attached to VM, and that they are showing in the OS (they may need to be brought manually online).
- check services are up, including that the database is running.
- check the DNS entries on the DNS server point to the new IP addresses in Azure (there may be static entries!)
Once those checks are complete, you can test the app!
- test app
- test network segmentation
- test Server administrators can access all the migrated servers
- turn off any connection to on-premise, then test app still works
Finally if you are happy, follow the post-migration guidance here to clean up:
7. Transition to platform database services
Migrating from IaaS databases to an Azure PaaS offering will offload hosting responsibility to Azure, and have other benefits such as making Azure responsible for managing database performance, applying patches, and taking backups. It will also reduce costs, improve scalability, availability and efficiency.
Data Migrate Assistant tool can be downloaded from the Azure Migrate area. Run the tool on the database server, and any incompatibilities between IaaS and PaaS will be flagged. The data can be uploaded from the tool into Azure Migrate. If incompatibilities are flagged, the database could be moved to an Azure managed instance, or left running on an IaaS VM.
Consider the following:
- Ensure the database service in Azure is as secure as the on-premises (and now Azure IaaS) implementations are.
- When evaluating services, select the most cost-effective solution.
- The service SLA.
- Downtime during migration.
- Database backups must be retained for at least 30 days within any PaaS service.
- Administrators should have access to manage any Azure resources related to the database service and databases, but not the data in the databases.
- Database Admins should have access to any database-related resources, but not any server-related resources.
- The platform service must be compatible with the existing applications, including the existing database schema and consumed features. (Run DMA tool to check this).
- The platform service should perform as well as, if not better than, the existing IaaS SQL server.
- Before any data is migrated to a platform service, a formal assessment must be generated which shows that the databases will be compatible with the selected service.
- Database backups should be retained for at least 30 days for each database.
- The platform service must limit ingress and only allow known administrators and network segments to access the database.
- Access to the management plane of any Azure resources created to support the databases for the applications is constrained to the required security groups.
8. Transition to platform web-hosting services
With the Database migrated to PaaS, the web app migration is the next port of call. You can check your app compatibility with Azure PaaS web apps here:
- Ensure SSL is enabled
- Ensure the same URL is used for the app, this may need adding as a custom domain for the web app and the DNS repointing.
- Ensure the selected app service platform is appropriate for the app (Linux / Windows)
9. Secure, optimize, and operate
With everything migrated, this stage is really about utilising the tools available in Azure to their fullest to scale, secure, monitor and operate the services in the most efficient manner.
For a couple of examples, real-time performance of the migrated web app and database for example can now be viewed directly through the portal. For further web app monitoring, app insights could be enabled:
Azure monitor can be used to alert on service health or resource failures.
By following the steps and guidance above, you should be able to perform a well structured Migration to Azure!
Check out Openhack notes from my colleague Jonnychipz for further guidance!
Microsoft Openhack - Migrating Workloads to Azure - Day 1
Today was Day 1 of 3 of the Microsoft Openhack - Migrating Workloads to Azure If you aren't familiar with the concept…
Microsoft Openhack - Migrating Workloads to Azure - Day 2
Today was Day 2 of 3 of the Microsoft Openhack - Migrating Workloads to Azure. Thge following screen shots and examples…