A Cloud Migration Framework — Part 2

In my last blog post, I discussed the importance of following a detailed framework when migrating to the cloud. By doing so, organizations ensure key areas are incorporated into their implementation and migration efforts remain consistent.

This blog post dives deeper to discuss the data-gathering, analysis, dependencies and strategic roadmap phases of any successful framework.

Migration Framework

Requirements Gathering

It is important to develop a clear understanding of the following five elements:

1. Business Requirements

What are the business needs that are driving the want to migrate virtual machines (VMs) to the cloud? Usually this can be in the form of a compelling event that is motivation to engage in this effort. Is there a data center issue? Storage issue? End of life for equipment? It is important to understand the business need for a cloud migration. How else can you know whether you were successful or not?

2. Technical Requirements

What are the technical requirements for the cloud? Are there subscription needs or organization needs that need to be accounted for in the architecture? What are the requirements for authentication and authorization? Role-based access control (RBAC)? Are their firewall constraints? Internet access restrictions? There should be some clear considerations for a cloud architecture.

3. Financial Requirements

What are the primary expectations of results from running workloads in the cloud (such as expected savings or generation of more revenue from e-commerce), and budgetary constraints (what is allocated for the migration and the expected timeframe for completion)? Though these may not be required for an assessment, it is a discussion point to understand how you might interpret the output from the assessment tool. Certainly, it is needed for developing a migration strategy.

4. Applications/Workloads

This is key to understanding the purpose of the assessment. You should have an idea of what application or workloads you wish to migrate. The assessment should target just those workloads, and there needs to be an understanding of the environment and migration goals prior to doing the assessment. Which ones have priority? Why have you chosen those specific virtual machines? Is there anything about those workloads you need to be concerned about (such as clustering, licensing, etc.)? It will also help for a discussion around reserved instances, and if there is an understanding of the functions of the applications (whether they are steady, unpredictable or cyclical).

5. Cloud Strategy

What type of licensing will you be using? This is important when looking at the assessment since most tools have licensing options (EA, pay as you go, discounts, etc.). Understanding how it’s envisioned to work helps in the cost analysis. What is the strategy’s ultimate goal? Cloud first? Hybrid? Understanding what the plan is for the cloud is important to help with the architecture and integration efforts between the cloud and data center.

Financial Analysis

When considering the financial implications of your cloud migration, a couple of key components are enterprise agreements and reserve instances. Let’s break those down:

Enterprise Agreements

The key to the financial analysis is to understand how you plan on paying for the cloud. Do you have an enterprise agreement with Microsoft? Amazon Web Services (AWS) has options for enterprise agreements as well. These agreements tend to provide a discount level to standard pricing provided in the tool. By understanding how your vendor agreement applies, you can focus their attention on that specific financial model.

Reserved Instances

Previously, it was suggested you should have some fairly detailed knowledge of the applications/workloads/VMs that are targeted for cloud usage. Understanding their purpose and planned usage helps with the discussion around reserved instances. Most cloud vendors incorporate prepurchase commitment of services for a specific time period. Use this knowledge of your applications to determine whether you should or should not take advantage of this capability. Many people may not be aware of this option, and may not understand how it works or what use cases are best to take advantage of it. Cloud documentation will usually provide guidance on best use cases, but generally, those applications that are constant, steady-state utilization with minimal changes normally benefit from reserved instance commitment. Those applications that are unstable, load-balanced and require constant adjustments throughout the year normally are not candidates for long-term commitment of resources.

Configuration Analysis

The point of the analysis tools is to allow you to gather the specific data you need to inform your cloud migration decision-making. Most tools provide the following information:

• Storage Size
• Storage IOPS
• Storage Type
• CPU
• Cores
• Memory
• Network Throughput
• OS
• Instance Type
• Comfort Factor

Different tools provide different data, with some more detailed and some less. The value of this information is that it informs discussions internally about “like for like” configurations for the cloud or an optimized/estimated configuration. This discussion should be about what the applications do and what you would like them to do in the cloud. It should open discussions about load balancing, horizontal scaling and other options that the cloud brings to the table. Adjust the tool’s recommendations based upon discussions with application owners.

Remediation

Use this time to talk about remediation of outstanding issues. All tools pretty much provide information on what needs to be done to the VM to qualify for cloud migration.

Extraneous VMs

Review the cost and configuration. Determine if there are VMs included in the analysis that can be removed.

Dependency Mapping

Most tools require agent installation to obtain application dependencies. When planning for a migration, it is critical to involve application owners. Understanding the application dependencies is key to being able to build a roadmap for a migration strategy. The goal of dependency mapping is to segment devices or applications into low-dependency groupings, thereby creating “waves” or “asset groups” that can be migrated together. Each of these groups are then put in a priority order. Priority can be for multiple reasons: Impact on production, criticality of application, test case, etc.

Strategic Roadmap

There are a couple of primary ways to build out your roadmap, from the bottom up and from the top down:

Bottom Up

Bottom up is a method of classifying cloud readiness complexity by working at the machine level. It assumes that you have defined specific machines that are to be migrated. In this case, you can cluster machines based on low or high dependency, and focus on those dependencies.

Top Down

Top down is an application-centric focus where you determine what applications you want to migrate in what order, and resolve dependencies based on application priority.

Each application/VM/workload should be documented as high, medium, low (or red, yellow, green) according to its complexity for obtaining readiness for the cloud.

In my final blog post, I’ll talk about the migration phase of the process, so come back soon.

Learn more about CDW’s broad portfolio of cloud solutions and services.