Aws migration-whitepaper-en

1
AWS Migration Whitepaper
March 2018

2
© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Notices
This document is provided for informational purposes only. It represents AWS’s
current product offerings and practices as of the date of issue of this document,
which are subject to change without notice. Customers are responsible for
making their own independent assessment of the information in this document
and any use of AWS’s products or services, each of which is provided “as is”
without warranty of any kind, whether express or implied. This document does
not create any warranties, representations, contractual commitments,
conditions or assurances from AWS, its affiliates, suppliers or licensors. The
responsibilities and liabilities of AWS to its customers are controlled by AWS
agreements, and this document is not part of, nor does it modify, any agreement
between AWS and its customers.

3
Contents
Introduction 1
The AWS Cloud Adoption Framework (AWS CAF) 2
Motivating Change 4
Business Drivers 5
Migration Strategies 7
“The 6 R’s”: 6 Application Migration Strategies 7
Which Migration Strategy is Right for Me? 10
Building a Business Case for Migration 12
Drafting Your Business Case 14
Items to Consider 14
People and Organization 15
Organizing Your Company’s Cloud Teams 15
Creating a Cloud Center of Excellence 16
Migration Readiness and Planning 18
Assessing Migration Readiness 18
Application Discovery 19
Discovery Tools 20
Application Portfolio Analysis 21
Migration Planning 22
Technical Planning 23
The Virtual Private Cloud Environment 24
Migrating 29
First Migrations – Build Experience 29
Migration Execution 30
Application Migration Process 30
Team Models 32

4
Conclusion 34
Contributors 35
Resources 35
Additional Information 35
FAQ 36
Glossary 37

5
Abstract
Adopting Amazon Web Services presents many benefits, such as increased
business agility, flexibility, and reduced costs. As an enterprise’s cloud journey
evolves from building and running cloud-native applications on AWS, to
mapping out the migration of an entire enterprise IT estate, certain challenges
surface. Migrating at scale to AWS calls for a level of business transformation in
order to fully realize the numerous benefits of operating in a cloud environment,
including changes to tools, processes, and skillsets.
The AWS approach is a culmination of our experiences in helping large
companies migrate to the cloud. From these experiences, we have developed a
set of methods and best practices to enable a successful move to AWS. Here we
discuss the importance of driving organizational change and leadership, how to
establish foundational readiness and plan for migrating at scale, and our
iterative approach to migration execution.
Migrating to AWS requires an iterative approach, which begins with building
and evolving your business case as you and your team learn and uncover more
data over time, through activities like application portfolio discovery and
portfolio analysis. There are the common migration strategies that will inform
your business plan, and a recommended approach to organizing and evolving
your cloud teams as confidence and capability increases. You will stand up a
Cloud Center of Excellence (CCoE) to lead and drive change, evangelize your
cloud migration initiative, establish cloud governance guardrails, and enable
and prepare your organization to provide and consume new services. Our
approach walks you through what it means to be ready to migrate at scale, and
how to establish a solid foundation to save time and prevent roadblocks down
the road. We will cover our approach to migration execution, continuing on with
building momentum and acceleration through a method of learn-and-iterate.

Amazon Web Services – AWS Migration Whitepaper
Page 1
Introduction
Migrating your existing applications and IT assets to the Amazon Web Services
(AWS) Cloud presents an opportunity to transform the way your organization
does business. It can help you lower costs, become more agile, develop new
skills more quickly, and deliver reliable, globally available services to your
customers. Our goal is to help you to implement your cloud strategy
successfully.
AWS has identified key factors to successful IT transformation through our
experience engaging and supporting enterprise customers. We have organized
these into a set of best practices for successful cloud migration. Customer
scenarios range from migrating small, single-applications, to migrating entire
data centers with hundreds of applications. We provide an overview of the AWS
migration methodology, which is built on iterative and continuous progress. We
discuss the principles that drive our approach, and the essential activities that
are necessary for successful enterprise migrations.
Migrating to AWS is an iterative process that evolves as your organization
develops new skills, processes, tools, and capabilities. The initial migrations
help build experience and momentum that accelerate your later migration
efforts. Establishing the right foundation is key to a successful migration. Our
migration process balances the business and technical efforts needed to
complete a cloud migration. We identify key business drivers for migration and
present best strategies for planning and executing a cloud migration.
Once you understand why you are moving to the cloud, it is time to address how
to get there. There are many challenges to completing a successful cloud
migration. We have collected common customer questions from hundreds of
cloud migration journeys and listed them here to illustrate common concerns as
you embark on your cloud migration journey. The order and prioritization will
vary based on your unique circumstances, but we believe the exercise of
thinking through and prioritizing your organization’s concerns upfront is
beneficial:
• How do I build the right business case?
• How do I accurately assess my environment?

Page 2
• How do I learn what I don’t know about my enterprise network topology
and application portfolio?
• How do I create a migration plan?
• How do I identify and evaluate the right partners to help me?
• How do I estimate the cost of a large transition like this?
• How long will the migration process take to complete?
• What tools will I need to complete the migration?
• How do I handle my legacy applications?
• How do I accelerate the migration effort to realize the business and
technology benefits?
These questions and many more will be answered throughout this paper. We
have included support and documentation, such as the AWS Cloud Migration
Portal.1 The best practices described in this paper will help you build a
foundation for a successful migration, including building a solid business plan,
defining appropriate processes, and identifying best-in-class migration tools
and resources to complete the migration. Having this foundation will help you
avoid the typical migration pitfalls that can lead to cost overruns and migration
delays.
The AWS Cloud Adoption Framework
(AWS CAF)
AWS developed the AWS Cloud Adoption Framework (AWS CAF), which helps
organizations understand how cloud adoption transforms the way they work.
AWS CAF leverages our experiences assisting companies around the world with
their Cloud Adoption Journey. Assessing migration readiness across key
business and technical areas, referred to as Perspectives, helps determine the
most effective approach to an enterprise cloud migration effort. First, let’s
outline what we mean by perspective. AWS CAF is organized into six areas of
focus, which span your entire organization. We describe these areas of focus as
Perspectives: Business, People, Governance, Platform, Security, and Operations.
For further reading, see the AWS CAF Whitepaper.2 AWS CAF provides a
mental model to establish areas of focus in determining readiness to migrate
and creating a set of migration execution workstreams. As these are key areas of

