Cloud Migration

Strategies and Best

Practices
Apoorva Mital

(C) Larsen & Toubro Infotech | Privileged & Confidential

 Introduction Cloud Migration
Understanding Migration Process Overview:
and its Business Drivers A Phased Approach

Contents
Common Application Cloud Migration
Migration Strategies Process
Which Strategy is Right Deep Dive into the
phases
for Me?

2
 Introduction: Understanding Migration & its Business Drivers

What is Migration?

Moving a meaningful portion - not necessarily all - of your organization’s existing IT assets to the cloud is considered a “migration.”
A migration might consist of moving a single data center, a collection of data centers or some other portfolio of systems that is larger than a
single application.

Common Business Drivers

Some of the common drivers that customers consistently apply when migrating to the cloud:
• Operational Costs: Key components of operational costs are unit price of infrastructure, the ability to match supply and demand, finding a
pathway to optionality, employing an elastic cost base, and transparency.
• Workforce Productivity: Typically, productivity is increased by two key factors: not having to wait for infrastructure, and having access to the
breadth and depth of AWS with over 90 services at your disposal that you would otherwise have to build and maintain. A workforce
productivity improvements of 30-50% following a large migration is common
• 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
• Operational Resilience: Reducing your organization’s risk profile will also reduce the cost of risk mitigation. With 16 Regions comprising 42
Availability Zones (AZs), AWS has the global footprint to improve uptime, thereby reducing your risk related costs
• Business Agility: Migrating to the AWS Cloud helps increase your overall operational agility. This lets you react to market conditions more
quickly through activities such as expanding into new markets, selling lines of your business, and acquiring available assets that offer a
competitive advantage.
©Larsen & Toubro Infotech Ltd. Privileged and Confidential 3
 The 5-Phase Migration Process – High Level Overview
“With the five-phase migration process, you start with the least complex application to learn how to migrate while
learning more about the target platform, and then build toward the more complex applications”
1
Migration Preparation and
Business Planning
If you don’t have a plan, you may be
planning to fail
• Developing a sound business case for migration
• This requires taking into account your objectives
along with the age and architecture of your existing
applications, and their constraints
• Engaged leadership, frequent communication, clarity
of purpose, along with aggressive but realistic goals
and timelines make it easier to justify the decision to
migrate
2 3, 4
Portfolio Discovery and
Planning
Crawl, Walk, Run
• Full portfolio analysis of your environment, complete
with a map of interdependencies between
applications, as well as migration strategies and
priorities, will help build a successful migration plan
• The complexity and level of business impact of your
applications will influence your migration strategy
• Beginning the migration process with less critical &
complex applications in your portfolio creates a
sound learning opportunity for your team to exit
their initial round of migration with:
o Confidence that they are not practicing with
mission critical applications in the early
learning stages
o Foundational learnings they can apply to
future iterations
o Ability to fill skills and process gaps and
positively reinforce best practices now based
on experience
©Larsen & Toubro Infotech Ltd. Privileged and Confidential
Designing, Migrating and
Validating Applications
Agile, Flexible, Iterative
• In these phases, the focus shifts from the portfolio
level to the individual application level
• Each application is designed, migrated, and
validated according to one of the six common
migration strategies (“The 6 R’s”)
• A continuous improvement approach is often
recommended in these phases by applying the
iterative methodology in these phases.
5
Modern Operating Model
Shift to cloud
• As applications are migrated, you optimize your new
foundation, turn off old systems, and constantly
iterate towards a modern operating model.
• Your operating model will be an evergreen set of
people, processes, and technologies that constantly
improves as you migrate more applications
4
 The Six Common Application Migration Strategies: “The 6 R’s”
1 2
Rehost
(“lift-and-shift”)
• This entails migrating your physical servers and
virtual machines as-is to the cloud. Most
applications are rehosted in a large-scale legacy
migration scenario where organizations are
looking to migrate quickly to meet a business case
• Most rehosting can be automated with tools such
as AWS Server Migration Service (SMS), although
some customers prefer to do this manually
• Customers have realized that even without
implementing any cloud optimizations, they could
save roughly 30% of its costs by re-hosting.
4 5
Repurchase
(“drop and shop”)
• This is a decision to move to a newer version or
different solution, that is your organization is
willing to 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
Replatform
(“lift, tinker-and-shift”)
• This entails making a few cloud optimizations in order
to achieve some tangible benefit, without changing
the core architecture of the application
• For example : you may be looking to reduce the
amount of time you spend managing database
instances, so you move to a database-as-a-service
offering like Amazon Relational Database Service
(Amazon RDS) or migrating your application to a fully
managed platform like AWS Elastic Beanstalk.
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, and
direct your team’s attention toward maintaining
the resources that are widely used
©Larsen & Toubro Infotech Ltd. Privileged and Confidential
3
Refactor/Re-architect
• Re-imagine how the application is architected and
developed using cloud-native. This driven by a strong
business need to add features, scale, or improve
performance that would otherwise be difficult to
achieve in the application’s existing environment
• If your organization is looking to boost agility or improve
business continuity by moving to a service oriented
architecture (SOA) this strategy may be worth pursuing-
even though it is often the most expensive solution.
6
Retain
• Organizations retain portions of their IT portfolio
because there are some that they are not ready to
migrate and feel more comfortable keeping them
on-premises, or
• they are not ready to migrate an application that
was recently upgraded and then make changes to it
again
5
Six Common Migration Strategies: Detailed View Diagram

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 6

 Employing the 6 R’s: Which Migration Strategy is Right for Me?
