MSP Azure Migration Program › migratin… · A guide for Microsoft CSPs to advance the migration...

Crossing the Chasm (Part 1 of 2)

A guide for Microsoft CSPs to advance the migration of initial workload from on-premise

datacenters to Microsoft Azure

Prepared for

Cloud Solution Provider Partners

3/17/2017

Revision .7

MSP Azure Migration

Program

Prepared for CSP Partners

ii

Crossing the Chasm (Part 1 of 2), Version 7, Draft

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without

limiting the rights under copyright, no part of this document may be reproduced, stored

in or introduced into a retrieval system, or transmitted in any form or by any means

(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose,

without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other

intellectual property rights covering subject matter in this document. Except as expressly

provided in any written license agreement from Microsoft, our provision of this document

does not give you any license to these patents, trademarks, copyrights, or other

intellectual property.

The descriptions of other companies’ products in this document, if any, are provided only

as a convenience to you. Any such references should not be considered an endorsement

or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products

may change over time. Also, the descriptions are intended as brief highlights to aid

understanding, rather than as thorough coverage. For authoritative descriptions of these

products, please consult their respective manufacturers.

© 2017 Microsoft Corporation. All rights reserved. Any use or distribution of these

materials without express authorization of Microsoft Corp. is strictly prohibited.

Microsoft and Windows are either registered trademarks or trademarks of Microsoft

Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks

of their respective owners.


iii

Migration S, Crossing the Chasm (Part 1 of 2), Version 7, Draft

Table of Contents

1 Migration Planning Summary, Goals, and Objectives ............................................................... 4

1.1 Business-Related Objectives ..................................................................................................................... 4

1.2 Migration Related Goals ............................................................................................................................ 5

1.3 Cloud Migration Timelines (Initial Workloads (Accelerated)) ...................................................... 6

1.4 Cloud Migration Timelines (Subsequent Workloads) ..................................................................... 7

2 Migration Process (Initial Workloads) .............................................................................................. 7

2.1 Selecting the Initial Workloads ................................................................................................................ 7

2.2 Confirming Initial Workload Compatibility with Azure .................................................................. 8

2.3 Choosing the Best Approach to Migrate the Initial Workloads .................................................. 9

2.3.1 Reinstallation Approach ....................................................................................................... 9

2.3.2 Export / Import Approach ................................................................................................. 10

2.3.3 Azure Site Recovery Approach ........................................................................................ 10

2.4 Migrating the First Workload(s) to Azure ......................................................................................... 11

3 Azure Workload Administration and Management Knowledge Sharing ........................11

4 Next Steps .................................................................................................................................................12



1 Migration Planning Summary, Goals, and

Objectives

This guide was created for Cloud Solutions Providers (CSPs) to assist them migrating their

customer’s first set of simple workloads from on premise to Microsoft Azure. Migrating the initial

set of Virtual Machines (or workloads) to Azure will enhance customer confidence and provide

them with the necessary motivation to migrate subsequent and more complex workloads to

Azure.

Target Audience:

This document will serve as a “guide” for Sales Executives and Architects within partner

organizations. It will help structure an initial cloud migration conversation and

engagement with customers by understanding their resources, support channels and

workflows that can be leveraged to start initial workload migrations and to attain the goals

and objectives of the program.

For customers that may have already migrated servers to Azure and have a good

understanding of Azure administration and management, the partner may choose to jump

straight to the “Crossing the Chasm – Part 2 of 2” guide.

Business-Related Objectives

Migrating from on-premise datacenters to Microsoft Azure immensely benefits the business as it

minimizes an organization’s need to continue to maintain and manage expensive datacenters. An

application is still the same application regardless of whether it is running inside an organization’s

own datacenter or hosted in another datacenter like Azure. Of course, enterprise level security,

reliability and availability have to be ensured with such migrations and Microsoft Azure is built

with these capabilities in mind.

However, beyond just the basic benefits of eliminating datacenter management responsibilities,

the use of Microsoft’s Azure environment provides an organization with additional technology

solutions that benefit the business. Microsoft’s Azure cloud platform provides:

Datacenters geographically distributed around the globe to serve organizations anywhere

in the world.

Geo-redundancy of the Azure datacenter infrastructure for high availability and business

continuity disaster recovery.

Virtually limitless capacity to scale as organization’s needs and requirements grow.



Resources that organizations pay for only “as needed” so that capacity can be decreased

or eliminated without incurring fixed capital costs.

Availability of integrated technology services such as BCDR, monitoring, management,

data analytics, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), mobile

