AWS Cloud Migration: Dos and Don’ts

Moving an IT infrastructure from one place to another is like moving a human: It's always stressful! But you can minimize this stress by using lessons learned from others' experiences.

I've seen quite a few cloud migrations in my career and, in this article, I would like to share some simple thoughts to help DevOps engineers, architects, managers and anyone else who may be involved in their organization's move to the cloud. (Also read: Cloud Migration Strategy: 10 Mistakes to Avoid.)

But first, some disclaimers:

1. This article focuses primarily on AWS cloud migration because I have a specialization in this subject. However, this information may be applicable to other cloud providers as well.
2. This article focuses mostly on migration from on-premise to public cloud because these migrations are, in my opinion, much more difficult than cloud-to-cloud migrations.
3. What works for one organization might be bad for another. While I'll tell you what's better to do and whaat to avoid in cloud migrations, please filter that through your critical thinking and remember that everybody has their own background and experience.

With that said, here are the dos and don'ts of AWS cloud migration:

Dos

1. Conduct a Cloud Readiness Assessment

If a person migrates to a new location, they should consider that:

• The climate will be different.
• The language spoken in that location may be different.
• The cost of living will be different and perhaps more expensive.

When a company migrates to the cloud, they should ask similar questions. These could include:

• Have we considered all the risks? (Also read: Is Your Organization Aware of These 6 Key Public Cloud Risks?)
• What must be changed for the workload to actually work?
• Do we have the human resources required?
• Do we have the budget to accomplish everything?

Formally asking these questions is called a cloud readiness assessment — it's a long-form interview about the varying organizational processes that identify how ready a company is to live in the cloud.

Cloud readiness assessments are based on the Cloud Adoption Framework (CAF) and allows you to understand what should be changed, process-wise, to live in the cloud successfully. AWS has a cloud readiness assessment tool which covers all of that.

2. Create a Business Case

What are drivers for your company's cloud migration? What problems do you want the migration to resolve? What goals should it achieve?

Be specific about those answers: If you intend to reduce costs, then calculate the sum. If you intend to improve availability, then define a clear service level objective.

Your business case will be the number one document for your migration. All other artifacts should be based on it.

3. Automate Discovery and Data Collection

Don't base your data analysis on manually created spreadsheets or verbal communication; let machines collect data about inventory and usage statistics.

The more precise data you collect, the better. AWS' Migration Evaluator service will help you to do this in most cases.

4. Manage Your Portfolio

Create a portfolio of workloads to migrate, analyze them, choose a migration strategy for each, choose some for the pilot/first wave migration, estimate timelines and prepare a plan.

Execute the migration after that. Repeat until the migration portfolio is empty. Share the data. Have subject matter experts review it.

5. Build a Cloud Center of Excellence

This is part of the Cloud Adoption Framework mentioned above. Before executing the migration, create a Cloud Center of Excellence (CCoE): a team of people responsible for creating a strategy and defining a good standard of living in the cloud.

your CCoE should include people with a variety of subject matter expertise, including:

• Management.
• Operations.
• Platform.
• People.
• Finance.
• Any other department consuming or providing services in the cloud.

Members of your CCoE will prepare a landing zone for the migration, including hard policies and softer policies and, in general, prepare your company for life in the cloud.

Don't fear revisiting any policy. Make changes as new factors come to light.

6. Do Well Architected Framework Reviews

This should occur both during migration waves and after them. This will allow you to avoid foolish mistakes and to get a high-level overview of what you have done from a technical perspective.

7. Plan to Modernize

Prepare a modernization plan along with your migration plan — migration isn't the end of the story! To be effective in the cloud, you have to keep up with it. (Also read: Experts Share the Top Cloud Computing Trends.)

The first modernization is likely to be huge, so it's important to plan this and to schedule budgets and resources in advance. Failure to do this, in many cases, will lead to increased operational costs.

Don'ts

1. Do Exactly What Another Business Did

A business may come and say, "We have to migrate to the cloud very fast. Let's lift and shift quickly right now."

But it's better not to start doing it right away. Are you sure that re-hosting strategy will be faster than some other strategy? In my experience, it hasn't been: When we tried to migrate on-premise VMs using Cloud Endure, it didn't work because the machines' operating systems were quite old and some OS-level dependencies didn't work on AWS' hardware.

Assess what you have, analyze it, analyze the business case — and think.

