Migrating from on-premises to the cloud is often fraught with unexpected problems, which can easily lead to unexpected expenses as well. What appears to be a simple act of lifting and shifting servers and data into virtual infrastructures becomes bogged down in a morass of issues—followed by demands to repatriate services back to your data center.
Chalk it up to a fundamental disconnect between on-premises architectures and cloud architectures. On-premises systems are all about getting the most out of hardware, often running a single service on a single server. The cloud is very different, and performance is less of an issue. Instead, cloud providers like Azure aim to take advantage of economies of scale, running multi-tenant hosts that use hyperscaling techniques to ensure that servers run at close to capacity at all times.
If you simply replicate the specifications of an on-premises server in the cloud, you will quickly find you’re on one of the higher-priced plans, paying for unused capacity. A far better approach is to optimize your server images to keep costs in check, taking into account cloud-native design principles without completely rearchitecting your virtual infrastructure.
Lift, shift, and optimize for the cloud
Those changes are for the future, once your applications and data have moved out of your data center. The switch from capital to operational expenditure can be used to fund longer-term redevelopment process, taking advantage of cloud-hosted platform services as an alternative to running your own servers.
Azure Migrate is a set of tools for desktops, servers, data, and web applications, all wrapped up in a single cloud-hosted portal. For large migrations, it includes access to Microsoft’s Azure Data Box bulk data transfer hardware. There’s even support for tools from a curated set of partner companies, providing additional assessment and migration services. Azure Migrate is free, though you will be billed for storage and for compute when running tests. Third-party tools may well have their own licensing requirements and will add extra costs.
It’s important to note that there are two versions of Azure Migrate. In most cases you would use the newest version. The old version, which only supports migrations from VMware virtual environments, will be removed in early 2024. The new version adds support for Hyper-V and bare-metal servers and provides tools for migrating from other public clouds to Azure. It also supports migrating Linux servers (with support for SUSE, Ubuntu, CentOS, Oracle Linux, and Red Hat Enterprise Linux) as well as Windows, and helps plan migrations of desktop systems using Azure to host VDI (virtual desktop infrastructure) environments.
The migration process itself is relatively simple. First there’s an assessment, then the actual migration. The first step will determine what servers are needed in Azure, the appropriate sizing for your workload, and if your candidates are ready for a migration from physical to virtual. The assessment allows you to start with an estimate of your cloud costs, so you’re not entering the process without knowing how your budget will be affected.
Beginning an Azure migration
At the heart of the process is a discovery and assessment tool that runs inside your network to find servers and applications that can be tested for use in Azure. You begin the process inside the Azure Portal, setting up an Azure Migrate dashboard and downloading the Azure Migrate appliance. This tool is used to run assessments inside your data center, and can be deployed in a VM or on its own dedicated server hardware. VMs are available for both VMware and Hyper-V.
The appliance uses standard management APIs to get data from your servers, so there’s no need to install agents across your network. This keeps any security risks to a minimum, as there’s little or no change to your data center attack surface. You have the option to use Microsoft’s Management Agent to get more detailed information, taking advantage of Azure’s log analytics tooling.
The Azure Migrate appliance first catalogs the servers in your network, delivering server data to the Azure Migrate service. Initially this is a raw list of servers, ready for you to put in groups. Groups allow you to define application infrastructures and migrate servers in batches. The catalog serves another purpose, as it can be used to identify where you can take advantage of licensing benefits to reduce costs, for example moving existing server licenses to the cloud rather than purchasing new ones.
Once you’ve run an initial discovery and grouped servers you can start a more detailed set of assessments. These identify servers and applications that are ready for migration as is, as well as identifying any dependencies that might affect a migration—for example, highlighting web apps that might share a single SQL Server instance. The process will suggest Aure VM sizes, along with any Azure SQL configurations that can be used as an alternative to SQL Server.
Next you can start to replicate servers in Azure, either moving a virtual machine copy or making a VM from your physical server. If you’re moving a physical server, you’ll need to install an Azure Migrate agent on the target servers. The same agent supports alternative hypervisors by treating them as physical servers.
Using a sandbox to check your work
Azure Migrate lets you test your migration in an Azure-hosted sandbox, which allows you to control access to the servers with limited access to its VNet. This reduces the risk of conflict with running services, while allowing you to test application operations and validate the migration before running a final update. You can run as many tests as necessary, allowing you to be sure that your services will migrate successfully, as there is no rollback to on-premises once a migration has completed. Don’t forget to clean up your test environment once you’re done, because you will be charged for its operation!
Once you’re happy with your test environment, you can run a full migration, replicating data servers and cutting over to the cloud once the migration is complete.
The main advantage to using a tool like Azure Migrate is that it builds on many years of experience with Azure migrations by Microsoft’s own consulting services. While it may not support some edge cases, it should simplify migrating most common enterprise architectures and web services to the cloud—while giving you much needed visibility into costs and expected budgets.