Case Study - Line-of-business application migration - Model Answer

Preferred target audience

• James Lynch, CTO
• Relevant IT department heads under James (e.g. Head of Operations, Head of Application Development, etc.)
• Business application owners
• CFO - to understand cost implications, including the CapEx/OpEx switch
• CSO - to understand security implications

Preferred solution

Migration Assessment

1. How can Fabrikam assess their existing infrastructure for migration to Azure? Provide options for VMware VMs, physical servers, and databases.

   For VMware VMs, Fabrikam should use Azure Migrate to assess their readiness for migration to Azure. Azure Migrate supports migration assessment for VMware workloads managed by vCenter version 5.5, 6.0, 6.5 or 7.0. It also supports assessment of Hyper-V environments. Azure Migrate can be extended using third-party tools to provide additional assessment and migration capabilities, including assessment of physical servers.

   Azure Migrate is a fully-managed Azure service. Migration assessment occurs in two major phases: discovery and assessment. In the discovery phase, a collector appliance VM is deployed into the on-premises environment to gather raw data on the VMs to be migrated. This data includes static VM information (such as CPU, memory, disk configuration, OS and identification of key workloads such as databases) together with utilization metrics. These metrics are gathered over time, so it is important to gather data over a representative time period, especially for workloads with irregular usage patterns (for example, to generate daily, weekly or monthly reports).

   

   The collector appliance uploads the data it gathers to an Azure Migrate project in Azure. Each appliance supports discovery of up to 10,000 VMs on VMware vCenter Server or 5,000 VMs on Hyper-V.

   

   In the second phase, assessment, the data from the discovery phase is used to produce a migration assessment report. Each assessment supports up to 35,000 VMs, which may be drawn from multiple collectors. You can create multiple reports from the same source data, and tailor the report using a range of migration parameters. These parameters include:

   • Azure region and monthly uptime.
   • Whether to size VMs based on the existing VMware configuration, or on the measured utilization. In the latter case, a ‘comfort factor’ allows you to control how much headroom is included in the sizing recommendation.
   • VM pricing tier, disk storage tier, Azure subscription offer, and discounts such as re-using existing Windows OS licenses with Azure Hybrid Benefit and reducing base compute costs with reserved instances.

   

   Having configured the assessment, an assessment report is produced. This provides information on migration readiness, together with an estimate of both compute and storage costs.

   The migration readiness report categorizes VMs as ‘Ready for Azure’, ‘Ready with conditions’, ‘Not ready for Azure’ or ‘Readiness Unknown’, together with the reason why/remediation required. It also provides a suggested tool for migration execution, and a recommended Azure VM size.

   The compute and storage cost estimates are based on the migration parameters specified in the assessment configuration. Costs are based on the rate card for your subscription, taking into account any offers and subscription discounts.

   Azure Migrate does not support migration assessment of physical servers using the built-in assessment tool. However, it can be extended using a range of third-party tools, which do support physical server assessment. The Azure migration hub lists several examples to consider: Corent, Movere, Turbonomic and Cloudamize.

   For database migration, a range of assessment tools may be required depending on the database type.

   • For Microsoft SQL Server databases, Fabrikam should use the Microsoft Data Migration Assistant (DMA) to assess database migration readiness. This took provides a much deeper database analysis than provided by Azure Migrate, which focuses on entire VM migrations. SQL Server databases can typically be migrated to Azure SQL Database or Azure SQL Database Managed Instances, the latter offering greater compatibility with the on-premises SQL Server. For 100% compatibility, SQL Server in Azure VMs can also be used, however this foregoes the advantages of using a managed service and will require on-going VM maintenance. In each case, the DMA tool will examine the existing on-premises database and report any compatibility issues.

   • For PostgreSQL databases, there is no assessment tool similar or equivalent to DMA. PostgreSQL databases can be migrated to PostgreSQL running in Azure VMs, or preferably to Azure Database for PostgreSQL, which provides a managed service without the management overhead of IaaS VMs. The Azure Database Migration Guide states: “Microsoft aims to support the currently released major version (n) and the two prior major versions (-2), or n-2…if your on-premises PostgreSQL instance is running one of these versions, the database will be fully compatible, and the migration will be relatively straightforward.” Upgrading to an up-to-date PostgreSQL version may be a necessary prerequisite to migration.

   • For Cassandra databases, once again there is no assessment tool specialized to this scenario. Existing Cassandra databases can be migrated to Cassandra running in Azure VMs, or preferable to Azure Cosmos DB, which provides Cassandra compatibility together with the advantages of a fully-managed service.