While there is no one-size-fts-all answer to determining the correct strategy for application migration, the focus should be
on grouping each of the IT portfolio’s applications into buckets defined by one of the migration strategies.

Selecting the right migration strategy depends on your organization’s business driver/objectives for cloud adoption and
constraints w.r.t time, cost and resource requirements.

Business Drivers Recommended Migration Path

▪ In a large-scale legacy migration scenario where an ▪ Re-hosting (lift and shift) strategy (IaaS)
organization is looking to scale migration quickly to achieve
quick benefits (cost, security etc..)

▪ If an organization is migrating for cost avoidance i.e.

eliminating the need for costly hardware refreshes and ▪ Re-Platform strategy (PaaS)
maintenance programs and time is not a primary constraint

▪ If an organization is looking to boost business agility, business

continuity or to improve overall performance, scalability and
the desire to move to a more agile, DevOps model, which can ▪ Re-architect strategy (PaaS, SaaS)
be achieved by moving to a service oriented architecture
(SOA).
▪ Time and Cost are not primary constraints here

▪ An organization wants to move their back-office technology

▪ Repurchase strategy (SaaS)
(HR, accounting etc..) to an as-a service licensing model
©Larsen & Toubro Infotech Ltd. Privileged and Confidential 7
Employing the 6 R’s: Which Migration Strategy is Right for Me?
The figure below shows the comparison of the different cloud migration strategies in terms of Effort (Time & Cost)
& Opportunity to optimize

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 8

Employing the 6 R’s: Which Migration Strategy is Right for Me?
The figure below shows the comparison of the different cloud migration strategies in terms of Time to migrate &
Efforts (Cost & Skills)

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 9

 Phase 1
Deep Dive: Migration Preparation and Business Planning
The primary focus of this phase is to build a clear and compelling migration business case that provides the
organization’s leadership with a data-driven rationale to support the initiative.
A migration business case covers inputs on 4 cost/value categories, as shown in table below:
Category Inputs for Consideration
• Total Cost of Ownership (TCO) comparison of run costs on AWS post-migration vs. current operating
model
Run Cost Analysis • 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)
• Migration planning/consulting costs
• Compelling events (e.g., planned refresh, data center lease renewal, divestiture)
Cost of Change • Change management (e.g., training establishment of a Cloud Center of Excellence, governance, and
operations model)
• Application migration cost estimate, parallel environments cost
• Estimate of reduction in number of hours spent conducting legacy operational activities (requisitioning,
racking, patching)
Labor Productivity
• Productivity gains from automation
• Developer productivity
• Agility (faster time to deploy, flexibility to scale up/scale down, mergers and acquisitions)
• Cost avoidance (e.g., server refresh, maintenance contracts)
Business Value
• Risk mitigation (e.g., resilience for disaster recovery or performance)
• Decommissioned asset reductions
AWS Tools & Accelerators
The AWS Simple Monthly Calculator The AWS Total Cost of Ownership (TCO) Calculator
©Larsen & Toubro Infotech Ltd. Privileged and Confidential 10
 Phase 2
Deep Dive: Portfolio Discovery and Planning
The primary focus of this phase is Application discovery, Application Portfolio Analysis and Migration Planning.
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
• Application Discovery provides you with the required data for project planning and cost estimation. It includes data collection from
multiple sources, the most common source being 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 (such as, matching Amazon EC2 instance types)
• It is recommended to use automated discovery tools instead of manually performing discovery which is highly time consuming. The
discovery tools can automate the discovery of all the applications and supporting infrastructure including sizing, performance, utilization,
and dependencies.
• An application discovery tool can:
o Automatically discover the inventory of infrastructure and applications running in your data center and maintain the inventory by continually
monitoring your systems.
o Help determine how applications are dependent on each other or on underlying infrastructure
o Inventory versions of operating systems and services for analysis and planning.
o Measure applications and processes running on hosts to determine performance baselines and optimization opportunities
o Provide a means to categorize applications and servers in a way that’s meaningful to the people involved in the migration
©Larsen & Toubro Infotech Ltd. Privileged and Confidential 11
 Phase 2
