Best Practices for Cloud Migration

AWS Approach

1 Cultivate conviction & alignment across senior leadership 

Migrating to the cloud is much more than a technology or technical transition. When done properly, cloud migration can transform and modernize your entire organization, creating new efficiencies and capabilities that accelerate innovation throughout every business department. 

It’s a big change—and in business, big changes don’t stick unless they’re backed by firm commitments from leadership. So, before cloud migration can begin in earnest, you’ll need to ensure that you establish buy-in across all key stakeholders. Failing to do so will lead to false starts, overextended timelines, and results that don’t live up to expectations.
To foster cloud migration, buy-in, start by identifying concrete goals that everyone within your organization can support (see Best Practice #2 for more detail). Then create timetables and benchmarks for achieving those goals, along with mechanisms that accurately measure progress and communicate it to the larger team. Inertia is a powerful corporate tool, so be sure to use it to your advantage. Don’t procrastinate—keep initiatives continuously moving forward. When you encounter stalls, implement solutions or workarounds as quickly as possible to avoid missing milestones and losing momentum (see Best Practice #7 for more on this). 

2 Identify top-down, quantifiable goals 

To ensure executive buy-in—and, more importantly, overall cloud migration success—you’ll need to identify aggressive, top-down quantifiable goals that force your organization to move faster than it would organically. Let’s take a look at an AWS customer example to illustrate this point. 

Several years ago, former CIO and current CFO of GE, Jamie Miller, embarked on a quest to accelerate the company’s journey into the cloud. She gathered the top technical leaders at the company and informed them that she intended to migrate 50 applications to AWS in 30 days.
Miller’s announcement was met with skepticism and predictions of failure. But she pushed on, confident that her goal could be met. While GE did ultimately fall eight applications short of Miller’s objective, the company’s experience of migrating 42 applications to AWS in one month enabled it to codify its security and governance models and generate momentum. The team’s skepticism transformed into excitement, with ideas for migrating and modernizing more applications flowing in from every direction.
Today, GE is in the process of migrating more than 9,000 workloads to AWS while reducing its data center footprint from 34 to four. The GE Oil & Gas division has started this journey by migrating more than half of its core applications to AWS while achieving a 52 percent reduction in its total cost of ownership.
These efforts mark the realization of new, aggressive, top-down quantifiable goals that could never have been set—let alone achieved—if Miller hadn’t pressed the company to speed up its move to the cloud years ago.
That’s why setting aggressive goals and remaining focused is so important—it empowers your organization to stop talking about migration and start doing it. Once those efforts are underway, you’ll likely be surprised at how soon you can reach milestones and generate tangible, quantifiable business outcomes. And even if you do come up short, you’ll still quickly gain a wealth of experience that will inform your continuing efforts and solidify your business case. 

3 Establish accountable leaders & train your teams 

You’ll find it difficult to achieve your top-down quantifiable goals unless your whole team is on board—committed to achieving the vision, excited to build new skills, and prepared to work in completely new ways. 

The good news:
All evidence suggests that most techies love working in the cloud. What’s not to love? The cloud offers a chance to learn new skills, test and play around with new ideas, explore new technologies, and improve the pace of your company’s digital transformation. Most people will jump at the opportunity to grow. But you may find that there are those who resist change. Any resistance will, at best, hinder your progress and, at worst, derail the whole venture and growth plan. 3 Establish accountable leaders & train your teams
So here’s what you do:
When you have buy-in for your transformation goals, you can clearly and firmly communicate the certainty of the cloud journey: It’s non-negotiable, there’s senior executive sponsorship, and the results will be transformative for the business.
Of course, there are bound to be worries—your data center team members will soon find themselves operating in a hybrid world, with progressively fewer on-premises resources to manage and an abundance of new and innovative cloud technologies to master. It’s essential that you articulate exactly how their roles will change, over what timescale, and, more importantly, highlight what opportunities they will have in the cloud-led world.
You can help overcome those hurdles by staffing your teams with a single accountable lead. This person—ideally someone who is passionate about cloud transformation and has at least a basic level of cloud understanding and capabilities—will be responsible for keeping their team focused on broader business goals while also measuring and reporting progress to senior management. 

4 Get quick and early wins to build experience and your business case 

As discussed in Best Practice #2 (top-down, quantifiable goals), achieving initial cloud migration success usually requires a push. Don’t let your efforts get stuck in analysis paralysis— just get started! Ship something to production that has immediate, tangible benefits. 

You need to prove that the journey is worth it and that there are fantastic, tangible benefits from going to the cloud. To keep everyone engaged, it’s best to do this as quickly as possible. Begin by identifying one or more applications that can move quickly and easily to the cloud and will deliver highly visible benefits to the organization.
AWS can help you with this first step by conducting an application portfolio analysis. We have the right tools to help you review all your applications and classify them into three basic categories: 1) easy to move, 2) medium or hard to move, and 3) save for last. By focusing your initial efforts on the first category—applications that can easily lift-and-shift to the cloud, with minimal or no rearchitecting—you can score some early wins and gain measurable results to solidify your business case. This will also help you crystallize your approach and uncover learnings that you can incorporate before attempting larger, more complex migrations. 

