Azure Virtual Datacenter:Lift and Shift GuideIdentify and plan the migration of applications andservers to the Microsoft CloudBy David Read, Thuy Le, Mark Ozur, Tycen Hopkins, and Ed PriceAzure Customer Advisory Team (AzureCAT)2018

Azure Virtual Datacenter: Lift and Shift GuideContentsIntroduction .4Identifying potential lift and shift candidates .6Step 1: Capture application inventory . 7Operating System (OS) versions and patch levels. 7Application frameworks and third-party libraries . 7Device/infrastructure integration . 7Operations integrations . 7Availability SLA . 7Usage and utilization metrics . 7Backup/archive, high availability, and disaster recovery . 8Step 2: Verify operating system and platform support . 8Step 3: Verify runtime frameworks and third-party library support . 8Step 4: Identify any potential infrastructure requirements or challenges . 9Network connectivity and isolation requirements . 9Specialized networking . 9Special device/hardware integration . 9Storage . 9Step 5: Validate other criteria and create a preliminary list of candidates . 10Operations. 10Legal and regulatory requirements . 10Costs . 10Choosing the right deployment model . 11Use the correct Azure virtual machine sizes . 11Select the correct deployment patterns for your workload. 11Related services and features . 13Next steps . 13See also . 142

Azure Virtual Datacenter: Lift and Shift GuideList of figuresFigure 1. Multi-stage filtering process for potential lift and shift candidate applications . 6Figure 2. Comparing deployment patterns for application workloads . 12Authored by Thuy Le, David Read, Mark Ozur, and Tycen Hopkins from Microsoft Azure Customer Advisory Team(AzureCAT). Edited by RoAnn Corbisier and Ed Price. 2018 Microsoft Corporation. This document is for informationalpurposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. The names of actualcompanies and products mentioned herein may be the trademarks of their respective owners.3

Azure Virtual Datacenter: Lift and Shift GuideIntroductionLarge organizations often maintain a variety of well-established applications, resources, andservices that are used internally or by external customers. Traditionally, the hardware required tohost these resources was provided by physical datacenters, both on-premises and co-locatedexternally. This arrangement leaves an organization's IT department managing all the hardware,software, and network configuration tasks required to keep these datacenters up and running.The introduction of public cloud computing platforms offers IT departments a variety of newoptions for developing, deploying, and maintaining applications and servers. To review all theAzure Virtual Datacenter resources and tools, see the Azure Virtual Datacenter page on the AzureArchitecture Center. Servers, storage devices, and networking hardware previously requiredphysical assets and configuration, but they are now available as virtual devices and services thatcan be spun up or down on demand. Rather than requiring a large initial investment in physicalhardware, cloud computing allows organizations to use only the computing, networking, andstorage resources they need, when they need them. Cloud services also offer several scalabilityand availability options that are not available on physical hardware.A standard part of IT planning includes reviewing and leveraging the options available on thecloud, to drive down the required maintenance effort and total cost of ownership for yourinfrastructure. That planning starts with an understanding of how to deploy or migrateapplications or services into the cloud. Microsoft Azure Migrate offers a way to easily discover,assess, and migrate your on-premises virtual machines to Azure.The Microsoft Azure cloud platform includes platform as a service (PaaS) and infrastructure as aservice (IaaS) offerings. PaaS on Azure provides application hosting, storage, and databaseservices without needing to worry about the underlying server resources. The Azure platformhandles most of the hosting, networking, infrastructure, and configuration tasks required in atraditional datacenter. For example, you no longer need to patch your virtual machines or managevirtual machine operating system health. By offloading responsibilities, you greatly reduce theoperations and support effort needed to stand up and maintain an application or service.IaaS, on the other hand, allows you to create virtualized servers, storage, and networkinfrastructure, giving you a similar level of control over your cloud-based assets as you wouldhave over the hardware in an on-premises datacenter. Applications or services hosted on IaaSrequire more operations and maintenance than those running on PaaS (although still usually farless than that required for on-premises physical hardware), but they offer more flexibility in howthose applications or services are structured.Choosing the mix of PaaS and IaaS depends on the nature of the workloads you want to host onthe cloud. New applications or services are not bound by legacy infrastructure and can use agreenfield (cloud-native) architecture, which allows you to take advantage of the PaaS and IaaSfeatures from the beginning of the design process.However, if you built applications or services for an on-premises datacenter, you need to carefullyplan your migration to cloud services. You could invest a lot of development effort to refactorworkloads to take full advantage of cloud service offerings. In addition, your internal developmentteams might not have the ability to modify third-party or legacy applications.Your organization will want to minimize the amount of change required to get an application or4