Page 3
the business impacted by cloud adoption, it’s important that we create a
migration plan that considers and incorporates the necessary requirements
across each area.
Figure 1: AWS Cloud Adoption Framework People and Technology Perspectives
The following table presents a description of each Perspective and the common
roles involved.
Perspective Description and Common Roles Involved
Business Business support capabilities to optimize business value with cloud adoption.
Common Roles: Business Managers; Finance Managers; Budget Owners; Strategy
Stakeholders
People People development, training, communications, and change management.
Common Roles: Human Resources; Staffing; People Managers.
Governance Managing and measuring resulting business outcomes.
Common Roles: CIO; Program Managers; Project Managers; Enterprise Architects;
Business Analysts; Portfolio Managers.
Platform Develop, maintain, and optimize cloud platform solutions and services.
Common Roles: CTO; IT Managers; Solution Architects.
Security Designs and allows that the workloads deployed or developed in the cloud align to the
organization’s security control, resiliency, and compliance requirements.
Common Roles: CISO; IT Security Managers; IT Security Analysts; Head of Audit and
Compliance.
Operations Allows system health and reliability through the move to the cloud, and delivers an
agile cloud computing operation.
Common Roles: IT Operations Managers; IT Support Managers.

Page 4
Motivating Change
Cultural issues are at the root of many failed business transformations,
yet most organizations do not assign explicit responsibility for culture.
– Gartner, 2016
Culture is critical to cloud migration. Cloud adoption can fail to reach maximum
potential if companies do not consider the impact to culture, people, and
processes, in addition to the technology. On-premises infrastructure has been
historically managed by people, and even with advancements in server
virtualization most companies have not been able to implement the levels of
automation that the cloud can provide. The AWS Cloud provides customers
instant access to infrastructure and applications services through a pay-as-you-
go pricing model. You can automate the provisioning of AWS resources using
AWS service APIs. As a result, roles and responsibilities within your
organization will change as application teams take more control of their
infrastructure and application services.
The impact of culture on cloud, and cloud on culture, does not need to be a
daunting or arduous proposition. Be aware and intentional about the cultural
changes you are looking to drive and manage the people-side of change.
Measure and track the cultural change, just as you would the technology change.
We recommend implementing an organizational change management (OCM)
framework to help drive the desired changes throughout your organization.

Page 5
Table 1: Organizational change management to accelerate your
cloud transformation
The AWS OCM Framework guides you through mobilizing your people, aligning
leadership, envisioning the future state of operating in the cloud, engaging your
organization beyond the IT environment, enabling capacity, and making all of
those changes stick for the long term. You can find additional information on
this topic in the Resources section of this paper.
Business Drivers
The number one reason customers choose to move to the cloud is for the agility
they gain. The AWS Cloud provides more than 90 services including everything
from compute, storage, and databases, to continuous integration, data analytics,
and artificial intelligence. You are able to move from idea to implementation in
minutes rather than the months it can take to provision services on-premises.
In addition to agility, other common reasons customers migrate to the cloud
include increased productivity, data center consolidation or rationalization, and
preparing for an acquisition, divestiture, or reduction in infrastructure sprawl.
Some companies want to completely re-imagine their business as part of a
larger digital transformation program. And, of course, organizations are always
looking for ways to reduce costs.
Common drivers that apply when migrating to the cloud are:

Page 6
Operational Costs – Operational costs are the costs of running your
infrastructure. They include the unit price of infrastructure, matching supply
and demand, investment risk for new applications, markets, and ventures,
employing an elastic cost base, and building transparency into the IT operating
model.
Workforce Productivity – Workforce productivity is how efficiently you are
able to get your services to market. You can quickly provision AWS services,
which increases your productivity by letting you focus on the things that make
your business different, rather than spending time on the things that don’t, like
managing data centers. With over 90 services at your disposal, you eliminate
the need to build and maintain these independently. We see workforce
productivity improvements of 30%-50% following a large migration.
Cost Avoidance – Cost avoidance is setting up an environment that does not
create unnecessary costs. Eliminating the need for hardware refresh and
maintenance programs is a key contributor to cost avoidance. Customers tell us
they are not interested in the cost and effort required to execute a big refresh
cycle or data center renewal and are accelerating their move to the cloud as a
result.
Operational Resilience – Operational resilience is reducing your
organization’s risk profile and the cost of risk mitigation. With 16 Regions
comprising 42 Availability Zones (AZs) as of June 2017, With AWS, you can
deploy your applications in multiple regions around the world, which improves
your uptime and reduces your risk-related costs. After migrating to AWS, our
customers have seen improvements in application performance, better security,
and reduction in high-severity incidents. For example, GE Oil & Gas saw a 98%
reduction in P1/P0 incidents with improved application performance.
Business Agility – Business agility is the ability to react quickly to changing
market conditions. Migrating to the AWS Cloud helps increase your overall
operational agility. You can expand into new markets, take products to market
quickly, and acquire assets that offer a competitive advantage. You also have the
flexibility to speed up divestiture or acquisition of lines of business. Operational
speed, standardization, and flexibility develop when you use DevOps models,
automation, monitoring, and auto-recovery or high-availability capabilities.

Page 7
Migration Strategies
This is where you start to develop a migration strategy. , you want to consider
where your cloud journey fits into your organization’s larger business strategy
and find opportunities for alignment of vision. A well-aligned migration
strategy, with a supporting business case and a well-thought out migration plan,
sets the proper groundwork for cloud adoption success.
One critical aspect of developing your migration strategy is to collect application
portfolio data and rationalize it into what we refer to as the 6 R’s: Re-host, Re-
platform, Re-factor/Re-architect, Re-purchase, Retire, and Retain. This is a
method for categorizing what is in your environment, what the
interdependencies are, technical complexity to migrate, and how you’ll go about
migrating each application or set of applications. Using the “6 R” Framework,
outlined below, group your applications into Re-host, Re-platform, Re-
factor/Re-architect, Re-purchase, Retire and Retain. Using this knowledge, you
will outline a migration plan for each of the applications in your portfolio. This
plan will be iterated on and mature as you progress through the migration, build
confidence, learn new capabilities, and better understand your existing estate.
The complexity of migrating existing applications varies, depending on
considerations such as architecture, existing licensing agreements, and business
requirements. For example, migrating a virtualized, service-oriented
architecture is at the low-complexity end of the spectrum. A monolithic
mainframe is at the high-complexity end of the spectrum. Typically, you want to
begin with an application on the low-complexity end of the spectrum to allow
for a quick win to build team confidence and to provide a learning experience.
This will help build momentum.
It is important to choose an application that has some business impact. You
want to build momentum with each migration; which is difficult to accomplish
if you select an application business owners fail to see value in.
“The 6 R’s”: 6 Application Migration Strategies
The 6 most common application migration strategies we see are:
1. Re-host (Referred to as a “lift and shift.”)

