The set-up of Azure Migrate is relatively simple, but enterprise-scale migration is not. This blogpost explains how to navigate key challenges and make good use of the tool for a successful cloud migration.
With enterprise organisations increasingly embracing public cloud for more of their IT estate, many are facing substantial data centre exits. Moving applications and workloads from a data centre to the cloud en masse is a complex undertaking, but expert use of hyperscaler tools can help. For organisations moving to Microsoft Azure, the Azure Migrate tool is commonly used to facilitate the task.
Azure Migrate’s core functionality centres on ‘rehost’ migrations, widely known as ‘lift and shift’. For many enterprises, the tool is their first experience of public cloud outside of software-as-a-service (SaaS) offerings like Microsoft 365 and EntraID. Consequently, there’s a widespread assumption that it offers a quick and easy route to cloud. In reality, several manual steps are required before and after the replication of assets, which increases the risk of error.
So, what’s involved and how can enterprises use Azure Migrate to move vast amounts of data to the cloud without unintended consequences for business stability or security?
Under the Hood of Azure Migrate
Azure Migrate handles the discovery and assessment of workloads prior to migration, as well as the migration itself. It consists of a set of infrastructure components – Azure Migrate Project, Key Vault, Storage Account and Recovery Services Vault – which are held in the target Azure environment. These components are not billed for the first 180 days of use, which should be ample to complete a migration. However, additional on-premise appliances are required to collect the necessary data and orchestrate the migration. Since Azure Migrate Project is a unique resource without native Terraform or Bicep templates, it is difficult to automate and scale these activities.
Optimising the Discovery and Assessment Phase
During discovery and assessment, Azure Migrate identifies dependencies between applications, as well as determining whether VMs are suitable for the Azure cloud platform.
There are two flavours to discovery: agent-based and agentless.
Agentless discovery is often positioned as a quicker approach, with information obtained via communication with application programming interfaces (APIs). However, this method requires elevated privileges. What’s more, the Azure Migrate appliance needs direct network connectivity to Active Directory domain controllers to authenticate each VM that needs to be discovered. VMs hosting web apps and SQL databases also need direct network connectivity from the appliance. Both requirements can pose challenges in situations involving multiple Active Directory domains, or where on-premise workloads are distributed over various segmented networks. These scenarios can result in multiple appliances being required and may also necessitate on-premise firewall changes to support the discovery process.
Agent-based discovery requires the installation of code onto VMs, which can be seen as a more arduous approach. But it overcomes the above challenges associated with agentless discovery and can gather deep, direct insights from complex systems. We often recommend it as a more robust option for enterprise migration projects. What’s more, once an agent is installed on the VM, it has the added benefit of providing richer network connectivity analysis. This includes User Datagram Protocol (UDP) traffic, ensuring applications communicating over this protocol are detected.
Once the discovery process is complete, Azure Migrate generates a migration readiness assessment. However, this is only based on VM size (in terms of central processing unit, memory, and disk). It doesn’t account for other important factors such as network connectivity or installed software that may not be supported on Azure. For this reason, we advise automating and extending the collection of discovery data to generate a more reliable and accurate migration readiness assessment. It’s worth noting here that it is possible to use Azure Migrate solely for the discovery phase. If the process reveals a high level of complexity, it may be better to modernise applications and opt for a refactor migration rather than a simple rehost.
Setting the Stage for Success on Azure
Whether the migration follows the rehosting or the refactoring model, it’s best practice to deploy applications onto an Azure Landing Zone. This should align with Azure’s Cloud Adoption Framework (CAF) and Well-Architected Framework (WAF). Backup, disk encryption, and monitoring and alerting should also be automated to meet organisational compliance requirements. After a rehost migration, VMs can be transitioned onto more modern, cloud-native alternatives to improve lifecycle management and developer experience on Azure.
For added security, Azure Migrate offers the ability to replicate VM disk data through a private endpoint, avoiding the need to migrate data over the public internet. As with all private endpoint implementations, this has a heavy burden on private domain name system (DNS) resolution. An alternative is to set up the required platform changes to enable migration of VM disk data over a private link and Azure Landing Zone network architecture that meets specific security or compliance requirements.
When it comes to the migration of relational database management systems such as Microsoft SQL Server, it’s worth considering alternative tooling. While Azure Migrate can handle the full process from discovery and assessment to migration, a specialised tool such as Azure Database Migration Service may be more suitable.
Once applications are migrated onto Azure, expert cloud engineering is required to unlock the platform’s key benefits. Most enterprise teams benefit from ongoing support as in-house engineers build confidence and new capabilities. Working with a managed services partner can accelerate progress, allowing in-house teams to upskill over time via mentoring and collaboration with experienced cloud engineers.
Cloud Experience and Expertise On-Tap
We’re seeing a significant surge in enterprise organisations undertaking largescale data centre exits. It’s partly due to widespread acceleration of cloud adoption as enterprises look to leverage the powerful, scalable data capabilities that are so beneficial to modern business. Other contributing factors include VMWare’s decision to end perpetual licensing and switch to a 100% subscription model. Optimising IT spend and reducing total cost of ownership is always a priority, so when data centre renewals come round licensing costs inevitably face scrutiny.
Whatever the driver, data centre exit is typically a one-off, time-critical event. For organisations moving to the Azure cloud platform, Azure Migrate is an excellent tool to facilitate the journey. Nevertheless, the points outlined above are a mere snapshot of the complex considerations likely to be encountered during the process.
Sourced Group (Sourced) an Amdocs company has a strong track record partnering with organisations moving to the cloud. Our familiarity with Azure Migrate and other relevant tools enables us to devise efficient, effective approaches, overcoming problems if they arise. We’ve compiled migration runbook templates and infrastructure-as-code (IaC) modules incorporating Azure best practices and our own learnings from enterprise migrations. For the longer-term cloud journey, our managed services offering helps customers optimise costs and security while maximising business value.
We can navigate your cloud migration and onward journey, allowing you to focus on other business priorities. Contact us here to book a consultation.
For more information, contact us as enquiries@sourcedgroup.com
