Moving an IT infrastructure from one place to another is like moving a human being: it’s always stressful! But you can minimize this stress by using lessons learned from the experiences of others.
I’ve seen several cloud migrations in my career, and in this article, I’d like to share a few simple thoughts to help DevOps engineers, architects, managers, and anyone else who might be involved in moving their organization to the cloud. (Read also: Cloud migration strategy: 10 mistakes to avoid.)
But first, some caveats:
- This article mainly focuses on migrating to the AWS cloud because I have a specialization in this topic. However, this information may also apply to other cloud service providers.
- This article mainly focuses on migrating from on-premises to public cloud because these migrations are, in my opinion, much more difficult than cloud-to-cloud migrations.
- What works for one organization may be bad for another. While I’m going to tell you what to do and what to avoid in cloud migrations, filter it through your critical thinking and remember that everyone has their own background and experience.
That said, here are the dos and don’ts of migrating to the AWS Cloud:
1. Conduct a cloud readiness assessment
If a person migrates to a new location, they should consider that:
- The weather will be different.
- The language spoken in that location may be different.
- The cost of living will be different and possibly more expensive.
When a business migrates to the cloud, it should ask similar questions. These could include:
Formally asking these questions is called an assessment of cloud readiness: it is a long-lasting interview on the various 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 provide insight into what should be changed, process-wise, to successfully live in the cloud. AWS has a cloud readiness assessment tool that covers all of this.
2. Create a business case
What are the drivers for your company’s cloud migration? What problems do you want the migration to solve? What goals should it achieve?
Be specific about these answers: If you intend to reduce costs, calculate the sum. If you want to improve availability, set a clear service level goal.
Your business case will be the number one document for your migration. All other artifacts should be based on it.
3. Automate data discovery and collection
Don’t base your data analysis on hand-created spreadsheets or verbal communications; allow machines to collect inventory data and usage statistics.
The more accurate data you collect, the better. The AWS Migration Evaluator service will help you do this in most cases.
4. Manage your portfolio
Build a portfolio of workloads to migrate, analyze them, choose a migration strategy for each, pick a few for pilot/first wave migration, estimate timelines, and prepare a plan.
Migrate later. Repeat until the migration wallet is empty. Share data. Ask subject matter experts to look into it.
5. Build a cloud center of excellence
This is part of the Cloud Adoption Framework mentioned above. Before you migrate, build a Cloud Center of Excellence (CCoE): a team of people responsible for building a strategy and establishing a good standard of living in the cloud.
Your CCoE should include individuals with a variety of subject matter expertise, including:
- Any other department that consumes or provides services in the cloud.
Your CCoE members will prepare a landing zone for your migration, including hard policies and softer policies, and generally prepare your business for life in the cloud.
Don’t be afraid to review any policy. Make adjustments as new factors come to light.
6. Make reviews of well-architected frameworks
This should happen both during migration waves and after them. This will allow you to avoid mindless mistakes and get a high-level overview of what you’ve done from a technical point of view.
7. Plan to modernize
Prepare a modernization plan together with your migration plan – migration is not the end of the story! To be effective in the cloud, you need to keep up with it. (Read also: Experts share top cloud computing trends.)
The first modernization is likely to be huge, so it’s important to plan for it and budget and resource ahead of time. Failure to do so will, in many cases, result in increased operating costs.
What not to do
1. Do exactly what another company did
A business can come and say, “We need to migrate to the cloud really fast. Let’s get up and moving fast right now.”
But it’s best not to start doing it right away. Are you sure that the re-hosting strategy will be faster than some other strategy? In my experience, this was not the case: when we tried to migrate on-premises VMs using Cloud Endure, it didn’t work because the machines’ operating systems were quite old and some OS-level dependencies weren’t working on the AWS hardware.
Evaluate what you have, analyze it, analyze the business case and think.
2. Migrating without clear goals
Why are you migrating? If you can’t answer this question, you probably need to find an answer or not migrate at all.
I have seen situations where companies 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 that it costs even more than 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 correct calculations and plan accordingly. Cost optimization will be the main thing when planning your target state. If availability is why you’re migrating, measure it, define your SLO, and make sure that availability is the main thing you consider in your destination state.
3. Migrate to a black box
Don’t treat migrated workloads as a “black box”.
It’s critically important that you know exactly what to migrate, how these things work, and their technical requirements and dependencies. This information will help you choose the right strategy for migrating your workload. If this is not done, there is a very good chance that you are going down the wrong path.
Gathering information about your systems is the most important activity during planning. (Read also: Data silos: what they are and how to manage them.)
4. Forget about well-designed structure pillars
Migration is stressful. That’s why people tend to do it as quickly as possible, focusing on just one thing: getting everything up and running in the cloud, as soon as possible.
But if you set aside the well-designed pillars of the structure, you may encounter consequences that you only understand once the risk has materialized.
5. Use a strategy for everything
It’s always easy to create one all-encompassing plan for all your workloads, for example deciding to lift and shift and then rearranging everything in the cloud. But what if some things could be taken back? What if some components could be replatformed, and with little effort?
You will save significant resources by analyzing all workload components and deciding on a unique strategy for each component. Collect data and plan correctly.
The seven cloud migration strategies
Remember: Cloud migration is the process of moving a data center capacity to infrastructure-as-a-service (IaaS) providers. The keyword here is “capacity” – you’re not migrating your servers, VMs, hardware, data, or anything else. A company migrates its capabilities.
To achieve this, there are seven cloud migration strategies: move, rehost (lift and shift), replatform, repurchase, redesign/refactor, retain, and retire.
Here is some information about each:
Host some workloads on premises and move them as-is to the cloud.
This is possible in limited cases, such as when we migrate cloud-independent workloads or when a platform might be cloud-native. More specific examples of this strategy include:
- Transferring a Kubernetes cluster from on-premises to the cloud.
- Transferring VMware machines with VMWare Cloud.
This is also known as “lifting and moving”. The rehosting strategy involves converting on-premise virtual machines/servers to virtual machines in the cloud. Examples included:
- Migrate on-premises VMs to EC2 instances with CloudEndure.
- Create EC2 instances, install software, and apply the same on-premises configuration.
We migrate a workload to a cloud-native platform without re-engineering systems.
We replace some custom/old systems with SaaS. Examples of this strategy include:
- Replacing a custom on-premise email sending system with SendGrid.
- Replacement of the CRM with the sales force.
Modify your application architecture to be cloud-native and use managed cloud services. This also includes rebuilding from scratch.
- Modify your apps’ code to upload files to S3 instead of local storage.
- Containerize an app and migrate to ECS.
Eliminate a portion of your workload that is no longer needed. For example, log servers are no longer needed since the migrated applications use CloudWatch.
Leave your workload on premises. Usually, this is temporary.
An example of this strategy could be: you have a huge Oracle database with many features and customizations and you choose not to migrate it to AWS because it would cost too much. Instead, you decide to keep it in place until it’s replaced with another solution in the modernization phase. (Read also: 7 reasons why you need a database management system.)
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 handled later, but experience tells us that this is a wrong assumption. In fact, rushing a cloud migration will most likely lead to the most stressful outcome possible: playing catch-up with the problems you’ve encountered once you’ve already moved into your new cloud-based production environment.
Proper engineering principles must be applied to cloud migration. Lifting a bridge and moving it from one river and throwing it down on another never works. The key to successful migration is to measure, analyze, design and plan. Migrating a workload to the cloud is difficult.