compute services, Internet of Things, and many other core features – making businesses

more agile.

Organizations of all sizes are no longer excluded from leveraging enterprise scale technology

features and services, and can easily extend their IT needs to meet core business related objectives

by enabling the services required by the organization, on demand.

1.1 Migration Related Goals

Migrating on-premises workloads to Azure brings vast and immense benefits for organizations

in every industry and segment. A majority of enterprise customers will look to Partners to help

them realize these benefits which present great opportunities for CSP Partners.

Understanding the Migration Framework and Processes is crucial for Partners to successfully

engage their customers and migrate their workloads to Azure. The process and methodologies

designed by Microsoft (shown in the diagram below) provides a tried and tested migration

framework that Partners can follow to assist their customers through a successful cloud migration

initiative.

The tools and processes used in the migration framework provide automation and support for

CSP Partners that will help customers discover their application usage patterns, map them to

Azure resources and services, and finally migrate them to Azure in a systematic fashion.

The following framework and resources outlined in the diagram below are available in the process

of onboarding customers to Azure:

Please Note: This is just one of many possible ways of migrating workloads to Azure. The one

discussed here is by no means a mandatory process that CSP partners have to follow. If they have

their own tried and tested methods, then they should follow them.



(Above) Azure Migration Framework & Process

1.2 Cloud Migration Timelines (Initial Workloads

(Accelerated))

As described in the “Setting the Scene - Successful Migration Scenarios” guide, the migration of

workloads from on-premise datacenters to Microsoft Azure is commonly broken into two steps.

The first step is identifying and migrating a handful of simple application servers to Azure. This is

on an accelerated timeline where a partner can help a customer migrate the initial 3-5 virtual

machines to Microsoft Azure within a week or two. This initial experience helps the customer

better understand Azure and how the administration and management of workloads on Azure

works. Additionally, it allows customers to gain comfort in the reliability and dependability of

Azure, along with extending the process of performing their normal day to day tasks with

workloads that have been moved to Azure in the cloud.



1.3 Cloud Migration Timelines (Subsequent Workloads)

Once a customer has a foothold of servers running in Azure and is comfortable with how Azure

operates, the next step is to target the migration of the remaining 15-20 additional virtual

machines to Azure. These workloads are typically the more complex applications, and have more

structure and downtime SLAs to them. However, it is still recommended that partners ensure the

20 or so virtual machines migrated are likely the easiest applications/workloads as part of the

initial extension of the enterprise datacenter to the cloud. The details of the migration of

subsequent workloads is covered in the “Crossing the Chasm – Part 2 of 2” guide document.

2 Migration Process (Initial Workloads)

The migration process for the initial workloads focuses on a few simple workloads (3-5 virtual

machines maximum) that are intentionally easy workloads to migrate.

2.1 Selecting the Initial Workloads

The selection of the initial workloads is critical in ensuring the customer’s first experience with

migrations and Azure is not overly complicated. It is also important that the learning/training

exercise includes having the customers get basic familiarity with Microsoft Azure, running virtual



machines in Azure, and understanding how to administer and manage the Azure-based systems.

Giving them proof that Azure workloads can be managed with the same level of familiarity that

the customer has managing on-premise systems is key to successful migrations.

Successful candidates for initial workload migration could be:

1) Standalone Systems: A server or application that is a standalone service. This means

that it is self-contained with as few dependencies as possible, thus it makes for the best

candidate for an initial migration to Azure. This is frequently a standalone Web-server

(like a WWW Webserver) or standalone Website.

2) Single node Systems: A sever or application that is a single node configuration, as

opposed to a server that is part of a cluster or a complex client/server application. This

also makes for a good initial candidate for migrations to Azure.

While this initial workload might not be seen as “strategic” or “complicated,” for the customer

who has had limited (or no) experience with Azure, this initial workload migration is intended to

get the customer “into Azure” with minimal effort and challenges along with a high success

factor.

To assist in the general suitability of application support in Azure (ex: version of Windows Server

or Linux OS supported in Azure), see https://support.microsoft.com/en-

us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines.

2.2 Confirming Initial Workload Compatibility with Azure

With the initial candidate for a virtual machine (workload) that will be migrated from an on-

