Cloud Migration — An Introduction

Published by D Girma on 2018-12-31

1. Overview

Cloud Computing is ushering in a new technological landscape by way of IT systems migration onto the cloud platform. Businesses and organizations, large and small, are increasingly in the process of moving their infrastructure and applications to the cloud. A significant percentage of businesses are already using the cloud with ever increasing proportion relative to their onprem (short for “on-premises”) IT resources.

Cloud Computing offers a number of benefits, such as reduced cost in IT expenditure, on-demand usage model suited to cost optimization, elastic resources with dynamic scalability, and many more. Granting all this, however, there are always exception to the rule and cloud may not be for everyone, although such cases are expected to be in the minority (see for example section 2.1.2 below).

For those actively opting for the cloud platform, in addition to or in lieu of onprem computing resources, getting up and running is not without challenges. The following are some indicators of the challenges compiled from various surveys. As these surveys are somewhat dated, you may have to factor in the continual improvements in technology and personnel skills, availability of more effective migration tools, as well as third-party migration service providers.

According to CloudEndure 2017 Cloud Migration Survey Report, the cloud migration phase lasts on average 18 man-months and at 45% of the total project time — the remaining time being for pre-migration planning (40%), and post-migration optimization (15%).
Early in 2017 InfoWorld predicted that one-in-three or 33% of cloud migration projects would fail in 2018. I haven’t seen an update on this if this prediction held accurate, nonetheless, the figure is indicative of how daunting migration tasks can be. Even taking a more optimistic view of the prediction, say, one-in-four (25%), or even one-in-five (20%), it only confirms that the challenge is not insignificant.
Most migration failures are due to lack of skill. Many companies attempted migration believing they had the in-house skill to do it, only to realize that in-house skills don’t automatically translate to the cloud. It is also conceivable that new and relatively less tested technologies (e.g., virtualization based on new technologies such as Container clusters), and less refined design methodologies in the making, may have had some impact. Therefore, companies should consider either intensive training of in-house staff, or seek support from third-party consultants.

ⓘ: If you need quick definitions/explanations of the technical terms that appear in this article, refer to a related article: Cloud Speak – Terminologies in Cloud Computing.

2. A Migration Journey

Projects as complex as cloud migration call for a systematic approach to the problem, usually broken down into a set of distinct and sequential methods. Microsoft Azure uses a migration methodology as depicted in the figure below which is easy to understand. I am using this methodology to illustrate the key concepts involved throughout this article.

2.1. Discover & Assess

This initial step does just what it says: identifying all existing application workloads in the infrastructure so as to prepare a complete inventory for migration. As indicated by the CloudEndure survey result (see above), this step can take a significant portion of the project time (circa 40% in the survey), so it is an extensive process that essentially forms a complete and up-to-date inventory for a migration project.

Note that the keyword application workload is very important here. A workload is the demand placed on a system by an application—the amount of processing work that the compute environment needs to accomplish in a certain period of time. Depending on the application, this may be quantified by some metric such the number of user interactions, database connections, etc, but the important thing ultimately is to assess the computing resource requirements and certain dependencies, say, in terms of CPU cores, RAM size, storage type (standard vs premium media, hot vs cold access), network configurations (subnets, DNS, firewalls, network latency, etc). This is critical in the mapping of applications on to virtualized computing resources (VMs and Containers).

To give you some idea of a typical workloads distribution, shown below is a survey result reproduced from the CloudEndure 2017 Report. Note that top of the list is occupied by web-connected applications (such as WebAPI based apps, development activities such as GitHub, database connections), while the bottom end is for enterprise applications (Customer relationship management or CRM, Enterprise resource planning or ERP) which, unlike web-connected heavy workload applications, these by their very nature are either of restricted user roles or user traffic.

2.1.1 Assessments for Easy Migration

Some migrations are straightforward and you may have done this already by adopting SaaS (Software as a Service) alternatives for your applications, the best examples being Microsoft Office 365 and Microsoft Teams suite of office and communications applications, and Microsoft Dynamics 365 for ERP and CRM applications.
There are also new offerings under new buzz words, such as Business SaaS or Business Process as a Service or BPaaS, so evaluate if these offerings can solve part of your migration workloads. Examples of BPaaS are cloud-based payroll services, project management services, accounting services, and many more. Check with cloud service providers (CSPs), CSP solution partners, and independent cloud-software vendors. Unlike standalone SaaS applications such as Office 365, with BPaaS you may need to assess a number of factors such as interoperability with other applications (e.g., data format), level of support, vendor lock-in, etc, which just illustrates what could be involved in your “discover & assess” phase of migration project.
A relatively easy but not necessarily cost efficient approach to cloud migration is porting apps and data resources to a cloud platform with minimal changes to the existing code. This is known as lift-and-shift or re-hosting approach. An example of a workload for this approach could be an onprem SQL workload that will be migrated by re-hosting on IaaS (Infrastructure as a Service) as an Azure SQL Managed instance. While this approach has an advantage of faster deployment, it cannot take advantage of native features of the cloud platform for performance and cost optimization. This approach is also well suited to various workloads that are hosted onprem with enterprise virtual machines. Migration of workloads based on enterprise virtual machines also lends itself to some automation, at least for the first phase(s) of the migration processes as highlighted under section 2.1.3 below.

