6Rs of Migration AWS ReInvent

Identifying Your Migration
Options: The 6 Rs
Nirav Kothari, Principal Consultant
AWS Professional Services
Jeffrey Gelb, Head of Foundational Engineering
Scholastic Inc.
November 30, 2016
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Agenda
In this session, we will cover:
• The 6 Rs of migration
• Assessment-based approach
• Considerations when selecting the various Rs
• Discuss each R of migration strategy
• How Scholastic leveraged the 6 Rs
6 Rs migration strategy
1 • Customers will keep host/application in their • Up-version of the OS and/or database onto the
source environment
4 target cloud
• Minimal analysis/validation of scope and • Some level of application changes
application affinity • Application reinstallation on the target
• Dependency on integrating service • Database to Amazon RDS
management
Retain (Revisit) Replatform
• Application and host decommission on source • OS and/or database porting
2 • No migration to target
5 • Middleware and application change to cloud
• Application owner approvals needed service offering
• Data conversion; Database transition to MySQL,
Amazon Aurora, or other
Retire Refactor
3 • Like for like application migration to target 6 • Application architecture changes may also require
cloud Up-version or Porting
• Minimal effort to make the application work on • Use SaaS-based offerings, application architecture
the target cloud infrastructure (minimal changes may require porting
application layout change) • Middleware, data modernization; application
• Storage migration will be needed (without consolidation/stacking
Rehost conversion) Rearchitect (Replace)
Assessment-based approach
• Financial assessment
• Security assessment
• Compliance and regulatory
assessment
• Business assessment
• Technical assessment
• Contractual assessment
Application considerations
• What is the application roadmap?
• What are the costs associated with this application?
• What improvement options are available to enhance service?
• Are there any risks of not making changes to this application?
• Where does this application align with the technology goals of
the organization?
Mapping drivers to migration strategy
High
Rearchitect (Replace)
Refactor
Business Agility/Value
Replatform
Rehost
Retain (Revisit)
Retire
Low High
Migration Effort
Retain
Physical Machine/Virtual Machine Image
• Unsupported OS and applications
App Binary User Data
Operating System Files • Legacy applications that do not have
Disk Volumes
Memory a business justification for migrating
to the cloud
NIC Disk Drives
Rearchitect
Retain Retire Rehost Replatform Refactor
(Replace)
Retire
• Duplicate resources due to M&A
Operating System Files • Resources part of an existing
Disk Volumes
Memory decommissioning program scope
• Clustered hosts for DR purposes

NIC Disk Drives
• Alternative HA hosts
Rearchitect
(Replace)
Rehost
• Servers running packaged
App Binary User Data App Binary User Data
software
Operating System Files Operating System Files
• Applications without an
Memory Disk Volumes Rehost New Disk Volumes
active roadmap
• Ad hoc, dev, and test

NIC Disk Drives Amazon EC2
environments
Rearchitect
(Replace)
Rehost
Pros Cons
 Speed of migration  Rehost is not OS agnostic; you will retain the
 Reduced risk of migration same OS and settings in the target
environment
 AWS + partner ecosystem-offered tools to
natively support this migration strategy  You may not use AWS services that give you
operational scale like Amazon RDS, Amazon
 Migration could be application, hypervisor, and Redshift, and so on
physical hardware agnostic
 Inherit potentially same application
 Could be automated/tool assisted performance characteristics
 Supports migration of system with  You don’t get to retire much technical debt
configuration
Rearchitect
(Replace)
Best practices for Rehost
• Utilize AWS and/or partner tools for increased velocity of your AWS Server
Migration Service
migration initiative (AWS SMS)
• Set up Migration Factory with AWS/partner help

• Evaluate and understand your infrastructure environment
• Challenge yourself to improved architecture
• Exercise migrations before doing a cutover
Rearchitect
(Replace)
Replatform
Physical Machine/Virtual Machine Image • Changing the OS or
Replatform App Binary User Data DB engine
• Upgrading to the
Operating System Files latest release of an
Fresh New OS application
Memory Disk Volumes
New Disk Volumes • Upgrading the OS
from Windows 2003
to Windows
2008/2012
NIC Disk Drives EC2
• Upgrading from
Oracle 8 to Oracle 11
Rearchitect
(Replace)
Replatform
Pros Cons
 Option to use cloud services that are close to  Some Replatform projects may be time-
existing infrastructure without requiring code consuming and costlier
change, for example, RDS, Amazon Aurora,  Might require both the existing and new
Amazon EFS, Amazon WorkSpaces environment to run in parallel
 No dependency on OS, hypervisor or  Requires additional planning and coordination