2. How can Fabrikam identify dependencies between their existing servers? How can they use this information in their migration planning?

   Azure Migrate dependency visualization provides in-depth analysis of processes and network dependencies for each assessed VM. It is extremely useful for identifying non-obvious network dependencies, such as Kerberos, DNS, certificate revocation checks, and so on.

   

   Dependency visualization in Azure Migrate is based on the Service Map solution from Log Analytics, and can be used free of charge with Azure Migrate for up to 180 days (a dedicated Log Analytics workspace is required to avail of this discount). As part of Azure Migrate, dependency visualization is only available for VMware (and in Preview, Hyper-V) VMs. For physical machines, you can either use the Service Map solution from Log Analytics directly, or use the dependency analysis features of whichever third-party tool you have chosen for migration assessment.

   Deploying dependency visualization requires installing the Microsoft Monitoring Agent and Dependency Agent on each server being assessed. These are available for both Windows and Linux. Third-party tools will have different requirements, and may even support agentless dependency analysis.

   

3. What criteria should Fabrikam use to prioritize their migrations when building a migration road map?

   When kicking off a migration program, it’s important to start with some quick wins. This builds confidence and experience. The first services to migrate should be isolated, non-critical workloads without unusual technical requirements, for which migration should be very straightforward. Typical examples include marketing websites and internal tools.

   The migration road map should assess the workloads based primarily on business criticality and migration complexity. Complexity should be broken down into considerations of security, compliance, availability, scale, performance, manageability and costs. Also, the migration approach should be considered, with a straightforward ‘lift and shift’ offering fewer risks and a faster migration than a specialized refactoring or re-architecting of the existing application.

   Understanding application dependencies will play a big part in planning your migration roadmap. In general, tightly integrated applications should be migrated together. Where dependencies will span the Azure to on-premises network, be sure to understand the bandwidth requirements and the impact of a network outage or higher latency. Consider ExpressRoute in such cases.

   Resource availability will also be a roadmap constraint. This is especially the case for application modernization projects or any migration that cannot use a routine ‘lift and shift’ approach. Lift and shift migrations are generally repeatable processes that can be standardized and executed efficiently at reasonable scale, whereas other migrations are each unique projects that must be managed individually, and require dedicated resources.

   The business context of each migration also plays a factor in roadmap prioritization. For example, if the hardware used by an existing workload is close to end-of-life, an early migration may save on renewal costs. Likewise, a recent investment in an on-premises application may justify deferring the migration. Similarly, if the migration is intended to bring significant business benefits (for example, to provide a higher-availability deployment for a critical application), this can be grounds for prioritization.

   

4. What options can you suggest to migrate workloads whose current infrastructure is not suitable for a lift-and-shift migration to Azure?

   Where lift-and-shift re-hosting in Azure VMs is not possible, a different approach will be required. There are a number of options available.

   Firstly, consider if the workload can simply be retired. The application may have few users, and their needs may be met in other ways. Organizations build legacy over time, and it is common to identify some applications that can be retired when creating a migration roadmap.

   Next, consider if an off-the-shelf SaaS service can replace the existing application. Consuming SaaS services offers huge benefits by removing any responsibility for ongoing maintenance.

   These options should always be considered, even for applications that are suitable for lift-and-shift. If none of these are possible, some re-engineering will be required to enable the migration. The level of re-engineering will depend on both the existing technical implementation and the strategic value of the application to the business. Relatively minor re-factoring may suffice to migrate the application to run in Azure, for example using a Web App or in containers. Alternatively, major re-architecting or even a ground-up re-write may be chosen as a worthwhile investment in a strategic application that will be the focus of future investments. More information can be found on the Azure migration hub.

   Finally, there is always the option to retain the application on-premises. This can make sense if there is a scheduled end-of-life, or where there are technical or regulatory constraints that cannot easily be met any other way.

Migration Execution