premise datacenter to Microsoft Azure identified, the first step is to run the Microsoft Virtual

Machine Readiness Assessment tool https://azure.microsoft.com/en-us/downloads/vm-

readiness-assessment/. The Virtual Machines Readiness Assessment tool will automatically

inspect the on-premises environment, whether it is physical or virtualized, and provide you with

a check list and detailed report on steps you need to take to move your environment to the

cloud. The Virtual Machine Readiness Assessment tool also validates the version of the

operating system, running services, and configuration to make sure the virtual machine is indeed

supported to run in Azure and a report will be provided to note any areas that might require

configuration or design changes.

If there are too many items noted that require remediation, a different (simpler) workload may

be more appropriate for the initial migration. Again, the point behind the exercise of the first

workload to migrate is to get an initial virtual machine running in Azure as quickly and as easily

as possible.

https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

https://azure.microsoft.com/en-us/downloads/vm-readiness-assessment/

https://azure.microsoft.com/en-us/downloads/vm-readiness-assessment/



2.3 Choosing the Best Approach to Migrate the Initial

Workloads

Getting the first workload to Azure can be performed many different ways. For a simple

application like a Web Server with HTML pages, a Windows Server Virtual Machine can be

installed in Azure, and the customer’s HTML code can be installed/copied on to that server.

Many organizations have simple installation / reinstallation procedures documented for building

a Web Server which is why a Web Server application is typically recommended as the best first

workload. This is noted as the Reinstallation Approach below.

For some migrations, it might be easier to export the entire server to a file and import that file

as a server into Microsoft Azure. This is noted as the Export/Import Approach. There is a third

approach noted using Microsoft’s Azure Site Recovery (ASR) that replicates virtual machines

between on-premise and Azure. However, while that approach is a good method for

subsequent automated virtual machine migrations, try to pick an initial application and one of

the two simpler migration approaches for the first couple of workloads.

2.3.1 Reinstallation Approach

A reinstallation approach can involve creating a new virtual machine and installation or

restoring the application program and data onto the newly created VM. For some

applications and for some organizational processes, this manual process may be a well-

known process and preferred by the IT team. As an example, if an application is simply a

Microsoft IIS Web Server, building a new Windows Server in Azure, enabling the IIS service

on the server and then installing the application code/data is something that many

organizations are very familiar with how to do, and it can be successfully completed in an

hour or two.

The pros for this option are that the organization is following well known and defined

installation processes. Additionally, this method of installation can result in an organization

installing the latest Windows Server 2016 environment, potentially replacing an older

Windows Server 2012 or 2012R2 configuration. So, in this process the organization not only

gets their IIS based Web application running in Azure, but they also have upgraded the

underlying operating system to be running on the latest Windows Server operating system!

The cons for this method are that the organization needs to have all of the application code,

plug-ins, or other configuration settings to properly install the application all over again.

Many organizations no longer have the installation discs or installation instructions to

recreate installations from scratch, so this could pose a problem.



2.3.2 Export / Import Approach

Another migration option is to export an existing server configuration and then import the

entire configuration into Azure. This is commonly referred to as a P2V (Physical to Virtual) or

V2V (Virtual to Virtual) migration. An export tool (like P2V or V2V) is used to export an

existing (running) system, and then the exported image is then imported into Azure.

The pros of this type of migration are that it captures the entire system configuration

including the operating system, application and data. This is a good solution for an

organization that no longer has the installation disks or lacks the installation and

configuration instructions to reinstall the application from scratch.

The cons to an export and import approach are that the organizations now bring whatever

was working (or not working) previously into Azure. Also, if an application has some odd

configuration or operating problems, they likely won’t just disappear when the application is

imported into Azure, so there could possibly be problems with moving from on-premise into

Azure.

However, for well running, complex applications, the export/import approach allows a full

migration of a working application into the new Azure environment with little effort.

2.3.3 Azure Site Recovery Approach

For organizations that believe the export/import approach of moving an entire application

image into Azure will not be a good solution, the use of Microsoft Azure Site Recovery (ASR)

simplifies the process. ASR effectively takes a running physical server or virtual machine

(running in Microsoft’s Hyper-V or in VMware) and replicates the running system over to

Azure.

The pros for migrations using ASR are that it provides scale via automation and by seeding

the on-premise servers with full synchronization and continuous replication (in 30 second

increments) until the organization is ready to cut over to the application in Azure. Once