2.1.2 Assessments for Not-So-Easy Migration

If you are not taking the easy routes mentioned above (for instance, lift-and-shift approach), then, may be you’re doing one or more of the following:

Make some modification to your code, perhaps as partial code refactoring(programmers’ parlance to mean restructuring existing computer code) for IaaS or PaaS (Platform as a Service) migration;
Convert physical server workloads into a virtual machine for IaaS or PaaS migration, or alternatively convert into native cloud such as Serverless for PaaS migration, which in effect is the next bullet point.
Re-write application for native cloud deployment on PaaS.

This assumes that where possible you have taken advantage of the SaaS options available to you. As you start dealing with physical servers and consider native cloud solutions, you are entering the not-so-easy territory for cloud migration. This is the case due to the fact that the workload dependencies change from onprem physical platforms as we move to the cloud platform. You may ask why this wasn’t the case with the lift-and-shift migration. It was indeed the case, to the extent that some tweaking was still necessary but by and large the onprem virtual machines that enabled easy (and automatic) migration have played a role in identifying and/or isolating most of the dependencies of workloads on the physical hardware. The dependencies in question are briefly explained below.

One of the stark differences between onprem and the cloud platform is the network latency—the time it takes for data to travel over the network—which is generally increased for cloud platforms due to the loosely coupled and distributed architecture. As network latencies increase, say between databases servers and processing points, a host of new problems crop up. While we can use some techniques to mitigate latency, such as a traffic manager to route to the closest endpoint, with cloud migration we are now entering a new kind of ball game that calls for workload assessments as we attempt to map existing workloads (onprem hardware platforms and networks) onto cloud platforms.

Working backwards from the problem just cited, it is clear that for successful migration we should have designed our existing applications to be network latency tolerant (but with tightly coupled data access and processing, designers during non-cloud era were all aiming for the opposite by minimizing latency and maximizing throughput—well, who thought of today’s cloud platform decades ago?). Like the network latency problem, similar factors such as tight dependencies on high-throughput data transfer, or high-performance storage media can also raise similar incompatibility issues in the cloud.

Generalizing this, it means ideally application workloads should be independent of the underlying processing and network hardware they run on. Whether you are tweaking existing code for minor modifications, performing major code re-write for native cloud migration, or develop supplementary native code to make the migration a success by code integration, this is where the skills of solution architects and cloud developers come in high demand. This is where detailed assessments come to the fore (and feed into the next steps for migration and beyond), including the assessments of performance requirements, disaster recovery processes, resiliency configurations, maintenance procedures, just to name a few. These are however topics that are more geared towards advanced topics and beyond the scope of our discussion for this introductory article.

2.1.3 An Example of Discover & Assess

When it comes to discover & assessment, which could be a tedious pre-migration process particularly for large enterprises, there are assistant tools and third-party CSP partners, that can make this exercise more successful in less time. For instance, Microsoft provides a free discovery & assessment tool by the name Azure Migrate for collecting onprem virtual machines information, and carry out assessments for migration by uploading to Azure Dashboard. This tool currently supports only VMware virtual machines, with Hyper-Vsupport to be included in the future. Considering VMware’s dominance in enterprise virtual machines (some unofficial estimate puts at around 70%), with workload location split between virtual machines (at about 60%) and physical machines (at about 40%), it means Azure Migrate tool can provide a significant help with considerable number of migration projects that qualify as the lift-and-shift approach.

Running Azure Migrate is straight forward. When you create a migration project in your Azure Dashboard (by invoking the Migration projects service), you will be offered to download a Virtual Appliance image (18 GB file size) which you import into a vCenter Server (the VMware management center, version 5.5. or higher), to create a Collector Virtual Machine (aka Collector Appliance). You can create the migration project only in East US or West Central US datacenters, but this should not be regarded as a limitation as you can choose appropriate dastacenter locations when you carry out the actual migration. It just means that the discovery and assessment management behind the Azure Migrate tool are currently available in East and West Central US.

Upon importing the Virtual Appliance image, the Collector Appliance comes to life as a 64-bit Windows Server 2016 with RAM size of 16GB as default, and with data collection command short-cut on the server desktop for running the discover & assess process. (It is possible that your download could be for Windows Server 2012 R2, with slightly smaller Virtual Appliance image size). For demo purposes, I imported mine to the free VirtualBox hypervsor with RAM size set to 8GB and vCPU of 2 and worked fine.

After logging on to onprem vCenter Server and specifying the migration project at Azure portal with the necessary credentials, the tool progresses to the collection of information (configuration and performance metadata) of virtual machines (see screen-shot of collector UI above). Subsequent assessments generate a report detailing the workload attributes or configurations that are ready to migrate (with resources and cost estimate), as well as workloads that require further investigation before migration. In the latter case, additional resources are provided to resolve issues and prepare the workload for migration.