Azure Virtual Datacenter: Lift and Shift Guideworkload migrated to cloud hosting. In these scenarios, the lift and shift migration model mightbe the right choice. For enterprise customers, the bulk of your application portfolio should besupported by a lift and shift migration model. A follow-up paper will discuss handling the edgecases and situations that don't fit this model.The lift and shift model involves moving your existing applications or services to Azure-basedvirtual machines, with an operating system and networking configuration as close to their currenton-premises configuration as is possible on a cloud platform. A successful lift and shift migrationtakes advantage of the infrastructure benefits and management features of the cloud, whileminimizing the both the migration cost and decreasing the time required to complete themigration.You should consider whether PaaS can be part of your lift and shift migration (for example, simpleweb applications migrating to Azure web app hosting), and you should not ignore these serviceswhen moving through this process. However, for existing complex applications built around theon-premises or physical datacenter model, making use of PaaS can require an extensiveretrofitting effort. This can potentially involve large development costs, which is what the lift andshift model tries to avoid.Because large preexisting enterprise applications tend to require more modifications to supportPaaS functionality, this document focuses on IaaS migrations, where you minimize the need forrefactoring by matching your existing hosting and network infrastructure. However, when youchoose between PaaS and IaaS technologies for migration, your decision might be based onmigration agility and speed. Which option gets your application running on the cloud? Whichchoice allows you to migrate the most applications and services within a window of time?Not all applications or services are a good fit for lift and shift migrations, and some that are a fitcan be more difficult to migrate than others. Hardware requirements, licensing issues, andincompatibilities might make running software on IaaS resources problematic. In many ways, theresearch and planning steps required for a conventional datacenter migration also apply to a liftand shift process, and any existing information and requirements gathering processes in place formigrations can also be applied to lift and shift.Identifying lift and shift candidates from your pool of applications requires a few steps. The firstpart of this document guides you through the information gathering process used to filter whichapplications will be easiest and most cost effective to quickly migrate to Azure IaaS.For those applications that are a good fit, migrating to Azure offers several benefits in resourceusage and scalability capabilities. The second part of this document discusses which deploymentmodel can best handle your application's resource requirements and usage patterns, and how tooptimize your costs based on those requirements.This guide is a starting point when considering the migration of existing applications and services.The processes described below are meant to be iterative. By working to identify a first round ofcandidates for lift and shift, you will build an understanding of what's required to host andmaintain applications in Azure, along with increasing the accuracy of cost estimates. Thisknowledge will make identifying subsequent candidates much easier.Note that the Azure platform is continuously adding features and services, and costs can change(generally lower) as new capabilities come online. Although applications and services might notbe candidates for lift and shift migrations now, they might be in the future, and any iterativereview process should take platform changes into account.5

Azure Virtual Datacenter: Lift and Shift GuideIdentifying potential lift and shiftcandidatesThe process of identifying applications suitable for a lift and shift migration is essentially a multistage filtering process. Your team will look at each application or service you are considering as acandidate for moving to the cloud, and then generate a list of all the hosting resources used bythe application, including both physical and virtual devices.The list of resources is used to assess the viability of hosting the candidate on Azure. Thisvalidation occurs in several increasingly detailed steps. Any application or service that doesn'tmeet the criteria assessed for a particular step in this process is moved to a separate list forapplications that require an alternative migration approach. Those that do meet the criteriaremain in the lift and shift migration candidate list and move on to the next step.Figure 1. Multi-stage filtering process for potential lift and shift candidate applicationsAt the end of this process, you should have a list of candidate applications you can successfullymigrate to Azure hosting with a minimal reengineering investment. At that point, you can beginto focus on how your application and service workloads can take advantage of cloud-specificdeployment models to optimize your use of cloud resources.6