2. Migrate Without Clear Goals

Why are you migrating? If you can't answer that question, you probably need to either find an answer or not migrate at all.

I've seen situations when businesses wanted to migrate to the cloud to reduce costs. They performed a lift and shift migration without doing a total cost analysis. Only after the fact did they realize it costs even more than was in a colocation center.

To avoid this, define clear goals and define the target state that achieves these goals. If costs are the driver, make the proper calculations and plan accordingly. Cost optimization will be the main thing when you plan your target state. If availability is the reason you're migrating, measure it, define your SLO and ensure availability is the main thing you consider in your target state.

3. Migrate in a Black Box

Don't treat workloads you migrate as a "black box."

It is critically important to know what exactly you migrate, how those things work and their technical requirements and dependencies. That information will allow you to choose the correct strategy for workload migration. If this is not done, there’s an excellent chance you will go down the wrong path.

Capturing information about your systems is the most important task when you do planning. (Also read: Data Silos: What They Are and How to Deal With Them.)

4. Forget About Well Architected Framework Pillars

Migration is stressful. That's why people tend to do it as quickly as possible, focusing on one thing alone: making everything work in the cloud, ASAP.

But if you set aside with well architected framework pillars, you may encounter consequences of which you only understand the severity once risk has materialized.

5. Use One Strategy for Everything

It's always easy to make a single, over-arching plan for all workloads — for example, deciding to do lift and shift and then rehosting everything in the cloud. But what if some things could be retired? What if some components could be replatformed and with little effort?

You will save significant resources by analyzing all of the components of the workload and deciding a unique strategy for every component. Collect data and plan properly.

The Seven Cloud Migration Strategies

Remember: Cloud migration is the process of moving a data center's capabilities to infrastructure as a service (IaaS) providers. The key word here is "capabilities" — you aren't migrating your servers, virtual machines, hardware, data or anything else. A business migrates its capabilities.

To accomplish this, there are seven cloud migration strategies: relocate, rehost (lift and shift), replatform, repurchase, rearchitect/refactor, retain and retire.

Here's a bit of information on each:

1. Relocate

Host some workloads on-premise and move them as-is to the cloud.

This is possible in limited cases, e.g, when we migrate cloud-agnostic workloads or when a platform might be cloud-native. More specific examples of this strategy include:

• Relocating a Kubernetes cluster from on-premise to cloud.
• Relocating VMware machines with VMWare Cloud.

2. Rehost

This is also known as "lift and shift." The rehosting strategy involves converting virtual machines/servers on-premise to virtual machines in the cloud. Examples include:

• Migrating on-premise virtual machines to EC2 instances with CloudEndure.
• Creating EC2 instances, installing the software and applying the same configuration as on-premise.

3. Replatform

We migrate a workload to a cloud-native platform without rearchitecting systems.

Examples:

• Migrating PostgreSQL to AWS RDS.
• Migrating docker containers to ECS.

4. Repurchase

We replace some custom/old system with SaaS. Examples of this strategy include:

• Replacing a custom on-premise email sending system with SendGrid.
• Replacing CRM with salesforce.

5. Rearchitect

Change your application's architecture to be cloud-native and use managed cloud services. That also includes rebuilding from scratch.

Examples:

• Change your apps' code to upload files to S3 instead of local storage.
• Containerize an app and migrate to ECS.

6. Retire

Eliminate a piece of workload that is not needed anymore. For example, log servers are not needed anymore as migrated applications use CloudWatch.

7. Retain

Leave your workload on-premise. Usually, this is temporary.

An example of this strategy might be: You have a huge oracle database with a lot of functions and customization and choose not to migrate it to AWS because it would cost too much. Instead, you decide to keep it on-premise until it's replaced with another solution in the modernization phase. (Also read: 7 Reasons Why You Need a Database Management System.)

Conclusion

If you want to reduce the risks associated with a cloud migration and make it less stressful, don't rush.

You may believe that rushing will save you time and other problems will be managed later, but experience tells us that this is a wrong assumption. In fact, rushing a cloud migration will most likely lead you to the most stressful outcome possible: playing whack-a-mole with the issues you've encountered once you've already moved to your new cloud-based production environment.

Proper engineering principles must be applied to cloud migration. Picking up a bridge and moving it from one river and plunking it down on another never works. The key to migration success is to measure, analyze, design and plan. Migrating a workload to the cloud is hard.