Page 8
Move applications without changes. In large-scale, legacy migrations,
organizations are looking to move quickly to meet business objectives. The
majority of these applications are re-hosted. GE Oil & Gas found that, even
without implementing any cloud optimizations, it could save roughly 30% of its
costs by re-hosting.
Most re-hosting can be automated with tools (e.g. AWS VM Import/Export).
Some customers prefer to do this manually as they learn how to apply their
legacy systems to the new cloud platform.
Applications are easier to optimize/re-architect once they’re already running in
the cloud. Partly because your organization will have developed the skills to do
so, and partly because the hard part — migrating the application, data, and
traffic — has already been done.
2. Re-platform (Referred to as “lift, tinker, and shift.”)
Make a few cloud optimizations to achieve a tangible benefit. You will not
change the core architecture of the application. For example, reduce the amount
of time you spend managing database instances by migrating to a database-as-
a-service platform like Amazon Relational Database Service (Amazon RDS), or
migrating your application to a fully managed platform like AWS Elastic
Beanstalk.
A large media company migrated hundreds of web servers that it ran on-
premises to AWS. In the process, it moved from WebLogic (a Java application
container that requires an expensive license) to Apache Tomcat, an open-source
equivalent. By migrating to AWS, this media company saved millions of dollars
in licensing costs and increased savings and agility.
3. Re-factor / Re-architect
Re-imagine how the application is architected and developed using cloud-native
features. This is driven by a strong business need to add features, scale, or
performance that would otherwise be difficult to achieve in the application’s
existing environment.
Are you looking to migrate from a monolithic architecture to a service-oriented
(or server-less) architecture to boost agility or improve business continuity?

Page 9
This strategy tends to be the most expensive, but it can also be the most
beneficial if you have a good product-market fit.
4. Re-purchase
Move from perpetual licenses to a software-as-a-service model. For example,
move from a customer relationship management (CRM) to Salesforce.com, an
HR system to Workday, or a content management system (CMS) to Drupal.
5. Retire
Remove applications that are no longer needed. Once you have completed
discovery for your environment, ask who owns each application. As much as
10%-20% of an enterprise IT portfolio is no longer useful and can be turned off.
These savings can boost your business case, direct your team’s attention to the
applications people use, and reduce the number of applications you have to
secure.
6. Retain ( Referred to as re-visit.)
Keep applications that are critical for the business but that require major
refactoring before they can be migrated. You can revisit all applications that fall
in this category at a later point in time.
Figure 2: Six most common application migration strategies

Page 10
Which Migration Strategy is Right for Me?
Choosing the right migration strategy depends on your business drivers for
cloud adoption, as well as time considerations, business and financial
constraints, and resource requirements. Re-platform if you are migrating for
cost avoidance and to eliminate the need for a hardware refresh. Figure 3 shows
that this strategy involves more effort than a Re-host strategy but less than a Re-
factor strategy. Re-host the majority of your platform and Re-factor later if your
data center contract will end in 12 months and you do not want to renew.
Figure 3: Comparison of cloud migration strategies
Consider a phased approach to migrating applications, prioritizing business
functionality in the first phase, rather than attempting to do it all in one step. In
the next phase, optimize applications where the AWS Platform can make a
notable difference in cost, performance, productivity, or compliance. For
example, if you are migrating an application that leverages an Oracle database
and your strategy includes replacing Oracle with Aurora PostgreSQL, the best
migration approach may be to migrate the application and stabilize it in the
migration phase. Then execute the database change effort in a subsequent
phase. This approach controls risk during the migration phase and focuses on
the migration business case and value proposition.

Page 11
There are common objectives that will improve application performance,
resilience, and compliance across the portfolio that should be included in every
migration. They should be packaged into the migration process for consistent
execution.
Your migration strategy should guide your teams to move quickly and
independently. Applying project management best practices that include clear
budgets, timelines, and business outcomes supports this goal. Your strategy
should address the following questions:
• Is there a time sensitivity to the business case or business driver, for
example, a data center shutdown or contract expiration?
• Who will operate your AWS environment and your applications? Do you
use an outsourced provider today? What operating model would you like
to have long-term?
• What standards are critical to impose on all applications that you
migrate?
• What automation requirements will you impose on applications as a
starting point for cloud operations, flexibility, and speed? Will these
requirements be imposed on all applications or a defined subset? How
will you impose these standards?
The following are examples:
• We will drive the migration timeline to retire specific facilities and use
savings to fund the transformation to cloud computing. Time is very
important, but we will consider any changes that can be done quickly
and safely while creating immediate savings.
• We will insource core engineering functions that have been historically
outsourced. We will look at technology platforms that remove
operational barriers and allow us to scale this function.
• Business continuity is a critical driver for our migration. We will take the
time during the migration to improve our position. Where application
risk and costs are high, we will consider a phased approach: migrate first
and optimize in subsequent phases. In these cases, the migration plan
must include the second phase.

Page 12
• For all custom development, we will move to a DevOps model. We will
take the time to build the development and release processes and
educate development teams in each application migration plan matching
this pattern.
Understanding your application portfolio is an important step for determining
your migration strategy and subsequent migration plan and business case. This
strategy does not need to be elaborate, but addressing the questions above helps
align the organization and test your operational norms.
Building a Business Case for Migration
IT leaders understand the value that AWS brings to their organization,
including cost savings, operational resilience, productivity, and speed of
delivery. Building a clear and compelling migration business case provides your
organization’s leadership with a data-driven rationale to support the initiative.
A migration business case has four categories: 1) runcost analysis, 2) cost of
change, 3) labor productivity, and 4) business value. A business case for
migration addresses the following questions:
• What is the future expected IT cost on AWS versus the existing (base)
cost?
• What are the estimated migration investment costs?
• What is the expected ROI, and when will the project be cash flow
positive?
• What are the business benefits beyond cost savings?
• How will using AWS improve your ability to respond to business
changes?
The following table outlines each cost or value category.
Table 2: Business case cost/value categorization
Category Inputs for Consideration
Run Cost
Analysis
• Total Cost of Ownership (TCO) comparison of run costs on AWS post-
migration vs. current operating model

Page 13
Category Inputs for Consideration
• Impact of AWS purchasing/pricing options (Reserved Instances, volume
discounts)
• Impacts of AWS discounts (Enterprise Discount Program, service credits, e.g.,
Migration Acceleration Program incentives)
Cost of Change • Migration planning/consulting costs
• Compelling events (e.g., planned refresh, data center lease renewal,
divestiture)
• Change management (e.g., training establishment of a Cloud Center of
Excellence, governance, and operations model)
• Application migration cost estimate, parallel environments cost
Labor
Productivity
• Estimate of reduction in number of hours spent conducting legacy operational
activities (requisitioning, racking, patching)
• Productivity gains from automation
• Developer productivity
Business Value • Agility (faster time to deploy, flexibility to scale up/scale down, mergers and
acquisitions, global expansion)
• Cost avoidance (e.g., server refresh, maintenance contracts)
• Risk mitigation (e.g., resilience for disaster recovery or performance)
• Decommissioned asset reductions
For an enterprise Oil & Gas customer, cost savings was a primary migration
driver. This customer realized additional financial and overall business benefits
through the course of migrating 300+ applications to AWS. For example, this
customer was able to increase business agility, operational resilience, improve
workforce productivity, and decrease operational costs. The data from each
value category shown in the following table provides a compelling case for
migration.