1. What Azure components or configurations should be deployed prior to migration?

   Before migrating your first application, the Azure environment should be prepared. This includes:

   • Planning and creating Azure subscriptions
   • Planning the network: Azure virtual networks, including address spaces and subnets; network security devices such as Application Gateways or third-party devices; Active Directory and name resolution; on-premises connectivity
   • Defining best practices for Azure deployments, such as resource group structure, choice of region, use of templates, resource naming convention and use of resource locks
   • Defining governance controls, including identity and access management, role-based access, policy, blueprints, and cost management including internal charge-back and reporting
   • Planning operations for migrated workloads, including Azure Site Recovery, Azure Backup, Advisor, Security Center, update management, and monitoring

For more information, see the Azure Virtual Datacenter and Azure Enterprise Scaffold documentation in the Azure Architecture Center.

1. What tools are available for migration execution? Provide options for VMware VMs, physical servers, and databases.

   Broadly speaking, there are three approaches to a lift-and-shift server migration:

   • Create the Azure environment, including VMs, and re-install the application from scratch
   • Port existing disks to Azure, and stand up a new Azure environment using those disks
   • Use a migration tool to port the existing environment to Azure

   A clean install has the advantage of creating a clean target environment, free of any legacy. It is also an opportunity to perform upgrades, for example to a newer OS version. However, it requires knowledge of the installation process and access to installation tools, neither of which may be available in practice in the case of legacy applications. It can also be time-consuming, and may incur a longer application downtime than using purpose-built migration tools.

   Porting existing disks avoids the need to re-install the application. However, it can require extended downtime since it may be difficult to perform while the application is still running. Stateful servers should be ported as disks, whereas stateless servers should be ported as disk images, allowing multiple Azure VMs to be created from a single image. Data can be transferred either online using the AzCopy tool, or offline using the Azure Import/Export service or Azure Data Box.

   Disks must be in fixed-size ‘VHD’ format. Hyper-V VHDX format disks must be converted, using Hyper-V Manager or the Convert-VHD PowerShell cmdlet. Note also that only ‘Generation 1’ Hyper-V VMs can be ported to Azure in this way. VMware disks in VMDK format can be converted to VHDs using the Microsoft VM Converter tool. Physical disks can be converted using the disk2vhd tool from SysInternals, however this only supports Windows, not Linux.

   When porting disks, a number of OS configuration changes must be made to ensure the server is able to run in Azure. These include changes to network, power, time, remote access, and more. A full list of changes for both Windows and a range of Linux distributions is provided in the Azure documentation.

   The third approach is to use a dedicated migration tool. Azure Migrate will suggest an appropriate migration tool as part of its migration assessment report. For VMware VMs, excluding databases, Azure Migrate supports both agent-less and agent-based migration.

   The agent-less migration requires the Azure Migrate appliance to be deployed as an additional VM into the on-premises environment. This VM integrates with vCenter to replicate VMs to Azure, without requiring any agents to be installed on the VMs themselves.

   The agent-based migration is based on using Azure Site Recovery as the migration engine. This approach is also used for Hyper-V and physical server migrations. In this case the Azure Migrate replication appliance is deployed on-premises, comprising two processes known as the Configuration Server and Process Server. The Process Server handles data replication, while the Configuration Server is responsible for orchestrating the replication process. Both servers are typically deployed to a single VMware VM, although for larger environments separate VMs (or even multiple Process Servers) may be used. In addition, the Mobility Service (an agent) must be installed on the VMs being migrated.

   Choosing between agent-less and agent-based migration will require you to study the Azure Migrate support matrix for VMware and compare migration methods. For example, note that servers using UEFI boot are only supported by agent-based migration.

   Both approaches offer zero data loss with near-zero application downtime. This is achieved by replicating the source VMs while they are still running, only requiring a short downtime to perform an incremental replication of any very recent changes.

   Replicating VMs to Azure can require significant bandwidth, both for the initial replication and for ongoing incremental data synchronization. Data can be transferred either via the public Internet (encrypted using HTTPS), or for greater security and increased capacity via an ExpressRoute connection. The ASR Deployment Planner tool can be used to forecast the bandwidth required, which can help with the decision whether ExpressRoute is required.

   Once replication is complete, Azure Migrate will take care of creating the Azure VMs in the pre-prepared Azure environment. This process can be staged by grouping and sequencing VMs, and customized using pre- and post-deployment scripts. Azure Migrate also supports non-disruptive test failovers, which can be used to validate the migration steps.

   While Azure Migrate does not support assessment for physical servers, it does support migration, using the Azure Site Recovery migration engine. The approach and architecture are similar to that used for VMware VMs. Alternatively, a number of third-party migration tools is listed on the Azure Migration hub and integrated into Azure Migrate.

   For database migration, dedicated database migration tools should be preferred.

   For Microsoft SQL Server databases, the Azure Database Migration Service is recommended. This is a fully-managed service designed to streamline the process of migrating databases to Azure. It can scale to support multiple database migrations and migrate large databases. Two migration modes are supported: offline and online. Offline migration provides the simplest migration experience, but requires the application to be taken offline for the entire data replication process. Online migration synchronizes databases without downtime, giving a continual status of the number of pending changes. Once all changes are replicated, only a short downtime is required to cut over between databases.

   Azure DMS also supports migration of PostgreSQL databases to Azure Database for PostgreSQL. Small databases (under 150GB, for example) can also be migrated by using the pg_dump and pg_restore commands to bulk-copy the data.

   For Cassandra databases, data can be copied using the CQL COPY command, or by provisioning an Azure Databricks deployment and using the table copy operation. Instructions for both methods are provided on the Azure Database Migration Guide, at https://datamigration.microsoft.com/scenario/cassandra-to-cosmos?step=1. Alternatively, the same guide also includes a table of third-party migration tools, and suggests Imanis Data as a potential migration tool in this case.