implemented, an organization can choose when to perform the full cutover. ASR also has a

Test Failover process that allows an organization to test their migration to ensure the end

state configuration works before cutting over the application in a fully operational production

state. Failback of a migration back to on-premise if there are problems in the initial cutover

to the Azure cloud is also a feature with ASR.

The con for migration using ASR is the need to learn a new tool like ASR and understand how

to setup and configure it. Microsoft has step-by-step guidance on how to utilize Azure Site

Recovery, so despite a short learning curve, ASR is typically the recommended method in

helping an organization get their applications migrated to Azure .



As noted, this method of using ASR for migration of workloads to Azure will be a focus for

subsequent workload migrations, but for the initial workloads, start with a simpler

Reinstallation or Export/Import methods.

2.4 Migrating the First Workload(s) to Azure

The process of migrating the first workloads can be as simple as building a virtual machine in

Azure and installing the application code (and data) on the virtual machine, if the Reinstallation

approach was chosen. The “Architectural Design and Considerations Guide for Initial

Workloads” document offers step-by-step procedures for building virtual machines in Azure,

and provides step-by-step guidance if the on-premise network needs to be “stretched” to Azure

to accommodate a hybrid integrated networking mode.

3 Azure Workload Administration and Management

Knowledge Sharing

After the first workload has been migrated to Azure is a good time to make sure the customer

becomes familiar with administering and managing the virtual machine, now running in Azure.

Having the knowledge and comfort that they can perform normal daily tasks in Azure just as they

have done for years with workloads on-premise ensures acceptance from the customer. This

reinforces the message that running their application in Azure is “just the same” as running their

applications on-premise.

Some of the common tasks to run through with the customer are:

Remotely accessing the running Virtual Machine (ie: using Remote Desktop Client to

connect to the server instance) – See https://docs.microsoft.com/en-us/azure/virtual-

machines/.

Setting up the Virtual Machine for patching and updates (ie: using Windows Software

Update Services, System Center Configuration Manager, or other update tool) – See

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/.

Monitoring the health and operations of the Virtual Machine in Azure (ie: using System

Center Operations Manager, and/or understanding the Azure Portal interface to

understand server operations) – See https://azure.microsoft.com/en-us/features/azure-

portal/.

Typically, this familiarization and knowledge sharing process is done in a 2-4 hours “knowledge

sharing” session after the first workload is migrated to Azure. Since Virtual Machines running in

https://docs.microsoft.com/en-us/azure/virtual-machines/

https://docs.microsoft.com/en-us/azure/virtual-machines/

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/

https://azure.microsoft.com/en-us/features/azure-portal/

https://azure.microsoft.com/en-us/features/azure-portal/



Azure are very similar to Virtual Machines running on-premise, customers typically understand

the process very quickly. For Managed Service Providers that take care of all of the daily tasks,

administration, and management, this “knowledge sharing” might just be a 1-hour overview with

the customer to simply show them that the services the partner will be doing for the customer

will be similar to what the MSP has done for the customer with their on-premise workloads. Such

activities will go a long way in easing the customer’s apprehension and build trust in knowing that

the partner transferred their knowledge, expertise, and services to a similar platform with proven

experience.

4 Next Steps

After the first workload has been migrated to Azure, the next step is to immediately begin the

process of migrating the second workload to Azure AND start the process of getting ready for the

subsequent/remaining workloads to ultimately get at least 20 production Virtual Machines to

Azure.

The process of migrating the second workload is identical to the migration of the first workload.

Again, select a workload that is anticipated to be easy to migrate. It could be a little more

complicated, like potentially an IIS/Web application with an integrated SQL Server component.

However, do your best to select a system that can be migrated with limited challenges.

While the migration of the second workload is underway, simultaneously getting ready to migrate

the next 3-5 subsequent workloads is important. Not having a “delay” between the completion

of the initial 3-5 Virtual Machines and the start of the next 15 Virtual Machines will ensure

continuity and success of the initiative. The planning and preparation process for the subsequent

workloads is documented in the “Crossing the Chasm – Part 2 of 2” guide document, and should

begin immediately.

MSP Azure Migration Program › migratin… · A guide for Microsoft CSPs to advance the migration...

Documents

Transcript of MSP Azure Migration Program › migratin… · A guide for Microsoft CSPs to advance the migration...