Page 14
Table 3: A case for migration
Drafting Your Business Case
Your business case will go through several phases of evolution: directional,
refined, and detailed. The directional business case uses an estimate for the
number of servers and rough order of magnitude (ROM) assumptions around
server utilization. The purpose is to gain early buy-in, allowing budgets to be
assigned and resources applied. You can develop a refined business case when
you have additional data about the scope of the migration and workloads. The
initial discovery process refines the scope of your migration and business case.
The detailed business case requires a deep discovery of the on-premises
environment and server utilization. We recommend using an automated
discovery tool for deep discovery. This is discussed later in the Application
Discovery section.
Items to Consider
In building your business case, consider the following items:
• Right-size mapping provides estimates of the AWS services (compute,
storage, etc.) required to run the existing applications and processes on
AWS. It includes capacity views (as provisioned) and utilization views

Page 15
(based on actual use). This is a significant part of the value proposition,
especially in overprovisioned virtualized data centers.
• Extend right-size mapping to consider resources that are not required
full time, for example, turning off development and test servers when
not in use and reducing run costs.
• Identify early candidates for migration to establish migration processes
and develop experience in the migration readiness and planning phase.
This early analysis of the application discovery data will help you determine run
rate cost, migration cost, resource requirements, and timelines for the
migration.
AWS has a series of tools and processes that can help you develop your business
case for a migration. The AWS Simple Monthly Calculator can provide
directional business case inputs,3 while the AWS Total Cost of Operation (TCO)
calculators can provide a more refined business case.4 Additionally, AWS has
tools that can help you estimate the cost of migration.
People and Organization
It is important to develop a critical mass of people with production AWS
experience are you prepare for a large migration. Establish operational
processes and form a Cloud Center of Excellence (CCoE) that’s dedicated to
mobilizing the appropriate resources. The CCoE will lead your company
through organizational and business transformations over the course of the
migration effort. A CCoE institutionalizes best practices, governance standards,
automation, and drives change throughout the organization. When done well, a
CCoE inspires a cultural shift to innovation and a change-is-normal mindset.
Organizing Your Company’s Cloud Teams
An effective CCoE team evolves over time, in size, makeup, function, and
purpose. Long-term and short-term objectives, as well as key operating model
decisions, will require adjustments to your team.
In the early stages of cloud adoption, team development begins as a small,
informal group connected by a shared interest—experimentation with cloud
implementation. As the cloud initiative grows and the need for a more
formalized structure increases, it becomes beneficial to establish a CCoE

Page 16
dedicated to evangelizing the value of cloud. While the CCoE establishes best
practices, methods, and governance for your evolving technology operations,
additional small cloud teams form. These small teams migrate candidate
applications and application groupings, commonly referred to as migration
waves, to the cloud environment. The CCoE directs the operating parameters of
the migration teams, and both the CCoE and migration teams provide feedback.
Collectively, lessons are learned and documented, improving efficiency and
confidence through hands-on experience.
Creating a Cloud Center of Excellence
The following are guiding principles for the creation of a CCoE.
• The CCoE structure will evolve and change as your organization
transforms. Diverse, cross-functional representation is key.
• Treat the cloud as your product and the application team leaders as your
customers. Drive enablement, not command and control.
• Build company culture into everything you do.
• Organizational change management is central to business
transformation. Use intentional and targeted organizational change
management to change company culture and norms.
• Embrace a change-as-normal mindset. Change of applications, IT
systems, and business direction is expected.
• Operating model decisions will determine how people fill roles that
achieve business outcomes.
Structure the CCoE to Prepare for Migration at Scale
Designing a CCoE to include people from across impacted business segments,
with cross-functional skills and experiences, is important for successful
migration at scale. you build subject matter expertise, achieve buy-in, earn trust
across your organization, and establish effective guidelines that balance your
business requirements. There is no single organizational structure that works
for everyone. The following guidelines will help you design a CCoE that
represents your company.
A CCoE is comprised of two functional groups: the Cloud Business Office (CBO)
and Cloud Engineering (see Figure 4). The functions of each group will help you
determine who to include in each group and in the larger CCoE.

Page 17
The CBO owns making sure that the cloud services meet the needs of your
internal customer, business services. Business services, and the applications
that support them, consume the cloud services provided by IT. IT should adopt
a customer-centric model toward business application owners. This tenet
represents a shift for most organizations. It is an important consideration when
developing your cloud operating model, CCoE, and cloud team approach.
The CBO owns functions such as organizational change management,
stakeholder requirements, governance, and cost optimization. It develops user
requirements, and onboards new applications and users onto the cloud. It also
handles vendor management, internal marketing, communications, and status
updates to users. You will select IT Leadership responsible for the cloud service
vision, Organizational Change Management, Human Resources, financial
management, vendor management, and enterprise architecture. One individual
may represent multiple functional areas, or multiple individuals may represent
one functional area.
The Cloud Engineering group owns functions such as infrastructure
automation, operational tools and processes, security tooling and controls, and
migration landing zones. They optimize the speed at which a business unit can
access cloud resources and optimize use patterns. The Cloud Engineering group
focuses on performance, availability, and security.
The following figure shows the functional groups that require representation
within your company’s CCoE.
Figure 4: Functional organization of a CCoE

Page 18
Migration Readiness and Planning
Migration Readiness and Planning (MRP) is a method that consists of tools,
processes, and best practices to prepare an enterprise for cloud migration. The
MRP method aligns to the AWS Cloud Adoption Framework and is execution
driven. MRP describes a specific program that AWS Professional Services offers.
However, we highlight the main topic areas and key concepts below.
Assessing Migration Readiness
The AWS Cloud Adoption Framework (AWS CAF) is a framework for analyzing
your IT environment. Using this framework lets you determine your cloud
migration readiness. Each perspective of the AWS CAF provides ways of looking
at your environment through different lenses to make sure all areas of your
business are addressed. Being ready for a large migration initiative requires
preparation across several key areas.
Items to consider:
• Have you clearly defined the scope and the business case for the
migration?
• Have you evaluated the environment and applications in scope through
the lenses of the AWS CAF?
• Is your virtual private cloud (VPC) secure, and can it act as a landing
zone for all applications in scope?
• Have your operations and employee skills been reviewed and updated to
accommodate the change?
• Do you (or does a partner) have the experience necessary to move the
tech-stacks that are in scope?
AWS has developed a set of tools and processes to help you assess your
organization’s current migration readiness state in each of the AWS CAF
perspectives. The Migration Readiness Assessment (MRA) process identifies
readiness gaps and makes recommendations to fill those gaps in preparation for
a large migration effort. The MRA is completed interactively in a cross-group
setting, involving key stakeholders and team members from across the IT
organization, to build a common view of the current state. You may have
representatives from IT Leadership, Networking, Operations, Security, Risk and