underlying physical hardware platform
 Migrating to newer platform/OS/DB
 Opportunity to utilize modern OS/DB
features/functionality
 Automated tools assisted option avaialble in
some cases
Rearchitect
(Replace)
Best practice for Replatform
• Evaluate code dependencies on OS
• Identify any modifications required in the code to port it on a
AWS Database
new OS Migration Service
(AWS DMS)
• Evaluate if porting would require any functionality trade-offs
• Communicate trade-offs with user base and partners
• Wherever possible, break up each functional component and
test them individually
• Consider hybrid environment and plan your migration
appropriately
• If environments are running in parallel, consider DNS switch
method post successful testing
Rearchitect
(Replace)
Refactor
• Changing middleware
App Binary User Data Refactor App Binary User Data • Recoding application
Operating System Files New Operating System components
Disk Volumes New Disk Volumes
• Changing application
Memory
code to utilize cloud
native feature for
EC2
performance, scaling,
NIC Disk Drives
agility
Rearchitect
(Replace)
Refactor
Pros Cons
 Application with a new lifeline, utilizes cloud  Could be complicated
native features  Requires a very good understanding of all
 Increased efficiency, agility at improved cost aspects of the application, compliance,
 Refactor strategy is application code, OS, regulatory, security, code, design, and so on
hypervisor and hardware agnostic  Could be expensive
 Flexibility in porting and globalization  Migration timelines could be extended
 Adaptive to modern consumer needs  Additional resource requirement by the
 Better customer experience business
Rearchitect
(Replace)
Best practice for Refactor
• Scope your Refactoring initiative to a desired business outcome, don’t
make it a reengineering project
• Make sure your code is working as expected and baseline current
functionality and features
• Make sure you have documented test procedures (and tools) for regular
testing after each component of your code is refactored PaaSLane
• Consider this as an opportunity to introduce good CI/CD practice and
tools, this would allow quick development, testing, rollout and rollback
• Break each refactoring down into small project, ensuring the delivered
code matches the desired functionality
• Use automated refactoring tool if there is one available for your use
case; for example, if your application is C++, you might be able to use
Lint, Visual Assist, Visual Studio
Rearchitect
(Replace)
• Changing from RISC to x86
Rearchitect User Data
• Changing application
Operating System Files $aaS on components
Hosted Solution • Rebuilding application
Disk Volumes
Memory architecture
• Replacing the application
with a SaaS offering or COTS
NIC Disk Drives product
• Purchasing a cloud-
compatible license
Rearchitect
(Replace)
Pros Cons
 Eliminating dependency on custom hardware  Careful evaluation of partners/vendors
or proprietary technology platforms required
 With Replace strategy, no infrastructure to  Some Rearchitect use cases grow in time and
maintain effort, covering Replatform, and Refactor
 Pay for what you use with SLAs  Data migration still required, even if Replace is
the strategy
Rearchitect
(Replace)
Best practice for Rearchitect (Replace)
• Evaluate your options, not just from technical functionality perspective, but also
consider integrations with partners, financial viability, and security/compliance or
regulatory requirements
• Build and run in parallel and identify options to keep data between the on premise
and newer system in sync
• Test functionalities in batches; benefits vs. sign-up vs. payroll and so on
• Identify user base that will be testing each functional component of the new
system, migrate in batches as well
Rearchitect
(Replace)
Comparing cloud migration strategies
All dimensions of time, cost and agility are relative to migration strategies presented on this slide
Retain Retire Rehost Replatform Refactor Rearchitect

(Replace)
Time
Cost
Agility
Balanced Rewarding
Case Study
Who is Scholastic?
Who is Scholastic?
• Our mission: To encourage the intellectual and personal

growth of all children, beginning with literacy
• Started in 1920 with a single magazine
• The largest publisher and distributor of children’s books in the
world
• 165 countries, 45 languages
• A leading provider of educational materials in K–8
Strategic things that matter
• Costs
• Uncertainty
• Flexibility
• Risk
• Scale
• Organization
• Strategy and reputation
Key cost factors
• Current costs
• Like for like costs
• Ideal architecture costs
• Pain point costs
• Transition costs
• Opportunity costs
Analysis approaches
• Retain or Rehost: macro analysis

• Replatform, Rearchitect: architectural analysis
• Rehost, Refactor, Rearchitect:
• Cost avoidance, feature/scale requirements
• Retire, Rearchitect, Refactor:
• Business alignment
• Lifespan
Scholastic’s migration mantras
• Everything must go!