Azure Virtual Datacenter: Lift and Shift GuideStep 1: Capture application inventoryFor each candidate application or service, have the teams responsible for hosting and maintainingit generate a full inventory of all dependencies. This inventory should not dive into extensivedetail about each resource, but it should be thorough in listing all types of resources used by thecandidate. It should focus on capturing key details about each resource type and what it does inrelation to the application or service.Although automated network detection tools and preexisting documentation will be a great helpin creating these lists, it is important to manually review lists of datacenter resources, up to andincluding inspecting the physical datacenter. Systems that involve specialized hardware or legacyapplications might have a lot of documentation that needs additional attention to make surenothing is missed.Note which servers are running on physical hardware vs. which ones are virtualized, as this canmake a significant and measurable difference in the effort required to migrate servers. Virtualizedservers have already gone through many of the steps required in a cloud migration, and tools areavailable to help migrate existing VMWare and Hyper-V virtual machines to Azure. Also note ifany software or licensing issues that require resources to run on physical hardware.In general, the inventory should capture the following information.Operating System (OS) versions and patch levelsFor any servers used by a candidate application or service, it is important to note the platform,operating system, version, and what patches have been applied.Application frameworks and third-party librariesFor any software that is a part of your candidate application or service, identify any applicationframeworks that are used, such as .NET or Java/JDK. Also make note of the framework version inuse.Similarly, take note of any third-party code or libraries used, along with the currently installedversion.Device/infrastructure integrationIdentify any network switches, routers, specialized load balancers, firewalls, or other devicesrequired to run your application or service. Note any specialized appliances or other hostinghardware, as well as any dedicated storage devices.Operations integrationsList any automated agents or other processes providing monitoring, security, and notificationcapabilities for your applications, services, or network infrastructure. If there are manual processesinvolved in maintaining your system, note these as well.Availability SLAFor each resource, document expected SLA and uptime requirements.Usage and utilization metricsCollect any usage and hardware utilization information for your server resources. Includeinformation about both nominal and peak loads, and note any predictable patterns of usage, such7

Azure Virtual Datacenter: Lift and Shift Guideas high traffic during particular dates or at specific times of day.Backup/archive, high availability, and disaster recoveryDocument how resources are backed up, and note archiving and retention policies. Note theinfrastructure in place to meet required availability SLAs, and list what disaster recovery policiesand practices are in place, including recovery point objectives (RPO) and recovery time objectives(RTO).Step 2: Verify operating system and platform supportAzure supports a wide range of guest OS images, including both Windows and Linux options.However, that support is not limitless. You'll need to check if the list of OS versions you recordedin your inventory are all supported.Consult the list of Azure endorsed Linux distributions to see the officially supported Linuxdistributions that qualify for the standard Azure platform SLA. See Information for Non-EndorsedDistributions for more details on the minimum requirements to deploy a custom Linux guest OS.For Windows servers, the Azure Marketplace provides supported preconfigured images forWindows Server 2008 R2 and later. Using custom guest OS images, you can deploy older versionsthat date back to Windows Server 2003. However, Windows versions past their end of supportdate require a Custom Support Agreement (CSA).Some Windows Server roles and features, like DHCP server, Hyper-V, and BitLocker data driveencryption, are not supported on Azure guest virtual machines. See the full list of Microsoft serversoftware support for Microsoft Azure virtual machines for details. Also note that while these rolesand features might be not supported within Windows server virtual machines, almost all thefunctionality they represent can be supported using other Azure-based services or applications.Consider whether you can migrate software that is hosted on legacy or unsupported operatingsystems, to newer Azure-supported versions, without requiring substantial changes or customdevelopment. If not, then that application or service should be moved to the alternative migrationapproach list, while the remaining potential lift and shift candidates move to the next step.Step 3: Verify runtime frameworks and third-party library supportTied together with OS support, you will need to validate whether any application runtimes andrelated technologies, used by the candidate application or service, are supported on Azure. Thisincludes making sure the currently used version of common frameworks, like .NET and Java, willwork. In addition, any third-party libraries used also need to work properly on the target OSversion.You must be diligent on this issue, as upgrades to OS, frameworks, and libraries can introducecascading dependency issues that can be very difficult to deal with in the migration process. Aswith OS support, if older frameworks and libraries cannot be upgraded to support the Azureenvironment without substantial changes to your application or service, then move thatapplication or service to the alternative migration approach list before moving the remaining liftand shift candidates to the next step.8