Page 19
Compliance, Application Development, Enterprise Architecture, and your CCoE
or CBO. The MRA output includes actions and next steps and visuals like a heat
map (see Figure 5). The MRA is available through AWS or an AWS Migration
Partner.
Figure 5: Migration Readiness Assessment heat map
Application Discovery
Application Discovery is the process of understanding your on-premises
environment, determining what physical and virtual servers exist, and what
applications are running on those servers. You will need to take stock of your
existing on-premises portfolio of applications, servers, and other resources to
build your business case and plan your migration. You can categorize your
organization’s on-premises environment based on operating system mix,
application patterns, and business scenarios. This categorization can be simple
to start. For example, you may group applications based on an end-of-life
operating system, or by applications dependent on a specific database or sub-
system.

Page 20
Application Discovery will help you develop a strategic approach for each group
of applications. Application Discovery provides you with the required data for
project planning and cost estimation. It includes data collection from multiple
sources. A common source is an existing Configuration Management Database
(CMDB). The CMDB helps with high-level analysis but often lacks fidelity. For
example, performance and utilization data need to pair the resources to the
appropriate AWS resource (for example, matching Amazon EC2 instance types).
Manually performing discovery can take weeks or months to perform, so we
recommend taking advantage of automated discovery tools. These discovery
tools can automate the discovery of all the applications and supporting
infrastructure including sizing, performance, utilization, and dependencies.
Items to consider:
• We recommend using an automated discovery tool.
• Your environment will change over time. Plan how to keep your data
current by continuously running your automated discovery tool.
• It may be useful to do an initial application discovery during business
case development to accurately reflect the scope.
Discovery Tools
Discovery tools are available in the AWS Marketplace under the Migration
category. Additionally, AWS has built the Application Discovery Service (ADS).
ADS discovers server inventories and performance characteristics through
either an appliance connector for virtual servers, or agents installed on physical
or virtual hosts.
An application discovery tool can:
• Automatically discover the inventory of infrastructure and applications
running in your data center and maintain the inventory by continually
monitoring your systems.
• Help determine how applications are dependent on each other or on
underlying infrastructure.
• Inventory versions of operating systems and services for analysis and
planning.

Page 21
• Measure applications and processes running on hosts to determine
performance baselines and optimization opportunities.
• Provide a means to categorize applications and servers and describe
them in a way that’s meaningful to the people who will be involved in the
migration project.
You can use these tools to build a high-fidelity, real-time model of your
applications and their dependencies. This automates the time-consuming
process of discovery and data collection and analysis.
Items to consider:
• An automated discovery tool can save time and energy when bringing a
CMDB up to date.
• Keeping the inventory up to date is key as the project progresses, and a
tool helps make this less painful.
• Discovery tools on the market each have their special purpose or
capability, so analyzing this against your needs will help you select the
right tool for your environment.
Application Portfolio Analysis
Application portfolio analysis takes the application discovery data and then
begins grouping applications based on patterns in the portfolio. It identifies
order of migration and the migration strategy (i.e. which of the 6 R’s, out lined
on page 9, will be used) for migrating the given pattern. The result of this
analysis is a broad categorization of resources aligned by common traits. Special
cases may also be identified that need special handling.
Examples of this high-level analysis are:
• The majority of the servers are Windows-based with a consistent
standard OS version. Some of the servers might require an OS upgrade.
• Distribution of databases across multiple database platforms: 80% of
the databases are Oracle and 20% are SQL Server.
• Grouping of applications and servers by business unit: 30% marketing
and sales applications, 20% HR applications, 40% internal productivity
applications, and 10% infrastructure management applications.

Page 22
• Grouping of resources across type of environment: 50% production,
30% test, and 20% development.
• Scoring and prioritizing based on different factors: opportunity for cost
saving, business criticality of the application, utilization of servers, and
complexity of migration.
• Grouping based on 6 R’s: 30% of the portfolio could use a re-host
pattern,30% require some level of re-platforming changes, 30% require
application work (re-architecture) to migrate, and 10% can be retired.
The data-driven insights you get from the application discovery work will
become the foundation for migration planning as you move into the migration
readiness phase of your project.
Migration Planning
The primary objective of the migration plan is to lead the overall migration
effort. This includes managing the scope, schedule, resource plan, issues and
risks, coordination, and communication to all stakeholders. Working on the
plan early can organize the project as multiple teams migrate multiple
applications. The migration plan considers critical factors such as the migration
order for workloads, when resources are needed, and tracking the progress of
the migration. We recommend your team use agile delivery methodologies,
project control best practices, a robust business communication plan, and a
well-defined delivery approach.
Recommended migration plan activities include:
• Review of project management methods, tools, and capabilities to assess
any gaps.
• Define project management methods and tools to be used during the
migration.
• Define and create the Migration Project Charter/Communication Plan,
including reporting and escalation procedures.
• Develop a project plan, risk/mitigation log, and roles and
responsibilities matrix (e.g., RACI) to manage the risks that occur during
the project and identify ownership for each resource involved.

Page 23
• Procure and deploy project management tools to support the delivery of
the project.
• Identify key resources and leads for each of the migration work streams
defined in this section.
• Facilitate the coordination and activities outlined in the plan.
• Outline resources, timelines, and cost to migrate the targeted
environment to AWS.
Technical Planning
Planning a migration goes beyond cost, schedule, and scope. It includes taking
the application portfolio analysis data and building an initial backlog of
prioritized applications. Build the backlog by conducting a deep analysis on
your portfolio by gathering data on use patterns. A small team can lead this
process, often from the enterprise architecture team, which is part of your
CCoE. The team analyzes and prioritizes the application portfolio, and gathers
information about the current architecture for each application. They develop
the future architecture and capture workload details to execute a streamlined
migration. It is not important to get through every application before begging
execution of the plan. To be agile, do a deep analysis of the first two to three
prioritized apps, and then begin the migration. Continue deeper analyses of the
next applications while the first applications are being migrated.
An iterative process helps you avoid feeling overwhelmed by the scale of the
project or limiting your progress as the initial design plans become dated.
Organize applications into migration patterns and into move groups to
determine the number of migration teams, cost, and migration project timeline.
Maintain a backlog of applications (about three 2-week sprints) for each
migration team in the overall project plan. As you migrate, you gain technical
and organizational expertise that you will build into your planning and
execution processes. You will be able to take advantage of opportunities to
optimize as you progress through your application portfolio. The iterative
process allows the project to scale to support migration teams structured by
pattern, business unit, geography, or other dimensions that align to your
organization and project scope.
A high-fidelity model that provides accurate and current application and
infrastructure data is critical to make performance and dependency decisions

