AWS Cloud Migration: Dos and Don’ts

What if one day you are asked to switch to AWS/GCP/Azure/any other cloud provider? That would probably cause a bit of tension, to emphasize the point, wouldn’t it?

I have witnessed quite a few migrations in my career and in this article I would like to share some thoughts to help engineers, architects, DevOps managers or anyone other may participate in such a migration. I’m focused on migrating to AWS primarily because I have expertise in the subject and because it’s fairly universal, but I think these experiences could apply to any other cloud provider.

For this case, I will mention on-premises to cloud migrations because these types of migrations are (in my opinion) much more difficult than cloud-to-cloud migrations.

I will also share my own views on the do’s and don’ts of moving. But distill them through critical thinking and remember that everyone has their own journey and experience. What is good for one person may be bad for another.

What is cloud migration?

Let’s start by defining what a migration is. How do I know if it’s an exodus? I like the following definition:

Cloud migration is the process of moving capacity from a data center to an IaaS provider.

“Ability” is the keyword. A company that doesn’t move servers/virtual machines/hardware/data or anything else. A company moves its capabilities.

There are seven move strategies:

Migration, reorganization (upgrade and change), foundation rebuild, acquisition, restructuring/restructuring, retention and retirement.
For example, I’ve seen situations where a company created a new product that would replace an existing one stored on-premises. The product will be designed to be well-architected and cloud-native from the outset and will be hosted in the cloud. Is this a migration project or a new project? From the above definition, we can say that it is a migration. This is a re-architectural strategy for migration.

What if we buy a new SaaS subscription instead of some software that we host on-premises? This is also an exodus:
An acquisition strategy.

– Let’s dig deeper into these seven more strategies:

To relocate. We host some workloads on-premises and move them as-is to the cloud. This can happen in limited circumstances; when we are migrating cloud-agnostic workloads or when a platform can be cloud-native.

Eg: Migrate on-premises Kubernetes clusters to the cloud or migrate VMware machines using VMware Cloud.

Re-organize. This is also known as lifting and shifting. We convert on-premises VMs/servers into cloud VMs.

Eg: Migrate an on-premises virtual machine to an EC2 instance using Cloud Endure, or create an EC2 instance, install the software and apply the same configuration as on-premises.

Change platform. We migrate workloads to a private cloud platform without re-architecting the system.

Eg: Migrate from PostgreSQL to AWS RDS or from Docker containers to ECS.

Redemption. We are replacing some custom/old systems with SaaS.

Eg: Replace a custom on-premises email system with Send Grid, or replace CRM with Salesforce.

Re-architecture. We re-architect your application to the native cloud and use managed cloud services. This also includes rebuilding from scratch.

Eg: Modify your app code to upload files to S3 instead of local storage or container and migrate to ECS.

Withdraw. We decided that part of the workload would be discarded if not needed.

Eg: The log server is no longer needed because migrated applications use Cloud Watch.

Keep. We leave it there. Usually it is temporary.

Eg: The huge Oracle database with a lot of functionality and customization was not ported to AWS due to the high cost. It was decided to keep it in place until it was replaced by another solution during the modernization period.