Azure Virtual Datacenter: Lift and Shift GuideStep 4: Identify any potential infrastructure requirements or challengesAfter you determine that a candidate application or service can operate as an Azure guest virtualmachine, the next step is to identify any other technical concerns with hosting resources on Azure.This stage can require in-depth research to compare Azure capabilities with your current onpremises infrastructure, ensuring all the features and services required for the candidate areavailable on Azure.If the infrastructure requirements of a candidate can't be met on Azure without unacceptableamounts of modification and cost, move that application or service to the alternative migrationapproach list.Each organization, application architecture, and datacenter can have a unique infrastructure, sothe list of potential issues to research will be unique to each of your candidate applications orservers. That said, many of the most common infrastructure challenges can be broken into thefollowing broad categories.Network connectivity and isolation requirementsHow do resources within your candidate application or server communicate with each other andthe outside world? Is the candidate meant for internal use only? Will users need to access it overthe public network? What kind of routing and firewall capabilities do you need?The Azure Virtual Datacenter provides a comprehensive approach to maintaining your overallgovernance, security, and network design. Can the existing Azure Virtual Networks and networkvirtual appliances support your needed capabilities?Also, does the candidate application or service have any dependencies on resources that will needto remain hosted on-premises, or at another datacenter or cloud location? Will on-premisesapplications, services, or users need to use the candidate from within your local on-premisesnetwork? Can Azure connectivity solutions, such as ExpressRoute or VPN connections, supportthese requirements?Specialized networkingDoes your existing infrastructure depend on specialized networking capabilities (such as multicast,Relocatable VIPs, Custom overlay networks, and so on)? Are these capabilities supported in AzureVirtual Networks?Special device/hardware integrationAre there any specialized hardware devices that the candidate application or service needs toutilize (such as a Telephone/PBX or physical security device)? Are there equivalent virtual devicesor appliances to provide this capability on Azure?StorageWhat are your overall storage requirements? Here are some common questions: How much total storage capacity do you need?Do you need to share disks between virtual machines?Do your virtual machines require high amounts (for example, greater than 50 TB) ofattached storage?9

Azure Virtual Datacenter: Lift and Shift Guide What kind of latency is acceptable for attached storage? Is ultra-low latency arequirement?Can Azure Storage, Managed Disks, and VHD files used in attached storage, support theserequirements?Also take into account the organizational and legal requirements for archiving, and long-termstorage retention for the candidate application or service. Can the policies be supported in Azure?Step 5: Validate other criteria and create a preliminary list of candidatesAt this point, you should have a high level of confidence that your remaining list of applicationsand services, on a technical level, are good lift and shift candidates. However, from an operationsperspective, less explicitly technical criteria can be just as important in deciding if a migration isjustified.OperationsIf a candidate is successfully migrated to Azure, how much will your operations processes need tochange? Here are some common concerns: How will your backup and recovery mechanisms need to change when resources arehosted on Azure? Will your disaster recover planning need to be modified? Will existing monitoring tools work in the new environment, and, if not, how much workwill be required to identify and implement an alternative approach? Will your existing high-availability architecture translate to Azure? Will existing DevOps tools and processes need to be modified?Legal and regulatory requirementsAre there legal or regulatory compliance concerns related to your application or service, such asprivacy laws or data retention requirements? As with any migration plan, you will likely need toconsult your organization's legal compliance team to thoroughly vet the lift and shift process foryour candidate applications and services.CostsUltimately, a migration is a business decision, and if the cost of moving to the cloud can't bejustified, there's no point moving forward. The initial migration involves one-time costs related tosetting up your Azure environment and migrating applications and services. However, aside fromthese migration costs, you must understand the ongoing operations costs required to host yourapplication or service.You should now have a good idea about the number and type of resources you will need onAzure to migrate your candidate application or service, and these should allow you to build costestimates for the migration. To understand ongoing costs, review and verify any assumptions youhave about operations and the related support tasks. Azure has extensive capabilities to scaleyour application resource needs. As part of this review process, consider the deployment modelsdiscussed in the following sections to optimize your Azure resource usage.With this information, you can generate quality cost estimates for hosting and maintaining yourcandidate applications and services.10