Page 24
during your migration phase. Having a well-informed plan with good data is one
of the key enablers for migrating at speed.
Items to consider:
• Application discovery and portfolio analysis data are important for
categorization, prioritization, and planning at this stage.
• An agile approach allows you to use this data for the migration before it
becomes obsolete.
• Iteration helps migrations continue as the detailed plan evolves with
new learnings.
The Virtual Private Cloud Environment
The VPC environment is an integrated collection of AWS accounts and
configurations where your applications will run. It includes third-party
solutions from the AWS Marketplace that address requirements not directly
controlled on AWS. You can implement the AWS CAF Security, Operations, and
Platform Perspectives to migrate and operate in the cloud environment securely
and efficiently. They will be covered together in this section.
Security
Building security into your VPC architecture will save you time and will improve
your company’s security posture. Cloud security at AWS is the highest priority.
AWS customers benefit from the AWS Cloud data centers and network
architectures that are built to meet the requirements of the most security-
sensitive organizations. A compelling advantage of the AWS Cloud is that it
allows you to scale and innovate, while maintaining a secure environment. The
AWS CAF Security Perspective outlines a structured approach to help you build
a foundation of security, risk, and compliance capabilities that will accelerate
your readiness and planning for a migration project. To learn more about cloud
security, see the AWS security whitepapers.5
The AWS CAF Security Perspective details how to build and control a secure
VPC in the AWS Cloud. Figure 6 illustrates the AWS CAF Security Perspective
Capabilities.

Page 25
Figure 6: AWS CAF Security Perspective Capabilities
The AWS CAF Security Perspective is comprised of 10 themes:
• Five core security themes – Fundamental themes that manage risk as
well as progress by functions outside of information security: identity
and access management, logging and monitoring, infrastructure
security, data protection, and incident response.
• Five augmenting security themes – Themes that drive continuous
operational excellence through availability, automation, and audit:
resilience, compliance validation, secure continuous
integration/continuous deployment (CI/CD), configuration and
vulnerability analysis, and security big data analytics.
By using the ten themes of the Security Perspective, you can quickly iterate and
mature security capabilities on AWS while maintaining flexibility to adapt to
business pace and demand.
Items to consider:
• Read the AWS security whitepapers for information on best security
practices.

Page 26
• Engage with AWS to run security workshops to speed up your teams’
understanding and implementation.
• Read the AWS Well-Architected Framework and the AWS Well-
Architected Security Pillar whitepapers for information on how to
architect a secure environment.6, 7
Operations
The AWS CAF Operations Perspective describes the focus areas to run, use,
operate, and recover IT workloads. Your operations group defines how day-to-
day, quarter-to-quarter, and year-to-year business is conducted. IT operations
must align with and support the operations of your business. The Operations
Perspective defines current operating procedures and identifies the process
changes and training that is needed for successful cloud adoption.
Figure 7: AWS CAF Operations Perspective Capabilities
The Operations Perspective helps you examine how you currently operate and
how you would like to operate in the future. Operational decisions relate to the
specific applications being migrated. Determine the appropriate Cloud
Operating Model (COM) for a particular application or set of applications when
envisioning the future state. To learn more about cloud operations, see the AWS

Page 27
operations whitepapers8 and the AWS Well-Architected Operational Excellence
Pillar whitepaper.9
There are different uses and users for applications across your business.
Products and services will be consumed in different patterns across your
organization. Therefore, you will have multiple modes of operating in a cloud
environment. When planning for your migration you will first define the use
cases and actors, and then determine how to deliver the solution.
To build an organization that is capable of delivering and consuming cloud
services, create a Cloud Services Organization. Cloud organizational constructs
such as a CCoE, a CBO, and Cloud Shared Services teams all fall within this
Cloud Services Organization. The last piece of the COM, is the set of capabilities
such as ticketing workflows, service catalogs, and pipelines that are required to
deliver and consume cloud services. These capabilities help the Cloud Services
Organization function effectively.
Items to consider:
• Building a Cloud Center of Excellence early in the process will centralize
best practices.
• Recognize that your organization will have multiple operating models
(e.g., R&D applications are different than back-office applications).
• A managed service, such as AWS Managed Services,10 can reduce the
time needed to solve operational problems in the early phases. It lets
your team focus on improving the migrated applications.
Platform
The AWS CAF Platform Perspective includes principles and patterns for
implementing new solutions on the cloud and migrating on-premises workloads
to the cloud. IT architects use models to understand and communicate the
design of IT systems and their relationships. The Platform Perspective
capabilities help you describe the architecture of the target state environment in
detail.

Page 28
Figure 8: AWS CAF Platform Perspective Capabilities
The Platform work stream provides you with proven implementation guidelines.
You can repeatedly set up AWS environments that can scale as you deploy new,
or migrate existing, workloads. You can establish key platform components that
support flexible, baseline AWS environments. These environments can
accommodate changing business requirements and workloads. Once in place,
your platform can simplify and streamline the decision-making process involved
in configuring an AWS infrastructure.
The following are key elements of the platform work stream:
AWS landing zone – provides an initial structure and pre-defined
configurations for AWS accounts, networks, identity and billing frameworks,
and customer-selectable optional packages.
Account structure – defines an initial multi-account structure and pre-
configured baseline security that can be easily adopted into your organizational
model.
Network structure – provides baseline network configurations that support
the most common patterns for network isolation, implements baseline network
connectivity between AWS and on-premises networks, and provides user-
configurable options for network access and administration.

Page 29
Pre-defined identity and billing frameworks – provide frameworks for
cross-account user identity and access management (based on Microsoft Active
Directory) and centralized cost management and reporting.
Pre-defined user-selectable packages – provide a series of user-selectable
packages to integrate AWS-related logs into popular reporting tools, integrate
with the AWS Service Catalog, and automate infrastructure. It offers third-party
tools to help you manage and monitor AWS usage and costs.
Items to consider:
• If your business is new to AWS, consider a managed service provider,
such as AWS Managed Services, to build out and manage the platform.
• Identify account structures up-front that allow for effective bill-back
processes.
• You will have both on-premises and cloud servers working together, at
least initially. Consider a hybrid cloud solution.
Migrating
First Migrations – Build Experience
MRP develops core operations, security, and platform capabilities to operate at
scale. You will build confidence and momentum for your migration project.
Running applications in the new operating model and environment will help
you mature these capabilities. It is important to develop migration skills and
experience early to help you make informed choices about your workload
patterns. We recommend migrating three to five applications. These
applications should be representative of common migration patterns in the
portfolio.
One example is re-hosting an application using existing server replication tools.
Other examples are re-platforming an application to have its database running
on Amazon RDS, or migrating an application that has internet-facing
requirements and validating the controls and services involved. Choose the
applications before you start the MRP in order to develop an approach and
schedule that accommodates your selections.