5 Trust the process & capitalize on modernization opportunities 

We understand that every migration is different; however, based on our experience with over a million active customers and helping organizations of all ages, industries, and geographies migrate to the cloud, we have seen a standardized migration process take shape. 

This process can generally be broken into three phases of activities: 1) assess, 2) mobilize, and 3) migrate and modernize. Following the process across each of these phases is essential to success. We’ll explain why as we go, but let’s start by taking a deeper look at these phases individually, showing you how AWS can help you properly implement them and achieve the best results.
The first phase involves assessing your organization’s current readiness for operating in the cloud. In the last Best Practice, we talked briefly about how AWS can help you with this phase by conducting an application portfolio analysis. Now, let’s look at the assessment stage more holistically and see what other AWS services and products can help you along the way.
A number of AWS tools enable you to assess your on-premises resources and build a right-sized and optimized cost projection for running applications in the cloud. That initial assessment enables you to deep dive into building your business case by understanding the right resources you will need to run your workloads on AWS.
Our Migration Readiness Assessment is a process of gaining insights into how far along you are in your cloud journey, understanding your current cloud-readiness strengths and weaknesses, and building an action plan to close identified gaps. You can use the AWS Cloud Adoption Framework (CAF) and its six perspectives (business, people, governance, platform, security, and operations) as a guide to help ensure that you have a holistic view of the transformation initiative that is required for an effective move to the cloud.
Next, you’ll need to¬¬ mobilize your organization with a detailed migration plan and a refined business case.
In this phase, you’ll address gaps in your organization’s readiness that were uncovered in the assessment phase, with a focus on building your baseline environment (aka the “landing zone”), driving operational readiness, and developing cloud skills.
A strong, achievable migration plan starts with a deeper understanding of the interdependencies between applications and evaluates migration strategies to meet your business case objectives. One critical aspect of developing your migration strategy is to collect application portfolio data and rationalize applications using the seven common migration patterns: relocate, rehost, re-platform, refactor, repurchase, retire, or retain. (We’ll get deeper into these “7 R’s” in the next section, Best Practice #6.)
While not every decision in a migration can be automated, there are a number of AWS tools you can use to drive smarter migration choices and processes. The AWS Application Discovery Service automatically collects and presents detailed information about application dependencies and utilization to help you make more informed decisions as you plan your migration.
AWS Migration Hub automates the planning and tracking of application migrations across multiple AWS and partner tools, allowing you to choose the migration tools that best fit your needs.
Finally, it’s time to migrate and modernize your applications while optimizing operations along the way.
During this phase, each of your applications will be designed, migrated, and validated. AWS Migration Hub allows you to quickly get progress updates across all your migrations, easily identify and troubleshoot any issues, and reduce the overall time and effort spent on your migration projects.
While migrating with AWS, you iterate on your new foundation, turn off old systems by cutting those over, and constantly evolve toward a modern operating model. Your operating model becomes an agile set of people, processes, and technology that improves as you migrate more applications and gain invaluable experience operating in the cloud.
Many enterprises use the migration effort to also modernize their businesses by refactoring their legacy technology portfolio. Taking this opportunity to modernize will accelerate innovation and increase agility, resiliency, and efficiency to transform your speed to market and customer outcomes. Some proven ways to do that include:
> Infrastructure automation (elastic infrastructure, containers, introducing AI/ML into automation)
> Agile development practices (DevOps, test automation, CI/CD, observability)
> Cloud-native architectural patterns (stateless, microservices, serverless, data lakes, AI/ML in applications)
> Product-based operating models (product teams, business outcome alignment, full-stack vs. platform structures)
As you iterate and migrate more applications, you will be able to drive repeatability and predictability in processes and procedures. That’s why it’s so important to trust the process and continue to go through the three phases described above—the more you migrate, the better and faster you’ll get at it, easing the transition and helping you unlock the full benefits of the cloud. 

6 Choose the appropriate migration pattern & embrace hybrid IT 

There’s more than one way to migrate an application. Common migration patterns usually follow one of seven basic patterns, what we refer to as “The 7 R’s.” 

Creating a detailed strategy that identifies the best pattern(s) for your applications is essential to creating/ sustaining momentum and capitalizing on opportunities for modernization along the way. As you embark on this major transformation, embrace hybrid architectures that will help you sustain your business, while migrating to the cloud. Below are the details on each of these seven patterns as we see them adopted most often by our customers. 

1. Relocate: Regarding AWS migrations specifically, this option allows you to move vSphere-based applications to the cloud without changing them in any way.
   
2. Rehost: Also known as “lift-and-shift,” this pattern is often used for large-scale migrations that need to be completed quickly.
3. Re-platform: Sometimes called “lift-tinker-and-shift,” this option involves making a few cloud optimizations to achieve tangible benefits, but without changing the core architecture of the application.
4. Repurchase: Casually referred to as “drop and shop,” this is a decision to replace your current environment by moving to a newer version of software or purchasing an entirely new solution.
5. Refactor: Also called “rearchitecting,” this pattern involves changing the way the application is architected and developed, usually in an effort to add or enhance capabilities. This is often done with modern application development technologies and practices that generally function better in the cloud, such as serverless computing, microservices, containers, and continuous integration/ continuous delivery (CI/CD). 
6. Retain: Choose this option for applications you plan to keep on-premises. We recommend you remain open to migrating them later—but for now, you can use AWS Outposts to combine them with your cloud assets for a truly consistent hybrid experience. We’ll talk more about hybrid in just a moment.
7. Retire: Simply decommission or archive unneeded portions of your IT portfolio.

While most applications can be easily migrated to the cloud, some applications remain on-premises—necessitating a hybrid IT architecture. 
Inevitably, there will be a period—which could last for some years—where you’re operating a hybrid architecture, with some applications and workloads in the cloud and others staying on-premises. You’ll need to periodically prioritize and re-evaluate what to move and what to keep, especially as the pace of innovation in the cloud opens up new opportunities virtually every day.
During this time, you’ll need to continue to communicate your cloud-first plan: For every application—from the newest web service to the oldest legacy system—the question isn’t “Why the cloud?” but “Why NOT the cloud?”
You’ll need a well-thought-out strategy that sees you increasingly moving legacy applications into the cloud—including the big, monolithic, complex legacy applications that are critical to your business, by using either the repurchase or the refactor approach.
A small proportion of these legacy applications may need to live on-premises for a foreseeable amount of time. These are the ones for which there’s a good answer to the basic cloud-first question: “Why NOT the cloud?” It may be that the data is too sensitive, the application can’t be rearchitected, the application has low latency or local data processing requirements, or the data can’t be moved for data sovereignty regulations. Look into AWS Outposts here, to get rid of your legacy data center assets.
To ensure you have a hybrid IT architecture that meets your needs today and tomorrow, you’ll want to choose a cloud provider that has the breadth and depth of services and features to address the broad spectrum of hybrid use cases, from integrating on-premises IT resources with cloud resources to delivering cloud services, APIs, and operating models to your on-premises and disconnected edge locations.
Getting everyone on board and having a well-thought-out, well-documented, and well-communicated hybrid strategy will make this transition period easier to manage and faster to complete. 

7 Avoid stalls, sustain & accelerate momentum 

Choosing the right migration pattern (one of the “7 R’s”) for the right workloads can help you avoid stalls and slowdown in the process. 

Before we get into methods to overcome stalls, let’s understand why migration and modernization stalls usually happen in the first place. Since we referred to the methods of migration as “patterns,” we’ll call these barriers “anti-patterns.” 

Anti-pattern #1: Continuous renewal of executive buy-in 

You’ll need to ensure that your migration business case is strong enough to maintain continuity throughout personnel changes and the departure and arrival of critical leadership stakeholders. Failing to do so can trap you in a cycle of continuous executive buy-in renewal. When new leaders enter your organization, you’ll lose precious time representing the argument for migration and awaiting approval. 

Anti-pattern #2: Slow cycle plan with big projects 

Attempting to migrate too much at once over too long of a timeline can create substantial migration stalls. A workload usually consists of many components, modules, and dependencies (such as storage, load balancer, etc.). Trying to migrate and modernize everything simultaneously may mean dealing with too many challenges all at once. As migration timelines get longer, business benefits get further and further delayed—jeopardizing your company’s commitment to the project. A modern approach—and a way out of this anti-pattern—could be to gradually chip away parts of a monolith in modular fashion onto a cloud native architecture. 

Anti-pattern #3: Non-convergent pursuits 

It’s tempting to jump into migration with the goal of addressing big problems to achieve flashy results. While setting your sights high is a good thing in general, keep in mind that those “big problems” and “flashy results” take on very different forms across various parts of the organization. This anti-pattern occurs when disparate teams and departments within a business are looking toward migration to achieve non-convergent goals. Perhaps one team wants to fix application architecture and assumes that making it modular would help issues, while another believes adopting agile engineering processes is the silver bullet. At the same time, the Operations team may try to automate away the processes in order to appear to drive efficiency. These are all valid pursuits but pulling parts of organizations in different directions without having a convergent point is unlikely to produce desired results for anyone. 

Anti-pattern #4: Serialized, dependent execution 

While non-convergent pursuits are a major cause of migration stalls, pursuits that converge in too singular a fashion can be just as detrimental. If the entire migration effort is focused on one business impact or goal, it can become dependent on serialized execution—wherein, if one element fails at a particular step, the whole project is halted and unable to proceed. Creating a migration plan with several interdependent activities can slow down teams. Organizations exhibiting this anti-pattern often address migration in serial order—building automation, building the productivity platform, defining access tiers, and then finally arriving at application architecture.
This anti-pattern can manifest in a number of ways. Perhaps the organization is forced to wait on the development of a DevOps platform or for all the components of cloud foundation to be fully adopted before workloads can start to use them. Or the central IT team restricts the development team’s access to services until the organization-wide foundation tier is built. No matter how it happens, businesses can avoid this anti-pattern by ensuring they balance non-convergent pursuits in a way that doesn’t cause them to converge in a serial, waterfall-like process.
So how can you avoid these stalls? One way is to refactor existing infrastructure, architecture, portfolio, and organization in small increments to deliver business value quickly and continuously. This can be achieved by keeping your organization focused on what we like to call “The Five Dimensions,” and two elements of the “Modern Technology Strategy”: 

The Five Dimensions 

1. Infrastructure automation 

Create reusable, repeatable mechanisms using automation and free up valuable engineering resources for repetitive, time-consuming, human error-prone tasks.
2. Builder springboards
Use self-service reference architecture, templates, CI/CD, zero down time deployments, and built-in monitoring/logging/notifications to create a builder-friendly platform with reusable patterns and libraries that helps developers accelerate their ideas from inception to production. 

3. Ubiquitous access to data 

Identify the types of data you need and their sources—aggregations, trends, reports, archives, etc. Consider how much of this data needs to be real-time vs. periodic and how/if/when that data will be consistent across different geographies. Establish mechanisms that democratize data within your organization through consumable nuggets of access patterns and insights, and empowering team members to choose the right tools for the right job. 

4. Architecture evolution 

Build modular, scalable, reliable architecture. This will enable rapid composition, easier experimentation, and multi-axis scaling, while containing issues to isolated modules through built-in support for failover and failback policies ultimately preventing the domino impact of failure from impacting the entire system. 

5. Organization for value 

We’ve seen many customers make great strides across the previous four dimensions, but struggle with the organizational changes needed to hold them all together. To avoid this, your business must establish fixed accountability and ownership of all services. This can be done by rethinking organizational approaches to your people, processes, and cultural practices, ensuring that all are working together to achieve the same values—both internally and for your customers.
We’re not recommending that you attempt to apply all five of these dimensions to your entire organization all at once. Migration and modernization success means starting fast but also starting small. Choose a concrete task, project, goal—or even a single application or feature—and see how you can rethink it to deliver on the five dimensions. Scale from there, applying your learnings as you go.
Conceptually, rallying around the five dimensions is critical to sustaining momentum in your migration and modernization initiatives. But there are other ways to think about the five dimensions, other than how they have been outlined above. Another viewpoint we’ve found helpful is to deliver on the five dimensions from a value perspective. This larger objective can be broken into two elements: 

1. Vertical slicing: The best way to experience the flavors of all layers of the cake is to cut is vertically—and the same is true for cloud migration. To drive early business results, gain momentum, validate components across architecture, and to prove value across all five dimensions, first prioritize use cases and carefully select an initial MVP scope. Then use resources to create new capabilities or enhance/simplify existing ones. Finally, deploy the MVP to customers, analyze the results, and iterate to optimize further. Now that team has learned the flavor of the different complexities involved, share the slices by splitting up your initial MVP team to seed new product teams. Harden shared services for infrastructure and tools. Finally, execute a change management plan that includes training and skills development. 

2. High frequency deliveries: Deliver more often to validate the hypothesis and value proposition. This will help enable innovation across all your lines of business.
The “Five Dimensions” and “Two elements” are most successful when jointly sponsored by both technology and business functions. Identify technology and business sponsors and set the tone for a value-driven sponsorship. Then organize teams within those partnerships around the creation of new features, services, or products. 

8 Build your Cloud Enablement Engine 

Now that you’re (ideally) operating in a cloud-first world, a DevOps operating model becomes the norm. 

With this transition comes a frequent assumption that implementing DevOps “correctly” means giving developers the ability to manage the full lifecycle of their applications and the platform services that support them.
While there will certainly be specific use cases where this “full stack, full lifecycle” approach to DevOps makes sense, most enterprises will benefit from having a central team that handles the undifferentiated heavy lifting of configuring and integrating AWS platform services on the developers’ behalf. This is especially true for large enterprises with a varied application portfolio.
This approach ensures the platform services supporting your applications adhere to corporate standards for architecture, operational excellence, security, and compliance—as well as financial controls—without burdening developers with these platform governance concerns.
Implementing a core team for these platform services frees development teams to focus on maximizing the business impact—and value—of their applications. Developers can then migrate and optimize their applications faster, using standardized, self-service enterprise capabilities.
This core team within your company becomes your “Cloud Enablement Engine.”
Your Cloud Enablement Engine (CEE) provides products and shared services to your internal customers. These products and services accelerate cloud adoption while keeping adoption sustainable and secure.
There are two key components to your Cloud Enablement Engine:
> Cloud Business Office (CBO): The CBO provides products or services for business and financial management and governance and ongoing training, as well as change management to ensure the organization successfully embraces adapting to life in the cloud.
> Cloud Platform Engineering (CPE): The CPE team configures and codifies the AWS platform to align with enterprise standards for architecture, operations, security, and finance. CPE then packages and continuously improves these standards as self-service deployable products and consumable services.
These products and shared services add up to a large responsibility for the Cloud Enablement Engine. That said, you don’t (and shouldn’t) build it all at once. At AWS, we frequently say, “think big, but start small.” Start with a single, small “Cloud Foundation Team” made up of a product owner, financial analyst, organization change management specialist, and engineering manager and include architects and engineers who have the domain expertise to design and build products related to Platform, Operations, and Security. 

Conclusion & next steps 

Once you’ve proven the cloud value to your business through the first applications your Cloud Foundation Team built and/or migrated, you’ll need a strategy in place to keep your adoption plan moving forward and to see greater benefits from your cloud transformation.
Many leading businesses, such as the ones listed throughout this eBook, have found that the answer is to free up their IT resources with a large-scale, rapid migration of their applications to AWS. When your team sees that you’re committed to rapidly migrating to the cloud, they tend to get on board faster. More people develop cloud skills, and momentum accelerates.
The benefits of breaking free from your legacy IT environment and practices are just too compelling to move slowly:
> Much lower IT costs
> Elevated security and operational resiliency
> The agility to move faster than competitors
> An on-demand environment for experimentation and innovation
> Near-infinite resources to support game-changing initiatives
This is where every organization wants to be—and when “cloud first” becomes your standard, you’re there. You can move fast, deploy new services globally, improve your time to market, free up real estate, innovate on the fly, and respond to changes faster than you would without a cloud-first strategy.

REFERENCES
AWS Migration. Best Practices.