• One step at a time
• Find one win
• Improve one thing
• Do or do not, there is no try

• When in doubt, move it
• In the cloud, incremental improvement == $
Scholastic: Retain (Revisit)
• Our example: e-commerce platform

• Why:
• Recent infrastructure investment
• Older technology with few cloud examples
• Proprietary third party software, no obvious support
• Limited depth of expertise in-house
• Limited lifespan
• Cost and risk of moving >> leaving in place

• Limited value in moving
• Outcome: left in place for 2+ years until retired

Scholastic: Rehost <-> Replatform
• Our example: marketing website infrastructure

• Why:
• Status quo was not viable
• Technologies very well supported by AWS
• Strong in-house team
• Low risk migration path
• Lots of independent pieces, easily testable.
• Cost and risk of moving < leaving in place.
• Outcome: migration + upgrades over 3-month span

Scholastic: Rearchitect
• Our example: digital platform

• Why:
• Status quo was not viable
• Desire for investment
• Strong future product growth
• Strong development team
• Good architectural and service fit
• Outcome: Radical cost and performance improvements
Scholastic: Refactor (+ Replatform)
• Our example: identity services

• Why:
• General architecture was stable
• Relatively small changes
• Good match for AWS
• Obvious and self-contained pain points
• Strong development team
• Status-quo at breaking point
• New solution available
• Outcome: launched May, 10x performance benefits, 5–

10x reliability/recovery improvement
Scholastic: Retire
• Our example: legacy web products

• Why:
• EOL technology
• No clear migration path (cloud or other)
• No clear refactoring path
• No clear replatform option
• No funding source or clear ROI horizon
• Overlap with other enterprise options
• Outcome: Almost all legacy technologies retired. Some

product lines retired.
AWS-Provided Migration Tools
Simplify the Journey
Planning Server and DB Data Transfer Post Migration Access partner

Migration Validation tools
AWS Application AWS Server S3 Transfer CloudWatch AWS Marketplace

Discovery Service Migration Service Acceleration
AWS Architecture AWS Database AWS Storage

Center Migration Service Gateway
VMWare Cloud on AWS Snowball

AWS
AWS Direct
Connect
Amazon Kinesis
Firehose
What’s Next?
Application portfolio migration
Application discovery, planning, and migration tracking in one place
Migrate and Operate and

Discover Plan Optimize
Validate
Better understand Streamline app More easily view Reduce time spent
your application migration planning migration progress determining current
portfolio and tracking status
Thank you!
Remember to complete
your evaluations!
Related Sessions
ENT218 - Simplify Cloud Migration with AWS Server Migration Service

ENT312 - Develop Your Migration Toolkit
ARC316 - Hybrid IT: A Stepping Stone to All-In
ARC314 - Enabling Enterprise Migrations: Creating an AWS Landing Zone
For more information, please visit

https://aws.amazon.com/migration/partner-solutions/

6Rs of Migration AWS ReInvent

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

6Rs of Migration AWS ReInvent

Transféré par

Droits d'auteur :

Formats disponibles

Identifying Your Migration

November 30, 2016

Operating System Files • Legacy applications that do not have

Operating System Files • Resources part of an existing

• Clustered hosts for DR purposes

• Ad hoc, dev, and test

• Set up Migration Factory with AWS/partner help

Retain Retire Rehost Replatform Refactor Rearchitect

• Our mission: To encourage the intellectual and personal

• Retain or Rehost: macro analysis

• Everything must go!

• Do or do not, there is no try

• Our example: e-commerce platform

• Cost and risk of moving >> leaving in place

• Outcome: left in place for 2+ years until retired

• Our example: marketing website infrastructure

• Cost and risk of moving < leaving in place.

• Outcome: migration + upgrades over 3-month span

• Our example: digital platform

• Outcome: Radical cost and performance improvements

• Our example: identity services

• Outcome: launched May, 10x performance benefits, 5–

• Our example: legacy web products

• Outcome: Almost all legacy technologies retired. Some

Planning Server and DB Data Transfer Post Migration Access partner

AWS Application AWS Server S3 Transfer CloudWatch AWS Marketplace

AWS Architecture AWS Database AWS Storage

VMWare Cloud on AWS Snowball

Application discovery, planning, and migration tracking in one place

Migrate and Operate and

ENT218 - Simplify Cloud Migration with AWS Server Migration Service

For more information, please visit

Vous aimerez peut-être aussi