As a Managed Services Provider (MSP) partner looking to help customers migrate to the Microsoft Azure Cloud, there are many approaches to get them to adopt the cloud. This guide highlights various migration strategies typically used in moving customers to the cloud and also covers the one migration strategy that has proven to be more successful than others. This strategy has helped rapidly build customer confidence with Azure resulting in faster adoption and more cloud migration wins. The next section describes these strategies in more detail.
Note: Partners may have a tried and proven migration strategy of their own and may to adopt this strategy to get their customers to migrate to Microsoft Azure. The guidance in this document is not a requirement partners must follow, however in lieu of any other strategic guidance, this process has proven to drive faster onboarding and Azure adoption.
Some early adopter cloud migration initiatives have targeted taking one of the customer's most important, highly visible application and focusing on moving that to the cloud. While a "win" for an organization's most important application sets a precedence to then migrate "everything else" to the cloud, the experience has been that the process often takes several months if not years to complete. While the organization will be highly committed to Microsoft because of the time and effort spent in planning and executing on the initial migration, the process is extremely time consuming and any changes in an organization's key stakeholders, decision makers or priorities can derail a lengthy pilot and migration process.
Other early adopter cloud migration strategies have sought to assess ALL servers and applications an organization has in their datacenter and plan a holistic migration roadmap to the cloud. While this addresses the entire breadth and depth of an organization's cloud migration strategy, this too is very time consuming and fraught with risk. Many organizations have a large number of servers and applications that most often times IT is not even aware of. This exercise, while comprehensive, doesn't result in a migration "win" for months, if not years.
What has proven to be the most effective strategy in advancing an organization's adoption to the cloud has been to start with just a handful of simple applications to migrate to Microsoft Azure and focus on a migration "win" within days. Building on that success is akin to a "snowball effect" approach, gaining customer confidence and accelerating the adoption of Microsoft Azure. The strategy starts with an initial discussion with the customer to identify the initial 2 or 3 applications that would likely be the fastest and easiest to migrate to Azure. Combined with a commitment to crosstrain the customer on core Azure administration and management tasks, this will help the customer "cross the chasm" to the public cloud quickly and with an expedited, pleasant first experience.
Additionally, what has also proven to accelerate the migration and adoption of Azure is educating the customer about the reliability, security and simplicity built into Azure. This, combined with positioning Azure as a complimentary service to an organization's ongoing IT strategy (and how this choice is not any more complicated nor different than what the organization has done in the past), will expedite adoptions. Below are a few scenarios that partners should consider migrating for the previous (and most effective) strategy.
A common "first server" cloud migration application has been migrating the organization's public www server or other classic Web server application. Typically, the Web (www) server is a standalone server that is not joined to any particular security domain running a simple Web application. These applications have relatively high visibility within the organization but have simple technical infrastructure needs and are ideal choices.
As a simple Web-based application, the cloud implementation typically involves building a standalone Windows or Linux Virtual Machine in Azure and then uploading code (potentially via FTP, Visual Studio upload or other file transfer protocols). The Web application can be staged and tested thoroughly prior to being brought online. Simple dev and test cycles can validate the readiness of the application to be brought online within days of initial migration effort. Also, because Web applications commonly are DNS driven for public access, a failback of the application can be accomplished within seconds with a simple DNS change – should a cutover to production on the cloud platform prove to be problematic.
Note: Technical guidance is provided in Phase 3 of the IP/Content framework describing the common Azure network integration and first/second workload migration process.
Similar to the first scenario, an application environment utilizing Microsoft IIS/Web (or Apache in case of Linux) services as a frontend and something like Microsoft SQL Server (or MySQL) on the backend can potentially be an excellent "first application" to migrate to Azure. Many times these simple Web/database applications are running on a single server, making the migration to Azure simple.
Such a self-contained application (that has limited dependencies on the integration of the frontend and the backend) can result in a quick test cycle with a push to live production within a few days from the start of the migration process. And as a Webbased application is typically dependent on just a DNS entry pointing to the live production system, a failback can be initiated to route users back to the original application should any problems occur during the cutover process.
With the initial round or two of servers migrated from on-premise to Microsoft Azure, customers will have an initial experience with Microsoft Azure. They will also gain familiarity with the administration and management process of Azure and be more confident in proceeding with more complex migration scenarios.
It's at this point in this initiative that the partner will advance to Phase 4 and gain access to a tool like Cloudamize to run an assessment on a handful of more complex application scenarios. Cloudamize will identify dependencies between server workloads, size the current server and application workload, and allow the customer and partner to prioritize the next 12-15 servers that'll be migrated to Azure.
It is still the best practice guidance to select easier workloads to migrate to Azure. The goal of the initiative is to migrate 20 virtual machines to Azure in a short period of time. While the next workload(s) can be a little more complex that the first couple workloads, keeping the migration efforts manageable will ensure completion of the first 20 Virtual Machines to Azure. This will provide the best experience in a short period of time.
There are a number of other Azure Services that are commonly enabled during an Azure migration initiative. These services do not involve the migration of virtual machines to Azure but extend an organization's capabilities (and consumption of Azure) in broader ways. Since these services are relatively quick to implement and not actively intrusive to the general operations of the server and application, they tend to be quick workloads to enhance an organization's Azure experience.
Additional Azure Services 1: Selecting a Simple Workload for Azure Backup
A simple additional azure service that can typically be implemented in a very short period of time is leveraging the Azure Backup functionality for an enterprise. Azure Backup is non-intrusive to running servers and has proven to yield positive experiences and add value. An initial experience with Azure Backup typically focuses on a couple workloads commonly in an organization's DMZ network or simple Web-based workloads. These servers are frequently not on a routine backup schedule and/or have a limited amount of data on them, thus are quick to backup. They also incrementally add value and provide the customer with an added capability while showing how simple and quick Azure Backup is for data recovery and protection.
After initial backup processes are completed, cross-training or simple demonstrations to the customer of how a file (or files) can be quickly selected and restored provides a comfort factor that Azure Backup is similar to old traditional backup systems the customer is likely familiar with, while also showing that it works efficiently and effectively. This rapidly grows the customer's confidence in Microsoft Azure as an easy, quick to configure and dependable cloud service.
Additional Azure Services 2: Selecting a Simple Workload for Disaster Recovery in Azure
Another simple Azure service that can typically be implemented in a very short period of time is leveraging disaster recovery functionality in the Azure Site Recovery (ASR) service in Azure. Again, selecting a server that might be in an organization's DMZ network or a Web-based frontend server is ideal for an initial ASR disaster recovery implementation. A small or simple application server can minimize the replication and failover times and provide a smoother first experience of ASR's capabilities.
Many organizations typically either have very expensive disaster recovery solutions in place – costing hundreds of thousands of dollars – or have no disaster recovery solutions at all. An ASR snapshot and Azure-based recovery of a small application can be completed in a matter of days to show the value of ASR (and Azure) as a low cost and extremely effective disaster recovery solution. Building on a successful first engagement with ASR for other applications can provide an extended project with a customer. Partners can work with customers on building disaster recovery planning, implementation, failover testing & ongoing monitoring and management services.
The biggest blocker most partners face in helping an organization migrate to Azure is its lack of familiarity with Azure. For decades' organizations have gotten used to the performance and reliability derived through their use of servers and applications within their datacenter or in the datacenters of their trusted managed service provider locations. Azure is a new thing for these customers and with the new comes concerns of reliability, security and a general lack of conceptual understanding of how the "public cloud works".
The quick and simple migration and adoption strategy followed by a familiarization training exercise allows customers to migrate an initial application or two to Azure and experience how Azure is no more different than what they have today. As the organization cycles through ongoing management and maintenance processes in Azure and experiences the similarities of Azure to how things are done today, their comfort levels with Azure increase and it enables the organization to trust additional migrations (including the highly visible and strategic applications) to Azure.
While the quick and simple migration and adoption strategy can get a partner to secure a migration "win" quickly, there is a tendency for organizations to "stop there" and "see how this goes" for an extended period of time. It is important for the partner to have already built into the migration plan and timeline the expectation that after the initial couple workload(s) have been migrated to Azure, the partner services engagement automatically proceeds with additional workloads. This continued cadence on migrating 3-4 additional workloads (involving 15-20 servers) provides a substantial footprint in Azure that ensures a certain "stickiness" for the customer to proceed ahead with the migration of ALL of their servers and applications to Azure.
It is this consistent migration planning and execution process that will help a partner ensure a rapid pace for the customer to "commit" to Azure. After the first couple workloads are migrated (typically within 2-3 weeks of initiating the migration efforts), the next 3-4 workloads comprising of an aggregate 10-15 servers should already be identified, scheduled and initiated for migration. This effort can be completed within 46 weeks of the initial migration efforts and will have an organization running 15-20 servers or Virtual Machines in Azure within the first 2 months.
While a partner may have helped a customer quickly get a foothold in Azure, the completion of "all" workloads to Azure will likely not proceed as rapidly. When the simple workloads are done, the organization is left with complex workloads. These are typically workloads with a lot of cross-server and application dependencies, varying application vendor cloud support and mission critical applications that have a very structured and methodical process that needs to be followed with stringent change management controls.
It is at this point that a partner should step back and assist the customer in a more structured and methodical migration planning and execution process. The planning process of a complex application could take 2-3 weeks or even 2-3 months to properly plan out the architecture, design and migrate it to Azure.
This is where application capacity planning, timing the migration cutover, security considerations, change management controls and application continuity systems have to be in place before the application can be moved to Azure.
However, since the customer has already migrated over an initial 15-20 servers to Azure and has already been cross-trained on how Azure works and how to monitor and manage basic Azure workloads, this will enable partners to handle more of the complex and mission critical applications.
A "Master Engagement Plan and Migration Checklist" has been provided to help partners walk through what has been proven to be this successful strategy in bringing customers across the migration chasm into Azure.
The Migration Checklist helps partners by identifying a sequential set of tasks that every successful migration goes through and also provides a guidance in leveraging existing resources available as part of this MSP Azure Migration initiative.