Page 30
Working through these initial migrations builds confidence and experience. It
informs the migration plan with the patterns and tool choices that fit your
organization’s needs. It provides validation and testing of the operational and
security processes.
Items to consider:
• Identify patterns (e.g., common architectures, technology stacks, etc.) in
the portfolio to create a list of application groupings based on common
patterns. This creates a common process for group migrations.
• Your first three to five applications should be representative of common
patterns in your portfolio. This will determine the process for moving
that pattern in the mass migration to follow.
Migration Execution
In the early migrations, you tested specific migration patterns and your CCoE
gained experience. Now you will scale teams to support your initial wave of
migrations. The core teams expand to form migration sprint teams that operate
in parallel. This is useful for re-host and re-platforming patterns that can use
automation and tooling to accelerate application migration. In the next section,
we will cover the migration factory process and expand on the agile team model.
Application Migration Process
Specific patterns with larger volumes, such as
re-hosting, offer the opportunity to define
methods and tools for moving data and
application components. However, every
application in the execution phase of a
migration follows the same six-step process:
Discover, Design, Build, Integrate, Validate,
and Cutover.
Discover
In the Discover stage, the application portfolio analysis and planning backlog
are used to understand the current and future architectures. If needed, more
data is collected about the application. There are two categories of information:
Discover Business Information (DBI) and Discover Technical Information

Page 31
(DTI). Examples of DBI are application owner, roadmap, cutover plans, and
operation runbooks. Examples of DTI are server statistics, connectivity, process
information, and data flow. This information can be captured via tools and
confirmed with the application owner. The data is then analyzed, and a
migration plan for that application is confirmed with both the sprint team and
the application owner. In the case of re-host patterns, this is done in groups that
match the patterns. The portfolio discovery and planning process provides this
information.
Design
In the Design stage, the target state is developed and documented. The target
state includes the AWS architecture, application architecture, and supporting
operational components and processes. A member of the sprint team and
engineering team uses the information collected during the Discover stage to
design the application for the targeted AWS environment. This work depends
on the migration pattern and includes an infrastructure architecture document
that outlines what services to use. The document also includes information
about data flow, foundational elements, monitoring design, and how the
application will consume external resources.
Build
In the Build stage, the migration design created during the Design stage is
executed. The required people, tools, and reusable templates are identified and
given to the migration teams. A migration team is selected based on the
migration strategy chosen for the application. The team will use these pre-
defined methods and tools to migrate to AWS. They assert basic validations
against the AWS-hosted application.
Integrate
In the Integrate stage, your migration team makes the external connections for
the application. Your team works with external service providers and consumers
of the application to make the connections or service calls to the application.
The team then run the application to demonstrate functionality and operation
before the application is ready for the Validate stage.
Validate
In the Validate stage, each application goes through a series of specific tests
(that is, build verification, functional, performance, disaster recovery, and

Page 32
business continuity tests) before being finalized and released for the Cutover
stage. Your teams evaluate release management, verify rollout and rollback
plans, and evaluate performance baselines. Rollback procedures are defined by
application within a rollback playbook, which consists of an operations
communication plan for users and defines integration, application, and
performance impacts. You complete business acceptance criteria by running
parallel testing for pre-migrated and migrated applications.
Cutover
In the Cutover stage, you execute the cutover plan that was agreed upon by the
migration team and application owners. Perform a user acceptance test at this
stage to support a successful cutover. Use the outlined rollback procedure in the
cutover plan if the migration is not successful.
Items to consider:
• Make sure the team is familiar with agile practices.
• An iterative approach to maximizes immediate requirements gathering.
You will not do up front work that will be out of date by the time you are
ready to use it.
• The CCoE plays a key role in sharing best practices and lessons learned
across the different migration teams.
Team Models
Core migration teams persist through the project as part of your new IT
operating model. These teams each have their own areas of specialization.
Core Cloud Teams
The Core Cloud teams work across the migration teams. They act as a central
hub for managing projects, sharing lessons learned, coordinating resources, and
building common solutions. These teams include:
Cloud Business Office (Program Control) – Drives the program, manages
resources and budgets, manages and reports risk, and drives communication
and change management. Typically, this team reports to the overall migration
or cloud lead and becomes the program office for your migrations.

Page 33
Cloud Engineering & Operations – Builds and validates the fundamental
components that ensure development, test, and production environments are
scalable, automated, maintained and monitored. This team also prepares
landing zones as needed for migrations.
Innovation – Develops repeatable solutions that will expedite migrations in
coordination with the platform engineering, migration, and transition teams.
They work on larger or more complex technical issues for the migration teams.
Portfolio Discovery & Planning – Accelerates downstream activities by
executing application discovery and optimizing application backlogs. They work
to eliminate objections and minimize wasted effort.
Migration Factory Teams
In the scale-out phase of a migration project, multiple teams operate
concurrently. Some support a large volume of migrations in the re-host and
minor re-platform patterns. These teams are called migration factory teams.
Your migration factory team increases the speed of execution of your migration
plan. Between 20%-50% of an enterprise application portfolio consists of
repeated patterns that can be optimized by a factory approach. This is an agile
delivery model, and it is important to create a release management plan. Your
plan should be based on current workloads and information generated during
the MRP phase. You should optimize it continually for future migration waves
and future migration teams. We recommend that you have a backlog of
applications that support three sprints for each team. This allows you to re-
prioritize applications if you encounter problems that affect the schedule.
Larger and more complex applications often follow the re-factor/re-architect
pattern. They are generally conducted in planned release cycles by the
application owner. The factory teams are self-sufficient and include five to six
cross-functional roles. These include operations, business analysts and owners,
migration engineers, developers, and DevOps professionals. The following are
examples of migration factory teams that are focused on specific migration
patterns:
Re-host migration team – Migrates high-volume, low-complexity
applications that don’t require material change. This team leverages migration
automation tools. This approach is integrated into patch-and-release
management processes.