Azure Migrate also has complementary tools by the name Service Map and Data Migration Assistant (DMA), both installable from Market Place. The Service Map,together with various monitoring agents (which will not be covered here), assists with the assessment by discovering machine dependencies at the process and connection endpoints. This provides a detailed map and therefore better visualization of workloads for migration. The DMA, on the other hand, is used to assess SQL instances with regard to compatibility issues (such as unsupported versions and features, connection strings, etc) as part of the overall migration assessments. Also worth noting that there are various third-party tools including migration services from Azure solution partners.

In summary, Azure Migrate:

uses Virtual Collector Appliance for its operation;
provides Azure readiness assessment of onprem VMware workloads (vCenter Serverversion 5.5 or higher is required);
provides estimates of resources sizing and cost per workload;
the Service Map and Data Migration Assistant tools can be used in conjunction to assess, plan, and accelerate migration; and
where migration fails, assists with identifying the issues for further investigation.

ⓘ: If the EU GDPR legislation applies to you, only metadata is collected by Azure Migratetool and you should not be overly concerned about personal data crossing the EU boundary during the assessment phase (which normally is of crucial consideration for businesses handling personal data of EU citizens).

2.2. Migrate & Modernize

Having done the hard work of discovery & assessment of workloads, the next step is migrating the workloads onto the cloud platform. In the preceding section, we have already touched upon migration with regard to easy and not-so-easy assessments, so we can sum up those points here with some additional comments. For a better perspective, we can put what we have outlined so far into the following diagram, with distinct migration strategies clearly labelled under migration & modernize phase.

Re-Host: This is a quick migration strategy without making code changes and therefore involving minimal risks. Enterprise virtual machine based applications (discussed above) and databases that require Azure IaaS virtual machine are examples of good candidates for this migration strategy.
Refactor: This involves some change to the application design, usually “around the edges” by retaining the major part of the codebase. This could be as simple as re-targeting a different cloud-based database or changing some part of the code in order to take advantage of cloud platform scaling and optimization. Note that Gartner and Azure website show this step as two distinct options: as Refactor (with minor code modification to repackage the application), and Rearchitect (with code modification to extend app functionality to allow scaling and optimization, if possible using solutions such as Containers). The difference between the two strategies is essentially the extent of code modification and resultant usage of cloud-native features.
Rebuild: or code re-write is developing the application based on cloud-native programming. In other words, this is application development on PaaS from scratch and for innovative solutions that take advantage of various advanced cloud technologies such as AI, Blockchain, IoT, and so on.

2.3. Optimize

By the time you get to this stage, you have various tools at your disposal in order to carry out your cloud optimization.

Performance optimization: Your migration strategies are just the beginning of the journey and you’ll no doubt continue that journey with various performance optimizations such as scaling based on different configurations. Azure for instance has various tools geared toward such tasks.
Cost Optimization: A key feature of the cloud platform is its elasticity to allocate and de-allocate resources for optimal cost, and we can leverage this to optimize cost and performance. Azure for instance provides a comprehensive set of cost management tools that can assist with this task.

2.4. Secure & Manage

Security is one of the most important aspects of any IT system, and more so for the cloud system. Moving to the cloud does offload some responsibilities to the CSP, but security as a shared responsibility is still the case. It is therefore important to be familiar with the security architectures and mechanisms provided by the CSP in order to enforce security policies as well as maintain legal regulatory compliances such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act or HIPAA. For GDPR related security, see a related article: Cloud Computing and the EU GDPR.

The threat landscape is always evolving which means that security management should be an on-going commitment with real time monitoring and continuous security assessments. Cloud services have an array of security management systems and tools, such as Identity Management, encryption technologies (for data at rest and in transit), and infrastructure and network protection mechanisms (such as defence in depth layered protection strategy). When it comes to security, CSPs generally provide dedicated security monitoring tools and publish a broad set of up-to-date guidelines (with any known specific threats) and it is important that such guides and recommendations are promptly followed, particularly if any actions need to be taken by you as a customer.

An example of a dedicated tool for Azure, available at Azure Dashboard, is the Security Center, which provides analysis of security policy compliance, security monitoring with alerts, as well as relevant recommendations; and surely one that qualifies as a favorite item on your Dashboard.
Here is an example of a detailed documentation on Azure website, which covers best practices for securing and managing workloads migrated to Azure.

3. Conclusion

Migrating onprem IT to the cloud platform is a big step for businesses and organizations particularly for small ones. This introductory article will hopefully provide an overview of what is involved. By now it should be clear that migration to the cloud is not an exact science. In addition to the new cloud design methodologies, platform architectures and tools, there are loads of heuristic techniques at work, say, by solution architects, rooted in practical experiences. The key to success is how to put these strands of knowledge and skills to create timely and optimal solutions of the migration journey into the cloud.

☀☀☀

If you’ve got this far, chances are you may have found this article useful. If so, show your appreciation by voting with thumbs-up 👍 at the top so that I get a more realistic indication of readers interest in what I share in my spare time.