Accelerating Migrations = Recommendations
0 likes138 views
The document provides a comprehensive guide for enterprises on cloud migrations to AWS, focusing on strategies such as 'lift and shift' (re-hosting) and modernization approaches. It outlines the two main AWS migration programs, MAP and EBA, detailing their benefits, requirements, and typical enterprise concerns during migration. Additionally, it emphasizes the importance of identifying application patterns and developing reusable migration playbooks to facilitate successful transitions to the cloud.
Accelerating Migrations = Recommendations
- 1. 1 Transformation Community Accelerating Migrations Prescriptive Guidance for Cloud Migrations Version 1.2.2 Author: Tom Laszewski, Americas Private Equity Transformation Advisor, AWS
- 2. 2 Transformation Community Background Information and Perspective Many enterprises desire a prescriptive guidance on a migration approach to AWS that utilizes a re-host (aka lift and shift) strategy. For those not familiar with the common migration patterns/strategies, they are covered in detail in the Migration strategies and best practices section of this document. In combination with a longer application discovery and analysis project, many enterprises want quick wins and a fast, limited discovery approach for a small subset of cloud migrations that are custom to their particular organization and processes. AWS has 2 high-level approaches to migrations, the Migration Acceleration Program, or MAP, and Experienced-Based Accelerator or EBA. MAP is recommended when a careful, detailed discovery, analysis, and planning phase is acceptable and preferred, which also provides the least risk and highest degree of successful, smooth migration outcomes. Another option is the EBA, which also has a high degree of success, and is for enterprises that are interested in taking a 'do, demonstrate, and show' approach to the migration. They desire to show early, quick success, and leverage this success to drive future investment in migrations. Customer cloud migration sponsors feel that they can use the empirical data from first quick migrations, and extrapolate the (migration and run time) costs of these migrations to help bolster the ROI and TCO business cases of the larger migration project. However, the EBA does require higher upfront resource commitment across certain core parts of the organization (such as shared services, aka networking, directory services, security, governance), high degree of CxO-buy in and support (issues are rapidly escalated, and must be rapidly addressed), and a slighter greater risk appetite given that a full application portfolio discovery and analysis will not have been completed prior to some workloads being migrated. The MAP approach has been used at over 30 customers, such as GE, Capital One, Enel, News Corp, and Coca Cola. The EBA migration approach has successfully been utilized by AWS at over 20 customers including Intel, Nationwide, and Cargill.
- 3. 3 Transformation Community AWS sees enterprises repeatedly ask for an approach based on these common tenets: 1. Re-host - moving workloads 'as is' (aka lift and shift) to AWS, and then re- architect and re-factor these applications once they are successfully running on AWS. 2. Modernize on AWS - First re-host to AWS, then modernize the applications by moving to microservices, AWS managed services, and AWS serverless (native architecture of the cloud) services.
- 4. 4 Transformation Community 3. Speed of execution - moving workloads quickly, before the entire portfolio of applications has been discovered, inventoried, and assessed to provide hands-on experience to ease future migration work. 4. 'Light-weight' portfolio analysis - not looking to initially embark on a multi- month effort to analyze the entire portfolio of applications, application and database inter-dependencies, rather doing that as fast follower using learned knowledge of the first wave of migrations. 5. Common tooling for DR and migration - limit the number of migration tools, and, where possible, utilize the same AWS, vendor, and open source tools for DR (backup and restore / pilot light / full HA) and migrations. 6. Hands on assistance - Enterprises require an AWS System Integrator partner that is highly skilled and has customer success stories, specifically for re- hosting to AWS. The partner must have deep, hands-on AWS 'lift and shift' migration experts. An India presence would be beneficial in most cases. 7. Investment from AWS - Where large investments are made by customer, enterprises require AWS to invest in these migrations as well and have large vendor management teams that need to be involved from the start. 8. VMware first migration - Most enterprises believe that VMware will offer a lower cost of migration, a quicker migration time, and a common set of operational tools to lower the cost of operations and management. VMware is perceived by many as the 'easy button' for a re-host migration to AWS. 9. Migration application patterns - identifying application and workload patterns will help accelerate the migration of applications; these patterns can be be applied to hundreds of workloads with little or no large design phases. The Recommended Approach to Discover section covers this thought process in detail. 10. Reusable playbook/run book - It is imperative playbooks / run books are created for easy (tier 1/bronze), medium (tier 2 / silver), and difficult (tier 3 / gold) applications across a number of different categories (Java/Tomcat/Oracle, .Net/SQL Server, Python/MySQL etc). 11. Looking for an 'easy button' - No easy button, but a migration playbook can make a migration closer to having an 'easy button' for migrations. VMware to VMware Cloud on AWS does make it easier to migrate Aligning business goals and outcomes to a cloud transformation initiative is essential to ensure the correct migration strategy is embarked upon. AWS sees these key business drivers from large customers for cloud transformation: 1. Digital transformation 2. Modern applications (including microservices) 3. Agility (business and technical) 4. New innovation / new customer offering 5. Cost reduction Many have prior experience with the VM and P2V migration during the physical to virtual lifecycles of their on-prem data centers, utilizing technologies such as our partner CloudEndure. CloudEndure has since been acquired by AWS - https://www.crn.com/news/cloud/aws-officially-acquires-dell-backed- cloudendure.
- 5. 5 Transformation Community Technology Landscape This section is a sample of the high level inventory of the current platform technology landscape that most enterprises have that will need to be migrated during the modernization to AWS. Details on software versions, system sizings (CPU/RAM/IO), and specific application types (for example Oracle RAC vs Standard Edition) will need to be collected before decisions are made regarding the migration plans. Applications - Application Servers, 'The code', application files These should be fine to replicate. Includes patches, upgrades, and new releases into production. Also includes the application files - images, files, documents 1. Tomcat 2. WebSphere 3. Cloud Foundry (PaaS) 4. COTS / ISV software (requires a detailed inventory) Middleware data 1. IBM MQ (aka IBM MS Series) for messaging 2. Session state (Active / active will require replication) Databases data 1. Oracle 2. Microsoft SQL Server 3. PostgreSQL 4. DB2 mainframe Operating System 1. Linux 2. Windows 3. MVS A sample high level functional architecture diagram is in Appendix Six. It utilizes mostly Tomcat (60%) for the application tier, with some IBM Websphere (30%) and Cloud Foundry (10%), Oracle, SQL Server and MySQL for the database tier on open systems, DB2 for the database on the mainframe, and VMware for most of the infrastructure operating environment. It is comprises of thousands of VMware instances. SAP is often considered to the be a key component of the overall IT landscape. Discovery - Migration tools to map current environment A phase of the migration where you do want to select one approach, and most likely one (or at most two) tools, is for discovery of your current environment. Because 'one size does not fit all', automated discovery (supplemented with 'manual', people- based, application team discussions) is critical to making sure the correct approach
- 6. 6 Transformation Community and tool is utilized across your software portfolio and within a single application stack. While automated tools can collect tons of data, they cannot always obtain certain non-intrinsic values of a given system without people intervention (for example, this server is DEV, not PROD, it is budgeted under this business unit P&L, etc), unless the customer CMDB has captured this information prior to discovery and the tool supports CMDB import functions. This section focuses on the tools that can help you understand your current platform including infrastructure, and application and database inter-dependencies. With this understanding, enterprises will be in a better position to determine what workloads, applications, and/or databases would be the best candidates to migrate first, as well as which workloads, applications and database inter-dependencies there are. This section covers discovery tools from RISC Networks, Dynatrace, New Relic, and AWS. Dynatrace and New Relic are Application Performance Management (APM) tools that have evolved their products into cloud migration discovery tools. RISC Networks has a heritage in IT Operations and Analytics. 1. RISC Networks - RISC Networks CloudScape is a turnkey cloud assessment solution, designed to simplify the planning, costing and execution of cloud migrations. Webinar with AWS 2. Dynatrace - Dynatrace provides support across the complete migration journey to AWS including application and infrastructure discovery, topology modeling, analytics, performance and user experience monitoring and root cause analysis. 3. New Relic - Provides 360-degree visibility into on-premise and cloud-based applications, with perspectives on infrastructure, application, and end-user experience (synthetic and real). 4. AWS Application Discovery Service - AWS Application Discovery Service helps enterprise customers plan migration projects by gathering information about their on-premises data centers. Customer Examples 1. RISC Networks - Turning Broadcasting https://www.riscnetworks.com/risc- networks-turner-broadcasting-case-study 2. Dynatrace - Landbay https://www.dynatrace.com/company/customers/landbay/ https://www.youtube.com/watch?v=Qvt8XGy0HuI 3. New Relic - REI https://newrelic.com/press-release/20170328 4. New Relic - Dunkin Donuts - https://www.slideshare.net/newrelic/dunkin- mobile-runs-on-new-relic Recommended Approach to Discovery Migration tools are effective at automating the discovery of a company's entire IT landscape. However, enterprises are looking to execute migrations quickly, on a small subset of their thousands of VMware servers. To enable this agile approach, enterprises needs to be thinking about identifying and documenting application
- 7. 7 Transformation Community patterns, and not individual servers, across a subset of the IT portfolio. Enterprises should “bucketize” application stacks (an application-centric migration approach as opposed to workload-centric) based on the criteria that they agree upon at the outset. The more patterns that are developed and tested upfront, the smoother the migration will be. It is recommended that companies test migrating one of each major pattern before starting a larger migration initiative, and document the steps in a runbook so that their migration team can worry about executing and not making decisions on the fly. The four common application patterns (aka 'buckets') typically follow the DR scenario / pattern or operations support tier structure of bronze, silver, gold, and platinum. Here are common characteristics of bronze (tier 1), silver (tier 2), gold (tier 3) and platinum (tier 4) applications: 1. Bronze : Small LAMP-based content management or web application - These application are not mission critical and the relational database size is small (GBs in size). Applications of this size are not mission critical, and have limited application or database dependencies with other applications. If there are dependencies on other applications, they utilize loosely-coupled application constructs such as RESTful APIs. The Recover Time Objective (RTO) and Recovery Point Objective (RPO) are less than 48 hours. Availability is less than 98%. 2. Silver : Medium size .Net, MS SQL Server marketing or HR application - This an application with 10s of TBs and hundreds of transactional users. These applications are critical to the day to day operations of the business, but can absorb some downtime. The Recover Time Objective (RTO) is < 24 hours and Recovery Point Objective (RPO) is < 4 hours. Availability is 98%. 3. Gold : Large size Weblogic, Oracle RAC financial or manufacturing applications - This is an application with up to several PBs of data. The application has a high requirements for availability, scalability, performance, and reliability, These applications are critical to the business, can absorb limited down time. The Recover Time Objective (RTO) is < 2 hours and Recovery Point Objective (RPO) is < 5 minutes. Availability is 99.9%. 4. Platinum : Supersize IBM Websphere, MQ, and DB2 mainframe application - This is an application with hundreds of PBs of data. The application has a high requirements for availability, scalability, performance, and reliability. The Recover Time Objective (RTO) is < 1 hour and Recovery Point Objective (RPO) is < 30 seconds. Availability is 99.99%. The example attributes, RTO / RPO, and availability characteristics are representative of how enterprise companies are stratifying tier 1, 2, 3 and 4 applications. Companies will need to determine the attributes and characteristics for their environment and “score” the technical parameters of the applications in terms of which application would be Bronze or Silver categories for a fast, limited discovery migration, including: 1. Limited inter-dependencies - The databases and application are independent of other applications and databases. If there is any integration with other systems they utilize loosely coupled constructs such as RESTful APIs.
- 8. 8 Transformation Community 2. Size and type of the database - The database is relational and GBs in size. 3. Web applications - Client/Server such as Visual Basic or Powerbuilder are more challenging as they require changes to security, load balancing, and potentially a move to multi-tenancy. 4. Linux and Windows - Workloads that operate in environments other than Linux or Windows cannot be 'lifted and shifted', some re-engineering and re- factoring is required. 5. Low compliance - HIPPA, PCI and workloads that have other compliance needs require more planning and time to migrate. 6. Utilizes a limited number of security, management, and monitoring tools - The more supporting tools the application utilizes the more complex the migration. Most of the consideration to this point has been focused on the technical attributes of the applications. Other attributes that need to be considered include: 1. Is the application going to be retired soon, or be deprecated? 2. What are the licensing costs of running a particular vendor software solution on AWS? 3. Is the is potential significant cost savings achieved by moving the application? 4. Are there business benefits of migrating the application? For example, increased application resiliency and availability, reduced cost of 'run' (management, monitoring), ability to release new features quicker, ability to offer mobile capabilities, enhanced analytics, ability to add AI/ML, etc. Once all the application patterns have been identified and the business benefits determined, the applications can be placed in a matrix similar to below. We are not including Platinum category applications at this time, as these are usually the last applications for migration, post all others migrations when the transition process and ongoing cloud operations are highly optimized. A B C D E F G 1 Java, Tomcat / DB2 Java Websphere / DB2 Java Tomcat / Oracle Java Websphere / Oracle Cloud Foundry 2 Bronze 3 Silver 4 Gold 5
- 9. 9 Transformation Community Once the applications have been placed into specific 'buckets', migration patterns for the migration and the target AWS environment can be identified for each type of application stack. For example, if there is an x86 3-tier lamp stack, the migration team will use AWS Server Migration Service (SMS) and AWS Database Migration Service (DMS), and run Amazon Linux and Aurora - or something along those lines. Migration strategies and best practices Migration to AWS can be achieved using a rehost, re-platform, re-architecture, repurchase, or retire strategy. These five migration strategies or patterns, based on those established by Gartner in 2011, have become industry standard terminology. As a refresher, these migration patterns are defined as: • Rehost - A rehost involves moving the components of the application ‘like for like’ to AWS. The compute is moved to Amazon EC2. The database and application file systems are moved to Amazon EBS. The backup and archiving are moved to Amazon S3 and Glacier respectively. A rehost is also known as a ‘lift and shift’ as it is a ‘forklift’ of the existing application and all its supporting (management, monitoring, DR etc) components to AWS with no changes. • Re-platform – A re-platform is also referred to as “lift, tinker and shift”. This is because it involves minimal changes (tinkering) to optimize the application for the cloud. The re-platform can typically consist of re-platforming an application or database tier to utilize AWS managed services such as Amazon RDS or AWS Elastic Beanstalk. Moving from WebLogic to Apache Tomcat is a re-platform that is done to reduce licensing costs. A migration of the OS from RedHat to Amazon Linux is another example of a re-platform completed for cost savings reasons. • Re-architecture – Re-architecture is more intensive strategy that typically entails using cloud-native features. Migrating your Java or .NET application code from a monolithic architecture to a microservices or serverless architecture is one example. A re-architecture of the database tier could involve a migration of Oracle to Amazon Aurora (MySQL or PostgreSQL). A big data, analytics platform utilizing Oracle Exadata, Netezza, or Teradata can be re-architected to run on Amazon Redshift or Athena (Data Lake), or Microsoft SQL Server to Amazon DynamoDB. • Repurchase – Repurchase is commonly associated with moving to a SaaS platform - CRM to Salesforce.com, an HR system to Workday, a CMS to Drupal, and so on. However, a repurchase cloud simplify involve moving your data integration from Informatica to AWS Glue. Or, replacing your legacy BMC tool with DataDog for AWS infrastructure monitoring. The AWS Marketplace simplifies SaaS repurchase procurement for leading ISV solutions. • Retire – Typically as much as 10% to 20% of an enterprise IT portfolio is no longer useful, and can simply be turned off. It should be considered how long before the application can be entirely gotten rid of. Retire strategies can take
- 10. 10 Transformation Community months or even years. In these cases, it may make sense to rehost the application as the saving in infrastructure, licensing, and support can be add up over the course of several months. More details on these patterns and details on migrating to AWS can be found here: https://aws.amazon.com/cloud-migration/ Rehost++ is a variant of the re-platform migration pattern that does not require changes to the core components of an application migration – application, storage, database, or OS. Therefore, a rehost++ is far less invasive then a re-platform which involve changes to application code, database schema and stored programs, or the OS scripts. Implementing Amazon auto scaling for high availability or implementing AWS CloudWatch for infrastructure monitoring are just two examples of rehost++. Moving a monolithic application to EKS or Fargate is rehost++ pattern that allows you to quickly gain the benefits of microservices, and slowly move application functionality to standard-alone microservices is another. Taking advantage of AWS microservices services add value, but don’t require significant changes to the application code or database. The post migration actions which include optimization, reinvention, automated operations, management, testing, and continuous improvement are often overlooked, or given limited consideration. Failing to plan for these actions will limit your ability to take advantage of the speed, agility, and cost savings of the cloud. You also run the risk of not meeting SLAs because of incidences or outages. For operations, self-healing systems that can recover quickly using integrated failure detection and remediation is a best practice. Platform optimization is achieved by utilizing AWS Well-Architected to consistently implement current AWS architecture best practices across your application portfolio. Chaos Engineering (failure injection) and AWS GameDays are methods of achieving continuous improvement and testing at production scale. Making the choice of which migration pattern to use for each of your application components can be challenging. The business and technical drivers for each of the migration patterns outlined below can help: • Rehost - Cost savings, or compelling events are the typical business drivers. The compelling event could be an imminent data center closure, on-going data center consolidation effort, or pending vendor licensing contract coming due. The people and technical reasons are ease of migration, and no need to implement new tools or technologies and retrain people. • Rehost++ and Re-platform - The business drivers for rehost++ and re- platform are improving business continuity, reducing outages, improving response time, and better application SLAs. The people and technical reasons are implementing new tools and products that are easier to use and save engineers time to focus on new business features and products.
- 11. 11 Transformation Community Rehost++ has a quicker time to market, and re-platform provides a lower TCO and a more attractive long term ROI. • Re-architecture – The business drivers of re-architecture are to fully leveraging the speed, agility, and disruption to business models the cloud provides. The people and technical reasons are to be cloud native to free up engineers' time more than a re-platform. • Replace – The business drivers of a SaaS application migration, are to completely get out of operating or managing any infrastructure or cloud services. This pattern can also be used to replace supporting components of the application stack, for example security, monitoring, management. Doing so provides an opportunity to consolidate tool vendors and to utilize cloud native tools to enable speed and agility. In many cases cost savings can be realized as a result of shifting to an operating expense model. A cloud migration pattern that helps drive up the rate of success is to start with ‘low hanging fruit’ projects to get some quick wins. ‘Low hanging fruit’ is defined here as an application that has low business risk (non-mission critical), is stand alone or has limited integration points, has a small database (under 100 GB), and utilizes a limited number of security, management, and monitoring tools. Two examples of where this pattern has been successful include: the CIO of a multi- national company mandated that 30 applications be migrated in 30 days - the outcome was 20 applications; a manufacturing company migrated 50 applications to an AWS Managed Services landing zone in 50 days. Creating a cloud transformation ‘manifesto’ can help drive consensus at many orgs. A ‘manifesto’ is a document that outlines the company's business and IT priorities and guiding principles of the cloud migration. Overall, the key is to get ahead of the potential post migration challenges, start training people, and identifying the future operating model (RACI diagrams and runbooks for example). A common blocker is the 'lift and shift trap' where once migrated, it is left alone and not optimized, iterated upon, and reinvented to be more cloud-native. A more holistic approach involves identifying and documenting your Cloud Operating Model, and transforming IT teams to a ‘product mindset’. A future whitepaper will dive into best practices and sample patterns for refactoring applications from re-hosted to re- architected. Werner Vogels, Amazon CTO, often has said “There is no compression algorithm for experience”, so with that tenet in mind, the sooner companies begin their migrations for Bronze and Silver apps, the more adept they will become at running at scale in the cloud before their competition achieves a competitive advantage from faster time to market, product/feature creation, increased shareholder value, and lowering costs/product price points.
- 12. 12 Transformation Community Mapping on-premise assets to AWS Mapping of on-premises technologies (vendor products and open sources solutions) to equivalents in AWS is an important aspect of a migration. Slides 9 and 10 of this presentation delivered at the AWS SF summit in 2015 has a high level mappings of technologies from on-premises to AWS: The presentation also has some best practices on migrations. An initial exercise to map on-premises technologies to their AWS counterparts can be helpful, and AWS Solution Architects can assist, here is an example of what results that might provide: A B C D
- 13. 13 Transformation Community 1 Technology on- premises AWS Notes 2 Load Balancer F5 F5, AWS ELB/ALB Limited iRules, ALB has built-in WAF 3 4 Web Server Apache AWS ELB 5 6 Application Server Tomcat Tomcat 7 8 Messaging IBM MQ Amazon MQ or Amazon SQS Amazon MQ supports JMS 9 IBM Message Broker Leave on- premises 1 0 1 1 File shares NetApp AWS EFS, S3 Utilized for file sharing 1 2 Hitachi AWS EBS, EFS, SFTP, Amazon FSx for Windows 35K shares 1 3 Mainfram e file share (NFS) 1 4 1 5 Databases SQL Server Amazon EC2, Amazon RDS, Aurora Aurora removes need for licenses 1 6 Oracle Amazon EC2, Amazon RDS, Aurora Aurora removes need for licenses 1 7 MySQL Amazon EC2, Amazon RDS, Aurora 1 8 z/OS DB2 DB2, Aurora 1. Application
- 14. 14 Transformation Community s with ANSI SQL move to Aurora 2. Application s with a lot of database stored procedures stay on DB2 1 9 SAP Hana SAP Hana 2 0 CICS/IMS Aurora Requires conversion 2 1 2 2 Network DNS Bind, Infoblock s (Public DNS) Route53 2 3 Windows (Private DNS) 2 4 2 5 Security Microsoft Active Directory AWS Directory Service 2 6 AD AWS Identity and Access Management (IAM) 2 7 2 8 Monitoring/Management/Provis ing 2 9 APM Xray 3 0 Infrastructure Monitoring BMC AWS Cloudwatch 3 1 Logging ? Cloudtrail/C W Logs
- 15. 15 Transformation Community 3 2 Alerting ? SNS, CW Events Areas that were covered in the AWS Summit presentation (slides 9 and 10) referenced above and not covered in the table above include: content delivery, cluster management, analytics, ETL, caching, archiving, email, and workflow. Recommended Approach to Migration for MAP methodology We have pooled the experience of our Professional Services and partner teams to develop a structured methodology to prepare you for the migration and then successfully execute. This starts with an assessment to determine baseline capabilities, a structured migration readiness and planning project to build the capabilities and plan to migrate and operate at scale, and then the approach and support to successfully execute those migrations. The Migration Acceleration Program consists of a three step approach for migrating to AWS that includes the following: 1. Migration Readiness Assessment (MRA) Phase The MRA phase determines the current state of your readiness to migrate and identifies areas where you already have strong capabilities and where further development is needed to migrate at scale. The MRA is based on the AWS Cloud Adoption Framework (CAF) and evaluates cloud readiness along eight dimensions (landing zone, operating model, security and compliance, migration process experience, skills and center of excellence, migration plan and business plan). Priorities and gaps identified during the assessment help define the scope for the Migration Readiness & Planning (MRP) phase. The MRA typically involves a 1 day workshop conducted by AWS and/or a MAP Partner. 2. Migration Readiness & Planning (MRP) Phase During the Migration Readiness & Planning (MRP) phase, you will team with AWS Professional Services and/or MAP Partner to build the foundation for a large-scale migration and gain experience migrating and operating several workloads on AWS. AWS and our MAP partners have developed a prescriptive methodology and approach based on best practices gleaned from hundreds of customer migration projects that significantly reduce time to migrate while lowering cost and risk. To prepare a cloud operational foundation, you will follow an agile approach with workstreams for cloud center of excellence, landing zone, operation model, and security and compliance. In addition, we’ll work with you to develop a strong migration plan and compelling business case that articulates the total cost of ownership (TCO) and return on investment (ROI) for a cloud migration. At the end
- 16. 16 Transformation Community of this phase, which is usually completed in 2-4 months, you will be ready to migrate at scale. 3. Migration Phase In the Migration phase, you will execute the migration plan developed during the Migration Readiness & Planning (MRP) phase, typically with the assistance of AWS Professional Services and/or a MAP Partner. A key component is establishing a “migration factory” composed of teams, tools and processes to streamline the movement of workloads from on-premises to AWS. The migration factory teams work through a prioritized backlog of workloads based on migration patterns identified in the portfolio discovery and planning process. Where possible we apply known migration and operational patterns to accelerate the movement of workloads, reduce risk and improve the final outcome. With this approach, you will quickly start to achieve the business benefits of lower operating costs and gaining agility and scalability. Once in the cloud, you can focus on optimization of applications, processes, operations and costs. This phase typically takes 12-24 months to execute. Recommended Approach to Migration for EBA methodology A hands on approach to the migration is recommended. This will include learning by doing, with workloads currently running in the on-premise data centers. This approach will enable the following outcomes for the company: 1. Practical experience with migration tools and the AWS run time environment. 2. A better understanding of the resources and effort required for migrations. 3. An understanding of the operating costs of migrated workloads. 4. Validation of the intended benefits of the migrations. 5. Documented best practices for planning and executing migrations. 6. Documented anti-patterns and lessons learned. 7. A migration 'playbook' which includes the tools, the process, testing, and production rollout <MAP/MRP and EBA, logic flow diagram?> parameters causing one direction or other, pros /cons, some EBAs inside MRP and the overall MAP how to avoid the “stall” help w/ cost bubble EBA drives better business case detail, Experience Based Accelerators Through the execution of thousands of applications migrations, AWS has learned that there is no substitute for hands on experience, repeatable pattern design and team work in the early stages of cloud transformation. Both application teams and business organizations find comfort in knowing they aren’t the first to experience
- 17. 17 Transformation Community large scale changes of people, process and technology. As a result, AWS has developed the Experience Based Acceleration program (EBA). The EBA was designed based on experience gained through thousands of migrations and hundreds of customer transformations. AWS has worked with some of the largest, most progressive corporations in the world to achieve cloud migration at scale, and can bring this experience and knowledge to help jumpstart new customer's cloud capabilities. The EBA is a bank of interactive workshops that accelerates organizational change, portfolio rationalization and application migrations to the cloud. It is intended to be the tip of the spear for transformation in complex, multi-faceted corporate teams. During the EBA, AWS brings experienced talent and methodology to work with and train customer resources to develop the best possible migration scenarios based on individual customer requirements. To combat these early challenges, AWS has created a bundle of Experience Based Accelerators. A B C 1 EBA Duration Intended Audience 2 Platform 5 Days Cloud Infrastructure, Security, Application, Operations, Discovery 3 Migration 5 Days Cloud Infrastructure, Application Owners 4 Application Rationalization 1-2 Days Cloud Infrastructure, Application Owners 5 Organizational Readiness 2 Days Leadership 6 50 in 50 up to 50 Days Cloud Infrastructure, Security, Application, Operations, Discovery What is the Migration Experienced Based Accelerator? The Migration EBA is an interactive migration experience that accelerates application migrations to the AWS cloud. It is intended to be the tip of the spear for application migration in complex, multi-faceted technology teams. During the EBA, AWS brings experienced talent and methodology to work with and train customer resources to develop the best possible migration scenarios based on individual customer requirements. How long does it take? The process takes approx. 2-3 weeks from start to finish, depending on the maturity of your current environment and availability of internal resources. The first two weeks are spent identifying resources, applications, logistics and project execution criteria. The final week is dedicated to migrating applications into the AWS cloud. How Does it Work?
- 18. 18 Transformation Community Once initiated, a small team of AWS or partner resources will work on-site with a customer's teams to educate application teams, identify applications for migrations, and discover dependencies. To prepare for this, the AWS team will work with the customer to identify approximately 20-25 potential application migration candidates so there are ample options to select from. In the final week, a larger team of customer, partner and AWS resources come together to collectively execute migrations for 10-15 applications, leveraging the AWS Agile Migration Methodology. Participation: • Heavy participation from the customer migration team is expected • Application team participation is required • Appropriate representation from other teams who represent a dependency on the migrations (Security, App, Compliance, Ops, etc…) • Executive participation throughout the week • Dedicated scrum manager/project manager to keep status updates (AWS provided) Application selection criteria: • Starting with the set of 20-25 applications that have been pre-identified as early candidates for migration • Low hanging fruit • Pre-discovery will be performed on a smaller set of 10-15 of those applications o Acceptance testing criteria will be defined and documented during discovery o Preference is to select applications from owners who have many other applications that will directly benefit from what is learned during these initial migrations. Logistics: • Work will be performed at a customer location • A dedicated room large enough to house all participants will be required for the duration of the activities • Plenty of power outlets • Lots of table space • White Boards • Lots of snacks and energy drinks • Expectation set with participants of long days and hard work • Participant “day job” responsibilities need to be delegated, delayed, or re- prioritized during EBA to provide 100% focus on the migration initiative • Validated federated access to the console and AWS services before starting for all participants Format: • Morning and afternoon stand ups o Kick off Monday @ 1:00pm, finish Friday @ 11:00am
- 19. 19 Transformation Community Summary AWS recommends beginning the planning process for an EBA or MAP migration workshop. To that end, a project plan template for the MAP/EBA workshop along with outcomes and success criteria can be found <here>. The customer and AWS need to work in parallel (owning different deliverables) to be able to execute on an the migration workshop, usually within 60 days of executive approval. Both teams will contribute to well defined expected outcomes and workshop success criteria. Importantly, due to the resource commitment, it is critical that their is executive level sponsorship for this initiative within the customer. The workshop project plan will include milestones, deliverables, and owners. One of the key actions is for AWS to gain insight into the current state of application discovery and analysis within the customer. This will help provide needed context and understanding for the exercise to identify the set of migration candidate applications, and for narrowing the list down for the migration workshop. Depending upon the level of cloud, AWS, and migration expertise of the participants of the workshop, it may be advantageous to hold a one-day Migration Immersion Day workshop before the migration Workshop. Unlike the MAP/EBA migration workshop, the AWS Migration Immersion Day does not work on existing workloads or does not set up a MVP AWS landing zone. It is a 200-level session, as opposed to the MAP/EBA migration workshop is a 300-400 level session. The Migration Immersion Day allows hands on time with AWS services, and SA guidance for their particular use cases. For developers, architects, and network, security, and database specialists, the Migration Immersion Day (one day event) provides pre-created modules and labs that can be delivered to the customer without rework. A full planning and execution cycle of an AWS Migration Immersion Day takes approximately 2 to 3 weeks. This immersion day is being updated to utilize CloudEndure. Document Authors AWS Team: Tom Laszewski, main author. Jon Keeter, editor, contributor Appendix One - SIs There are a number of AWS consulting partners that can help with migrations to AWS. These partners are listed here - https://aws.amazon.com/migration/partner- solutions/. North American focused migration partners 2nd Watch and Cloud Technology Partners focus on rehost. Many other North American consulting partners, such as Slalom and Cloudreach focus on re-architecture. Although they are not a migration competency partner, GreenPages Technology is a platinum VMware partner and has
- 20. 20 Transformation Community experience migrating workloads to AWS EC2 and VMware Cloud on AWS. India- based Global System Integrator partners Cognizant, Infosys, and TCS have significant and well-experienced lift and shift migration practices. Appendix Two - Oracle Database Licensing on AWS Oracle licensing and support is often confusing. AWS and its partners can provide help with Oracle support and licensing on AWS. There are also partners who can help with Oracle audits and negotiating Oracle ULA and ELA renewals, for example Palisade, Version1, House of Bricks, and Clckwrk. AWS can provide white papers, presentations and data sheets for all four partners. The AWS Database Freedom team is well connected with these companies, and can also provide advice on how to reduce costs of Oracle licensing when moving Oracle Database workloads to AWS. Appendix Three - Estimating the cost of the migration to native AWS Three different perspectives on the method to determine the cost of a migration were gathered from industry averages, AWS, and AWS SI migration partners. All methods used empirical data from previous cloud migration projects. These methods also used a per server/VM cost; based upon number of workloads instead of applications or other attributes of a migration. It is not uncommon to hear a large divergence in per server/VM migration cost, ranging from $200 to $2000. This can be attributed to the fact some consulting companies will quote a lower cost per server which does not include migration tools cost, analysis and discovery, land zone design and instantiation, testing, and production cut over – fully loaded migration cost estimates include all these aspects. Low costs, $200-$600 a server/VM, are typically an indication that some aspect of the overall migration costs is excluded. Most enterprises are only interested in a fully loaded cost per server/VM for the migration project. The industry average is $1500 a server, and that’s averaged out over any platform; physical/VM, x86 or not. This is not a data driven number, but more anecdotal from conversations with partners and customers, and research of industry produced averages. Migrating a physical server, compared to a virtualized server, can add 20-30% more cost per server. AWS professional services uses an internal migration cost estimator tool. AWS looks at all aspects of what it takes to migrate based on level of effort. The cost to migrate is typically directly proportional to the hourly rate of the consultants doing the work. Some partners may say that they charge $200 per server. However, this is only for the moving of bits and bytes. It doesn’t take into account the consulting hours to discover, plan, design end-state architectures, tools selection and testing, migration wave planning, test plan creation, validation, integration, UAT, cut over, migration project coordination, and change management. So these price quotes come with disclaimers.
- 21. 21 Transformation Community Below is a deck from the AWS Summit in 2017. It came to about $1200/server. The last data point is from a Global System Integrator (GSI) that is an AWS migration competency partner. This GSI typically uses a number of around $1.5K per server/VM, with a lower cost for VMware to Vmware migration. Appendix Four - Getting a high level estimate of run time cost Compute, storage, and network costs make up a majority of the cost of running applications on AWS. In most cases, compute comprises the majority of the cost, followed by storage and then networking. There are situations where storage (a content management system) or network (a video streaming application) costs may surpass compute as the most significant cost. Here are some guidelines on application components that help you determine a run time cost: 1. Minimum information a. Compute : Number of servers/VMs including RAM, CPU, OS, and boot drive size (Amazon EC2) b. Storage mapping to transactional, backup, archival, and log/file system/applications (Amazon EBS, Amazon Glacier, and Amazon S3) c. Region where processing is happening d. Data transfer out for networking e. Internet or dedicated networking including security requirements (AWS Direct Connect and VPN) 2. Nice to have a. Backup requirements for each workload that can not be supported by EBS snapshots b. HA requirements for each workload (ALB/ELB, Route53)
- 22. 22 Transformation Community c. Route53, Auto Scaling, Scalability requirements for each workload (ELB, CloudFront) d. DR requirements for each workload e. Storage IOPS, EFS requirements for each workload f. Compute requirements for management/monitoring 3. Really nice a. Workload stratification file servers, security, RDBMS, ERP, big data, security, management/monitoring etc. b. HIPPA and PCI requirements for each workload c. HPC requirements for each workload d. Extremely high CPU, memory requirements e. Top third-party vendors for packaged apps IDS/IPS, WAF, management, monitoring, logging, etc. Appendix Five - Critical Success Factors o Determine migration “R” and design end state architecture as need be (which account/vpc/subnet/routing, firewalls, etc…) o Through discovery, understand the performance characteristics (network/disk/ram/cpu), and usage patterns of the candidate applications. o High speed Direct Connect / MPLS network – For migration of data and hybrid applications where on-prem dependencies exist for a period of time. o The migration staff needs to be specialized in the areas that they will be responsible for. This requires a well-oiled migration factory where each set of teams are experts in design, assessment, execution, and troubleshooting, using automation and infrastructure-as-code principles. Project coordination and project tracking tools are a given as well but having strong program management skills is required to keep all the moving parts closely aligned. o From a macro perspective, the migration team needs to think about the end state environments (architecture/landing zone), and the operational models. These need to be established early on, and aligned with the migration plan. o Need a strong communication plan to ensure alignment with the internal business users, and to share successes and lessons learned as they go through the migration. o Automated test plans must be created for as many use cases as possible upfront. This is to avoid a situation where there may be a 2 week delay waiting for an application owner to sign off before cutting over during production roll out. o Need to use automation tools as part of the workflow from discovery, wave planning, migration, and testing. o Gather business reqs: RTO/RPO (SLAs in general OLAs more specifically if they have any) + regulatory reqs + usage patterns + freeze windows.
- 23. 23 Transformation Community o Data classification and durability (level of criticality/regulatory reqs, backup/archive/DR/if it fits within a BCP) will impact the migration cost and runtime cost on AWS. o Security posture (encryption, authn/authz model) needs to be determined early in the migration process. o Shared services requirements (AD/logging/infrastructure monitoring/application performance management) need to be determined early in the migration process. o Schedule and coordinate change outage window and communication to all stakeholders - including dependencies. o Using a migration tool of choice, the overall production roll out methodology should consist of: 1) running one iteration and verifying the results; 2) running delta syncs as needed; 3) unit testing, right- sizing as needed, change IP if necessary, attach AWS constructs as needed (EBS, SG, routes, etc..); 4) verifying access and functionality (UAT) on AWS instance; 5) shutdown or disconnect server on-prem from network, and cutover, DNS switch or re-IP. Appendix Six - Example Architecture Stack
- 24. 24 Transformation Community Appendix Seven - CCOE patterns Appendix Eight - Migration and modernization ROI, TCO, staff productivity, cost savings, and innovation The table contains the value creation for migrations and modernization for the compute, storage, and network (hosting cost savings), and the cost savings and revenue generation from staff productivity, operational resiliency, and innovation – the three pillars of value creation beyond cost savings. A B C D E F 1 Disposit ion Average cost per VM/server (Low/Med/Hi gh) AWS ARR (saving s when compar ed to on- premis es) Example s of increase in staff producti vity Examples of percentage savings in operational resilience Example s of innovati on 2 Re-locate $150/225/285 18– 23% Internal team’s data analysis reduced from 2 hours to 2 minutes (NHS Digital) Mission- critical uptime improved from 99% to 99.999% (World Fuel Services) Global expansio n launched in minutes instead of 6-12 months (S&P
- 25. 25 Transformation Community Global Ratings) 3 Re-host $900/1,200/1, 450 38– 45% Energy Marketin g business prepared for acquisitio n in only 6 months rather than 12 (Hess Corp) Improved resp onse time by 160%, and performance by 84% (Air Works) Deploy new applicatio ns 75% or 3 weeks faster (WEGO.c om) 4 Re- platform $1,250/1,600/ 1,925 50– 65% 40% of IT team now concentra tes on dev work versus admin work (Radica Systems) 100x performance improvement in batch processing and data analysis (All Nippon Airways) Mobile bookings increased by 75% (Wyndha m Hotels & Resorts) 5 Re- architect $2,100/2,500/ 3,000 70– 90% Software developm ent is now 67% percent faster using AWS and DevOps (Cathay Pacific) 60% reduced downtime (Trainline) Time to market cut from weeks to hours (FlyDubai )