Deep Dive: Portfolio Discovery and Planning
AWS built discovery tool - Application Discovery Service (ADS) discovers server inventories and
performance characteristics through either an appliance connector for virtual servers, or agents installed
onApplication
physical orPortfolio
virtual hosts.
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 earlier, will be used) for
migrating the given pattern.
• The result of this analysis is a broad categorization of resources aligned by common traits. Examples of this high-level analysis are:
o The majority of the servers are Windows-based with a consistent standard OS version. Some of the servers might require an
OS upgrade.
o Distribution of databases across multiple database platforms: 80% of the databases are Oracle and 20% are SQL Server.
o 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.
o Grouping of resources across type of environment: 50% production, 30% test, and 20% development
o Scoring and prioritizing based on different factors: opportunity for cost saving, business criticality of the application, utilization
of servers, and complexity of migration.
o 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.
©Larsen & Toubro Infotech Ltd. Privileged and Confidential 12
 Phase 2
Deep Dive: Portfolio Discovery and Planning
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.
• The migration plan considers critical factors such as the migration order for workloads, when resources are needed, and tracking
the progress of the migration. It is recommended the project 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:
o Define project management methods and tools to be used during the migration
o Define and create the Migration Project Charter/Communication Plan, including reporting and escalation procedures.
o 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
o Procure and deploy project management tools to support the delivery of the project
o Identify key resources and leads for each of the migration work streams defined in this section
o Outline resources, timelines, and cost to migrate the targeted environment to AWS
o Technical Planning which includes taking the application portfolio analysis data and building an initial backlog of prioritized
applications. 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.

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 13

 Phase 3, 4
Deep Dive: Designing, Migrating and Validating Applications
In these phases, the focus shifts from the portfolio level to the individual application level. Each application is
designed, migrated, and validated according to one of the migration strategies.

First Migrations - Build Experience

• It is important to develop migration skills and experience early to help you make informed choices about your workload patterns.
• It is recommend migrating three to five applications first. 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 Migration Readiness and Planning (MRP) in order to develop an approach and schedule
that accommodates your selections.
• 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. I provides validation and testing of the operational and security processes

Migration Execution Process

• In the early migrations, you tested specific migration patterns and your team 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.
©Larsen & Toubro Infotech Ltd. Privileged and Confidential 14
 Phase 3, 4
Deep Dive: Designing, Migrating and Validating Applications
Migration Execution Process

• Every application in the migration execution phase 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(DTI). Examples of DBI are application owner, roadmap, cutover plans, and operation runbooks
and 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.

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

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 15

 Phase 3, 4
Deep Dive: Designing, Migrating and Validating Applications

Design
▪ 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

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 runs 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 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.

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 16

 Phase 3, 4
Deep Dive: Designing, Migrating and Validating Applications

Validate
▪ 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

AWS Migration Tools & Accelerators

Server & Database Migration: Data Migration:
• AWS Server Migration Service (SMS) • Amazon S3 Transfer Acceleration
• AWS Database Migration Service (DMS) • AWS Snowball
• VMware Cloud on AWS • AWS Snowmobile
• CloudEndure Migration • AWS Direct Connect
• Amazon Kinesis Firehose

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 17

 Phase 5
Deep Dive: Operate and Optimize
This is post migration phase where, after you have migrated a set of applications to cloud, you should look to leverage
cloud for additional benefits for elasticity, higher availability, Security etc.. Subsequently, you should focus on how you can
further optimize your cloud-based application in order to increase cost savings.

Leverage the Cloud

• Leverage other AWS services viz. Auto Scaling Service, Amazon CloudFront, Amazon Elastic MapReduce (EMR)
• Automate elasticity and SDLC processes
• Harden security
• Create dashboard of your Elastic Datacenter to manage AWS resources
• Leverage multiple availability zones to achieve high availability and create a Business Continuity Plan (BCP)

Optimization
• Understanding your Usage Patterns to optimize usage
• Improve efficiency
• Implement advanced monitoring and telemetry (AWS SNS, AWS CloudWatch Logs, AppDynamics etc.)
• Track your AWS Usage and Logs
• Re-engineer your application (To build a highly scalable application, some components may need to be re-engineered to run optimally
in a cloud environment. Some existing enterprise applications might mandate refactoring so that they can run in an elastic fashion)
• Decompose your relational databases

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 18

Additional Resources

• https://aws.amazon.com/whitepapers (AWS Whitepapers)

• https://aws.amazon.com/cloud-migration/
• https://d1.awsstatic.com/whitepapers/cloud-migration-main.pdf
• https://azure.microsoft.com/mediahandler/files/resourcefiles/cloud-migration-essentials-
e-book/Cloud_Migration_Essentials_E-Book.pdf

©Larsen & Toubro Infotech Ltd. Privileged and Confidential 19

©Larsen & Toubro Infotech Ltd. Privileged and Confidential