Page 34
Re-platform migration team – Designs and migrates applications that
require a change of platform or a repeatable change in application architecture.
Re-factor/re-architect migration team – Designs and migrates complex or
core business applications that have many dependencies. In most cases,
development and technical operations teams support this business capability.
The migration becomes a release cycle or a few release cycles within the plan for
that team. There can be many of these in flight, and the role of the CBO is to
track timing, risks, and issues until migration completion. This team owns the
application migration process.
Items to consider:
• Perform a portfolio analysis to understand common patterns across all
applications. This can help build repeatable work for the factory teams
to execute efficiently.
• Use a partner to help with resource constraints as your team supports
regular business activities.
• AWS and the AWS Partner Network (APN) ecosystem can bring
specialized resources for specific topics such as databases, application
development, and migration tooling.
Conclusion
We have introduced both the preparation and execution steps required for large
migrations to the cloud. Analyzing your current state, building a plan, and
iterating the work breaks a large migration into manageable activities for
efficient execution. Looking at a migration as an organizational change project
empowers you to build buy-in and maintain communications through each
stage of the process. Build a business case and refine the return on investment
as the project progresses. Use the AWS Cloud Adoption Framework to analyze
your environment through the different Perspectives: Business, People,
Governance, Platform, Security, and Operations. This gives you a complete view
of which areas to improve before moving forward with a large migration effort.
Use a migration factory construct and iterate the migration patterns to create an
optimal move to the AWS Cloud. Today, migrating to the cloud has moved from

Page 35
asking “why” to asking “when.” Building an effective migration strategy and
plan will change your response to “NOW!”
Migration is just the beginning of what is possible. Once you have migrated an
application, consider your migration experience as a capability that you can use
for the optimization phases for this application. You will have a current
architecture and a future design. You will implement, test, and validate changes.
You will cutover and go live. You now have a new IT capability that can drive
speed, agility, and business value for your organization and your company.
Contributors
The following individuals and organizations contributed to this document:
• AWS Professional Services, Global Migrations Practice
Resources
• AWS Migration Competency and Partners:
https://aws.amazon.com/partners/find
• AWS Whitepapers:
https://aws.amazon.com/whitepapers
• AWS Migration Acceleration Program:
https://aws.amazon.com/migration-acceleration-program/
• AWS Webinar: How to Manage Organizational Change and Cultural
Impact During a Cloud Transformation:
https://youtu.be/2WmDQG3vp0c
Additional Information
Articles by Stephen Orban, Head of Enterprise Strategy at AWS, on cloud
migration:
• http://amzn.to/considering-mass-migration
• http://amzn.to/migration-process
• http://amzn.to/migration-strategies
• http://amzn.to/cloud-native-vs-lift-and-shift

Page 36
• http://amzn.to/migrate-mainframe-to-cloud
FAQ
1. How do I build the right business case?
Your business case should be driven by your organizational KPIs and
common drivers, such as operational costs, workforce productivity, cost
avoidance, operational resilience, and business agility.
2. How do I accurately assess my environment? How do I learn
what I don’t know about my enterprise network topology and
application portfolio and create a migration plan?
Consider the volume of resources used by each application, and automate
the assessment process to confirm that it’s done rapidly and accurately.
Assessing your environment manually is a time-consuming process. It
exposes your organization to human error. Automating the process will
help you gain insight into what you don’t know, and it will help you more
clearly understand and define these uncertainties so they can be factored
into your migration strategy.
3. How do I identify and evaluate the right partners to help me?
Details on Partner offerings can be found at:
o AWS Migration Partner Solutions11
o Migration Solutions in AWS Marketplace12
4. How do I estimate the cost of a large transition like this?
The AWS Total Cost of Ownership Calculator can compare how much it
costs to run your applications in an on-premises or colocation
environment to what it costs on AWS.13
5. How long will the migration process take to complete?
Enterprise migrations that are completed within 18 months generate the
greatest ROI. The duration of a migration depends on scope and
resources.
6. How do I handle my legacy applications?
Consider taking an incremental approach to your migration by
determining which of your legacy applications can be moved most easily.

Page 37
Move these application to the cloud first. For legacy applications that
require a more complicated approach, you can develop an effective plan
for migration.
7. How do I accelerate the migration effort to realize the
business and technology benefits more quickly?
Automate the migration process as much as possible. Using migration
tools from AWS and APN Partners is the best way to accelerate the
migration effort.
Glossary
• Application Portfolio – Collection of detailed information about each
application of an organization, including the cost to build and maintain
the application, and the business value.
• AWS Cloud Adoption Framework (AWS CAF) –A structure for
developing an efficient and effective plan for organizations to successfully
move to the cloud.
• Cloud Center of Excellence (CCoE) –A diverse team of key members
who play the primary role in establishing the migration timeline and
evangelize about moving to the cloud.
• Landing Zone – The initial destination area that is established on AWS
where the first applications operate from to ensure they have been
migrated successfully.
• Migration Acceleration Program (MAP) –Designed to provide
consulting support and help enterprises who are migrating to the cloud
realize the business benefits of moving to the cloud.
• Migration at Scale – The stage in the migration process when the
majority of the portfolio is moved to the cloud in waves, with more
applications moved at a faster rate in each wave.
• Migration Method or Migration Process – Refers to Readiness,
Mobilization, Migration at Scale, and Operate.

Page 38
• Migration Readiness and Planning (MRP) – A pre-planning
service to prepare for migration when the resources, processes, and team
members who will be engaged in carrying out a successful migration to
AWS are identified. Part of the Readiness stage of the migration process.
• Migration Readiness Assessment (MRA) –A tool to determine level
of commitment, competence, and capability.
• Mobilization – The stage in the migration process in which roles and
responsibilities are assigned, an in-depth portfolio assessment is
conducted, and a small number of select applications is migrated to the
cloud.
• Operate – The stage in the migration process when most of the portfolio
has been migrated to the cloud and is optimized for peak performance.
• Readiness – The initial stage in the migration process when the
opportunity is evaluated, the business case is confirmed, and
organizational alignment is achieved for migrating to the cloud.
• Stage – The individual topics of the migration process. Readiness,
Mobilization, Migration at Scale, and Operate are all stages in the
migration process.
1 https://aws.amazon.com/cloud-migration/
2 https://d0.awsstatic.com/whitepapers/aws_cloud_adoption_framework.pdf
3 https://calculator.s3.amazonaws.com/index.html
4 https://aws.amazon.com/tco-calculator/
5 https://aws.amazon.com/whitepapers/#security
6 https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-
Architected_Framework.pdf
7 https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf
8 https://aws.amazon.com/whitepapers/#operations
Notes

Page 39
9 https://d1.awsstatic.com/whitepapers/architecture/AWS-Operational-
Excellence-Pillar.pdf
10 https://aws.amazon.com/managed-services/
11 https://aws.amazon.com/migration/partner-solutions/
12
https://aws.amazon.com/marketplace/search/results?searchTerms=migratio
n&page=1&ref_=nav_search_box&x=0&y=0
13 https://awstcocalculator.com/

Aws migration-whitepaper-en

More Related Content

Similar to Aws migration-whitepaper-en (20)

More from CMR WORLD TECH (20)

Recently uploaded (20)

Aws migration-whitepaper-en