2. What post-migration steps should be carried out for business-critical applications migrated to Azure?

   An application should not be considered production-ready immediately upon completion of the migration process. A number of additional steps should be taken to harden the application for security, manageability and availability. These include:

   • Uninstall the Mobility Service Agent (installed during the migration process in the case of agent-based migration)
   • Install the Azure VM agent. This provides a number of critical manageability features for Azure VMs, including support for VM extensions and password reset.
   • Configure Azure Backup
   • Configure Azure Site Recovery (as a disaster recovery solution, not for migration)
   • Check network security groups and apply additional rules as necessary
   • Verify correct configuration of availability sets or availability zones
   • Enable Azure Disk Encryption
   • Review cost forecasts and enable charge-back
   • Review additional recommendations from Azure Advisor and Azure Security Center

Cost management and optimization

1. How can Fabrikam estimate the future cost before a workload is migrated to Azure?

   Azure Migrate will provide a cost estimate for each migrated workload as part of each migration assessment. This estimate factors in the assessment parameters, such as VM family and size, hours of operation, etc. Azure Migrate downloads the rate card for your subscription from the Azure billing APIs, so any eligible discounts are applied automatically. Be sure to deploy Azure Migrate to a subscription that qualifies for the same billing rates as your production subscriptions.

   

   Simple cost estimates can also be obtained using the Azure Pricing Calculator. If you are logged into an account with access to an Azure subscription with discounted rates (for example, an EA subscription), the calculator includes the option to use the appropriate rate card.

   

   Third-party tools used for migration assessment of physical servers will also provide cost estimates for the migrated workload. For details such as use of discounted rates, check with the vendor.

2. How can Fabrikam optimize their cost estimate, prior to migration?

   For VMware, Fabrikam should use the configuration parameters in Azure Migrate available to tune their migration assessment. Many of these parameters will have an impact on the cost estimate. They include:

   • Azure region
   • VM pricing tier (Basic or Standard)
   • Disk type (Standard HDD, Standard SSD, Premium SSD)
   • Use of Reserved Instances and Hybrid Benefit
   • VM family and size
   • VM uptime
   • Subscription offer and discount

   They can create multiple assessments for the same VMs, to try out different configurations.

   For physical environments, Fabrikam should take a similar approach of tuning their migration assessment using parameters similar to those listed above, as supported by the third-party migration tool chosen or by using the Azure pricing calculator.