Azure Virtual Datacenter: Lift and Shift GuideChoosing the right deployment modelIn a physical datacenter, the initial costs (notwithstanding depreciation models) of purchasing andconfiguring hardware, can be very large in comparison to ongoing operations expenses. Yourpeak loads might be much higher than most operations, and some workloads may only beneeded occasionally. However, you still need to purchase and operate all the server hardwarenecessary to handle these higher loads.On a public cloud platform, there is no hardware to purchase and no upfront costs to create anew virtual machine. You pay for the compute, storage, and networking resources you actuallyuse. Virtual machines that aren't needed for a specific time can be shut down to save computeand networking costs, and you can start them back up when they are needed. You can spin upadditional virtual machines during high-traffic or special events like Black Friday or month-endprocessing. You can resize individual virtual machines to provide additional capacity, and whenthe load diminishes, you can spin them down again. Azure Cost Management can help youoptimize what you spend on the cloud, while maximizing cloud potential.The lift and shift migration model moves your applications and services to the cloud with as littlemodification as possible. However, you will save a lot on your ongoing costs if you properlyunderstand your resource utilization and pick the best deployment model to use when youmigrate resources.Use the correct Azure virtual machine sizesThe first step to optimize your Azure resource usage is to understand the capabilities of yourexisting hardware. Use that information to select the best Azure virtual machine size to handlethat load. Larger virtual machines cost more to run, so make sure you use the right size for yourworkload.Consider the age and utilization levels of your current hosting platform. It is possible that aCompute core on Azure is materially faster, requiring fewer cores than your current deployments.Make good use of any utilization data you have on your existing hosts or virtual machines toidentify performance requirements. Note the nominal and peak usage on each server and mapthese to an appropriate virtual machine size: Sizes for Windows virtual machines in AzureSizes for Linux virtual machines in AzureVirtual machines can easily be resized, so after deployment to Azure, continue to monitor andtune your usage assumptions to make sure you're using the correct virtual machine sizes, as yourloads change over time.Select the correct deployment patterns for your workloadThe simplest way to set up an IaaS application or service in Azure is to create a fixed number ofalways-on virtual machines, in sizes capable of handling your peak usage requirement. This willhandle your needs, but it imposes the costs of operating at peak capacity at all times.One of the key advantages of IaaS on the Azure platform is the ability to scale your virtualmachines as your needs change. You can reduce costs by adding or removing additional virtual11

Azure Virtual Datacenter: Lift and Shift Guidemachines instances, or by increasing the capabilities of existing virtual machines.Figure 2. Comparing deployment patterns for application workloadsFor each application or service that you are planning to migrate to Azure, review the followingdeployment patterns to see if you can use them to optimize your resource utilization withoutrequiring any significant changes to the applications themselves.Horizontal scale out/inHorizontal scaling involves spinning up additional virtual machines to handle increased demandon your application or service. When the demand declines, these additional virtual machines arespun back down to reduce resource usage.This pattern is well suited for stateless applications, such as the web tier of an n-tier application,calculation services, or other processes that handle independent transactions. Applications thatalready make use of a load balancer are usually good candidates for this pattern.Vertical scale up/downVertical scaling involves increasing the size of individual virtual machines to handle increaseddemands. When the demand decreases, the virtual machine size is decreased. If workloadincreases are predictable (for example, based on a specific day each month), vertical scaling canbe scheduled to increase the virtual machine size during that period of time. Scaling can also beset to happen dynamically, bas

Azure Virtual Datacenter: Lift and Shift Guide Identify and plan the migration of applications and servers to the Microsoft Cloud By David Read, Thuy Le, Mark Ozur, Tycen Hopkins, and Ed Price