Getting ready to migrate to the Amazon Web Services (AWS) Cloud? Companies that are looking to modernize existing business applications often realize the best way to do so is to migrate them to the cloud. By doing so, you can improve agility, performance, and cost savings by moving all, or a key subset, of your workloads to the cloud.

However, many companies struggle to develop the right staff, tools, and processes to migrate quickly and cost-efficiently. Below Logicworks and CloudHealth Technologies share a well-tested methodology for migrating to AWS and how to confront unexpected challenges that can cause major delays or inefficiencies. You should walk away with a clear idea of how to plan and execute your next AWS migration project.

The Migration Process

The process of migrating existing applications to AWS is complex and often involves stakeholders from every part of an organization. Therefore, it’s important to spend time upfront to acknowledge that cloud migration is not just an IT project — it affects many different groups, and often requires a close collaboration between finance, compliance, product, systems, and other teams.

If you are preparing for migration, start by understanding the standard AWS migration process. AWS divides the process into the following five phases:

Each cloud migration project is unique. But the success of any migration depends on understanding your organization’s current and target state, and the steps required to get to the target state. Armed with this information, you can set the right goals and help your team succeed in the cloud.

STEP 1: MIGRATION PREPARATION AND BUSINESS PLANNING

The first step in any migration project is to bring together key stakeholders to discuss and finalize your goals for moving to the cloud.

After helping thousands of organizations move to AWS, the AWS team created the The AWS Cloud Adoption Framework (AWS CAF) to provide guidance for each unit in your organization. According to AWS, the CAF helps each business unit understand how to update skills, adapt existing processes, and introduce new processes to take maximum advantage of the services provided by cloud computing. The AWS CAF is organized into six focus areas to help organize your efforts:

By breaking down the process into focus areas, each business unit can better plan for the impact of cloud adoption. The AWS CAF is usually delivered in the format of a live, in-person workshop, facilitated by an approved AWS CAF workshop partner like Logicworks.

The ultimate goal of the AWS Cloud Adoption Framework is to unify stakeholders and create an action plan designed to move your team from cloud goals to cloud implementation.

STEP 2: PORTFOLIO DISCOVERY AND PLANNING

When tackling a project of significant magnitude, the most challenging part is deciding where to get started. If you already have a project in mind for migration, this step is relatively simple; but if your infrastructure is spread across multiple data centers or multiple teams, without a unified set of metrics for assessing applications, it can be very difficult to identify the set of applications that are best suited for the first wave of migration.

Selecting the right applications for migration is both art and science. A combination of the right data and the right expertise can help you make it through this phase.

UNDERSTAND & DOCUMENT YOUR CURRENT INFRASTRUCTURE.

In order to identify the right applications for migration, you must have a common method for analyzing, documenting, and evaluating your current infrastructure.

This is where using a architecture assessment solution like CloudHealth can help. Using a lightweight agent, CloudHealth collects and analyzes infrastructure performance, usage, and configuration from on-premises or virtualized servers. It funnels that data into a single dashboard, and can even make recommendations for the cost of running that application on the public cloud.

Using a SaaS tool is far more efficient than asking individual data center teams to inventory application infrastructure, which can take many days or even weeks. Data collected from various teams may be in a different format, making comparisons difficult. A unified, SaaS-based assessment process helps business decision makers compare apples-to-apples in order to make the right migration decisions.

DETERMINE WHICH APPLICATIONS TO INCLUDE IN FIRST WAVE OF MIGRATION.

Once you have collected data on your current systems, it is time to determine the best applications for migration.

There are many criteria to determine the “best” applications to migrate; hopefully, in Step 1, you have identified your business’ priorities, and can decide whether you are simply looking for the applications with the greatest cost savings on public cloud (determined through a pricing cat-alog or the CloudHealth platform), or the applications whose developers require greater agility.