3. How can Fabrikam analyze and optimize their costs, post-migration? Include details of mechanisms for internal charge-back.

   As part of their regular operations, Fabrikam should periodically review their deployments to ensure they are optimized for cost efficiency. This review should include:

   • Does the solution make full use of the provisioned VM sizes or PaaS service SKUs? Can the services be moved to fewer or cheaper VMs, or to a lower-cost service SKU? Be aware that new VM families may offer better performance at lower cost than older VM families.
   • Does the solution run 24x7? Does it need to? Can costs be reduced by turning off or reducing the footprint at night or at weekends? This is easily implemented using the Start/stop VMs during off hours solution from the Azure Marketplace.
   • Can auto-scale be used to further optimize the deployment footprint?
   • Can Azure discount programs, such as Hybrid Benefit or Reserved Instances, be used to reduce costs?
   • Are supporting services, such as Azure Site Recovery, Azure Backup, and Log Analytics being used efficiently? For example, for a stateless web server, is Azure Backup required, or would simple disk snapshots suffice? (Can you use a Web App instead?)
   • Are there any cost recommendations in Azure Advisor?

   Azure Cost Management is a useful tool to review both historical and forecast costs. It can provide both a detailed single-application view, or an aggregated view across the organization. Use Cost Management to identify trends and anomalies, as an investigation tool, and as a source of recommendations.

   Key to cost efficiency is creating a cost-conscious culture within the organization. Ensure that those making decisions on deployment are aware of (and ideally accountable for) the cost implications.

Checklist of preferred objection handling

1. Owners of each business application need to approve any substantial application change, including migration. Business owners have indicated that they will require evidence that migration will be successful before granting approval.

   Migration projects should include creation of a proof of concept deployment, to validate the overall architecture and any assumptions, for example regarding the impact of changes to network latency between application components. This helps build confidence in Azure as a platform for hosting the application.

   For the migration process itself, Azure Migrate supports a ‘test failover’. This creates the Azure deployment in parallel with the existing deployment, allowing the migration process to be verified without risk of production impact. Likewise, database migration using DMS does not impact the existing production database.

   Third-party migration tools used for migration of physical servers similarly support a validation step prior to committing the migration.

2. Fabrikam have negotiated an Enterprise Agreement (EA) with Microsoft for their Azure consumption. Any cost estimates need to reflect their EA discount.

   Not a problem! Cost estimates from both Azure Migrate and the Azure Pricing Calculator can be tailored to reflect your EA discount.

3. Many applications comprise multiple components or tiers. How can you ensure that these migrations are appropriately orchestrated?

   Using Azure Migrate, VMs can be grouped to reflect the application architecture. The dependency visualization feature of Azure Migrate helps identify and configure these groupings.

   The migration process can then be staged to migrate different groups of VMs separately. Custom scripts can be used to perform custom pre- and post-migration operations.

   Similar orchestration is also supported by third-party migration tools, used for physical servers.

4. To reduce business impact, each migration should be designed to minimize application downtime. In addition, to reduce risk, there must be an option to fail-back should the migration experience an unexpected problem.

   Migration will always be designed to create the new application deployment in parallel with the existing deployment. This applies to all application tiers, including the database.

   To ensure data consistency during migration, a short application downtime may be required. For application servers migrated using Azure Migrate, incremental replication keeps the duration of this downtime to a minimum, since the initial data transfer can happen while the application is on-line so only deltas need be synchronized during the migration window.

   Similarly, data migration using DMS supports online migration, allowing you to keep your application online while data is synchronized, and to track the status of any pending changes. Only a short downtime window is required to cut over to the new database.

   In the event of an unexpected issue arising, the existing deployment remains available as a fail-back. If the issue is detected prior to cutting over production traffic to the new service, the on-premises server can immediately pick up where it left off. If the need to fail-back is identified only after the migrated service has received production traffic, then database changes may have occurred, which will need to be reverse-migrated to the on-premises system. This scenario is best avoided by ensuring the migration is properly tested. For critical applications, the reverse-migration should be tested (in a test environment) in case it is required.

5. We are expecting to move all our existing infrastructure to Azure. Reducing our on-premises server costs should provide substantial cost savings. Can you confirm what savings we can expect?

   It is a common myth that all workloads should move to the cloud, and that the cloud will automatically be cheaper. Careful planning will be required to optimize your Azure deployment, and a cost analysis performed to make sure the business case for migration is sound and fully understood.

   The Build a business justification for cloud migration guide is a useful resource for dispelling cloud adoption myths and building a realistic business case.

Customer quote (to be read back to the attendees at the end)

“We chose Azure as our strategic cloud platform, due to the breadth of services offered and wide range of tools available to support migrating our existing workloads. Despite a complex, legacy on-premises environment we have now completed the bulk of our Azure migrations, without incident, in under 9 months. Our applications are now faster, more reliable, and cheaper and easier to operate and maintain.” - James Lynch, CTO