{"id":50847,"date":"2022-11-21T00:00:00","date_gmt":"2022-11-21T00:00:00","guid":{"rendered":"https:\/\/www.techopedia.com\/aws-cloud-migration-dos-and-donts\/"},"modified":"2022-11-16T20:43:48","modified_gmt":"2022-11-16T20:43:48","slug":"aws-cloud-migration-dos-and-donts","status":"publish","type":"post","link":"https:\/\/www.techopedia.com\/aws-cloud-migration-dos-and-donts\/2\/34892","title":{"rendered":"AWS Cloud Migration: Dos and Don’ts"},"content":{"rendered":"
Moving an IT infrastructure<\/a> 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.<\/p>\n I've seen quite a few cloud migrations<\/a> in my career and, in this article, I would like to share some simple thoughts to help DevOps engineers<\/a>, architects, managers and anyone else who may be involved in their organization's move to the cloud. (Also read: <\/strong>Cloud Migration Strategy: 10 Mistakes to Avoid<\/strong><\/a>.)<\/strong><\/p>\n But first, some disclaimers:<\/p>\n With that said, here are the dos and don'ts of AWS cloud migration:<\/p>\n If a person migrates to a new location, they should consider that:<\/p>\n When a company migrates to the cloud, they should ask similar questions. These could include:<\/p>\n 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.<\/p>\n 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.<\/p>\n What are drivers for your company's cloud migration? What problems do you want the migration to resolve? What goals should it achieve?<\/p>\n Be specific about those answers: If you intend to reduce costs<\/a>, then calculate the sum. If you intend to improve availability, then define a clear service level objective.<\/p>\n Your business case will be the number one document for your migration. All other artifacts should be based on it.<\/p>\n Don't base your data analysis on manually created spreadsheets or verbal communication; let machines collect data about inventory and usage statistics.<\/p>\n The more precise data you collect, the better. AWS' Migration Evaluator service will help you to do this in most cases.<\/p>\n Create a portfolio of workloads<\/a> to migrate, analyze them, choose a migration strategy for each, choose some for the pilot\/first wave migration, estimate timelines and prepare a plan.<\/p>\n Execute the migration after that. Repeat until the migration portfolio is empty. Share the data. Have subject matter experts review it.<\/p>\n 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<\/a> responsible for creating a strategy and defining a good standard of living in the cloud.<\/p>\n your CCoE should include people with a variety of subject matter expertise, including:<\/p>\n 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.<\/p>\n Don't fear revisiting any policy. Make changes as new factors come to light.<\/p>\n 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.<\/p>\n 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: <\/strong>Experts Share the Top Cloud Computing Trends<\/strong><\/a>.)<\/strong><\/p>\n 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.<\/p>\n A business may come and say, "We have to migrate to the cloud very fast. Let's lift and shift<\/a> quickly right now."<\/p>\n 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<\/a> were quite old and some OS-level dependencies didn't work on AWS' hardware.<\/p>\n Assess what you have, analyze it, analyze the business case — and think.<\/p>\n Why are you migrating? If you can't answer that question, you probably need to either find an answer or not migrate at all.<\/p>\n 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<\/a>.<\/p>\n 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<\/a> is the reason you're migrating, measure it, define your SLO and ensure availability is the main thing you consider in your target state.<\/p>\n Don't treat workloads you migrate as a "black box<\/a>."<\/p>\n 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.<\/p>\n Capturing information about your systems is the most important task when you do planning. (Also read: <\/strong>Data Silos: What They Are and How to Deal With Them<\/strong><\/a>.)<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n 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?<\/p>\n 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.<\/p>\n Remember: Cloud migration is the process of moving a data center<\/a>'s capabilities<\/em> to infrastructure as a service<\/a> (IaaS) providers. The key word here is "capabilities" — you aren't migrating your servers<\/a>, virtual machines<\/a>, hardware<\/a>, data or anything else. A business migrates its capabilities.<\/p>\n To accomplish this, there are seven cloud migration strategies: relocate, rehost (lift and shift), replatform, repurchase, rearchitect\/refactor, retain and retire.<\/p>\n Here's a bit of information on each:<\/p>\n Host some workloads on-premise and move them as-is to the cloud.<\/p>\n 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:<\/p>\n This is also known as "lift and shift<\/a>." The rehosting strategy involves converting virtual machines\/servers on-premise to virtual machines in the cloud. Examples include:<\/p>\n We migrate a workload to a cloud-native platform without rearchitecting systems.<\/p>\n Examples:<\/p>\n We replace some custom\/old system with SaaS<\/a>. Examples of this strategy include:<\/p>\n Change your application's architecture to be cloud-native and use managed cloud services. That also includes rebuilding from scratch.<\/p>\n Examples:<\/p>\n Eliminate a piece of workload that is not needed anymore. For example, log servers are not needed anymore as migrated applications use CloudWatch.<\/p>\n Leave your workload on-premise. Usually, this is temporary.<\/p>\n An example of this strategy might be: You have a huge oracle database<\/a> 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: <\/strong>7 Reasons Why You Need a Database Management System<\/strong><\/a>.)<\/strong><\/p>\n\n
Dos<\/span><\/h2>\n
1. Conduct a Cloud Readiness Assessment<\/h3>\n
\n
\n
2. Create a Business Case<\/h3>\n
3. Automate Discovery and Data Collection<\/h3>\n
4. Manage Your Portfolio<\/h3>\n
5. Build a Cloud Center of Excellence<\/h3>\n
\n
6. Do Well Architected Framework Reviews<\/h3>\n
7. Plan to Modernize<\/h3>\n
Don'ts<\/span><\/h2>\n
1. Do Exactly What Another Business Did<\/h3>\n
2. Migrate Without Clear Goals<\/h3>\n
3. Migrate in a Black Box<\/h3>\n
4. Forget About Well Architected Framework Pillars<\/h3>\n
5. Use One Strategy for Everything<\/h3>\n
The Seven Cloud Migration Strategies<\/span><\/h2>\n
1. Relocate<\/h3>\n
\n
2. Rehost<\/h3>\n
\n
3. Replatform<\/h3>\n
\n
4. Repurchase<\/h3>\n
\n
5. Rearchitect<\/h3>\n
\n
6. Retire<\/h3>\n
7. Retain<\/h3>\n
Conclusion<\/span><\/h2>\n