If you haven’t migrated to AWS yet, the best approach is to begin migrating the workloads with the fewest dependencies. This allows you to ramp up slowly, building expertise and confidence before tackling the more complex workloads. Another approach is to start with the workloads that have the most over-provisioned, or idle resources. Industry research suggests that as many as 30% of on-premises servers, both physical and virtual servers, are zombies (showing no signs of useful compute activity for 6 months or more). On top of that, more than 35% of servers showed activity less than 5% of the time. As long as you rightsize your cloud deployment on AWS, these workloads will see the greatest price/performance improvements once migrated.

CHOOSE A MIGRATION STRATEGY.

Once you’ve determined your end state and which workloads you will begin with, you must decide on a migration strategy. You may have multiple different strategies depending on the workload, application, and business unit, but organizations typically pick one of the following options:

1. Lift and shift. This approach allows you to keep the application mostly as is, and make any necessary adjustments to run on AWS. This is one of the fastest approaches, and there are many migration tools that can assist with the process.
2. Partial refactor. Some aspects of your applications can remain as is, but other parts may need to be rebuilt to operate properly on AWS. A partial refactor may also leave the existing application as is, and build additional supporting services on top of it.
3. Full refactor. A full rebuild of your application is the most time-consuming approach, but it also represents the greatest opportunity to take advantage of the elasticity and availability of the AWS Cloud. This could also be a good opportunity to break an application down into microservices, or build out a container-based architecture.
4. Transition to SaaS or PaaS. If the workload you are migrating is a commodity application (e.g., email, CRM), or has commodity components (e.g., a relational database), you can incorporate a SaaS or PaaS into the mix. This will help accelerate migration plans, as well as reduce management overhead.

A lift and shift strategy is the simplest and fastest approach, and is the most common method for companies that are migrating their first applications to AWS. However, be aware that you may not see significant cost savings on AWS if you use this method, as you may not be able to use some of the cost saving services of AWS, like horizontal scaling, managed databases, and more.

DECIDE ON THE RIGHT TEAM TO ARCHITECT, BUILD, MIGRATE, AND MANAGE YOUR CLOUD.

A mistake many teams make is to assume that AWS is “easy”. While it is true that you can spin up a new AWS instance in minutes, architecting and managing a growing AWS environment requires the same level of expertise as someone managing any complex system. Your team can choose either to train your existing team in AWS, outsource work to an external team, or to partner with a company like Logicworks that will build, migrate, and manage your cloud alongside your in-house team.

Many companies hire a partner to go through the first phases of migration alongside their team. This allows the internal team to get some experience on AWS, while having the support of an expert AWS team to reduce risks and help you avoid common mistakes.

STEP 3: DESIGN

The last question to consider is tactical, but complex: what will your infrastructure look like on AWS? Which instance types should you use, and in which configurations? Which Reserved Instances should you purchase to maximize your investments?

The ultimate goal of the design phase is to deliver a target reference architecture that is ap-proved by all stakeholders identified in Step 1. This process usually involves the following steps:

• Look at historical performance data across CPU, memory, network, and disk for servers, and across throughput, capacity, and IO for storage.
• Decide how much “headroom” you want to give each asset (typically 25%), and then look at the actual minimum, maximum, and average usage across these metrics to determine which instance type makes the most sense on AWS. A virtual machine is considered undersized when the amount of CPU demand peaks above 70% for more than 1% of any 1 hour. On the other hand, a virtual machine is considered oversized when the amount of CPU demand is below 30% for more than 1% of the time during a 7-day period. Looking at 30 days of history is sufficient, because it is easy to scale up resources on the cloud if you need to. When going through this process, it’s critical to normalize for different generations of physical infrastructure.
• Design a strawman AWS architecture, both in the form of an architecture diagram and a list of proposed services including EC2 instances, EBS volumes, VPCs, etc. and associated costs.
• Share with key stakeholders identified in Step 1. If you involve security and compliance teams in the design stage, you will be much more likely to meet your project deadlines than if you involve them after the infrastructure is built out.

Read the rest of this eBook by downloading it here.