Getting Started with Migrating to the Cloud
The course is part of these learning paths
In this course we will learn practical planning techniques for migrating business applications to public cloud services.
The course is suitable for anyone wanting to learn more about how public cloud services can be effective in business transformation.
- Identify the benefits of migrating to the cloud.
- Describe the six common migration strategies used in cloud migrations.
- Explain the stages of the Cloud Transformation Maturity model, and identify where an organization might be in cloud maturity.
- Implement a framework for assessing an organisation's business and technical migration readiness.Pre-requisites:
I recommend completing the Cloud Computing for Business Professionals learning path as a pre-requisite. While this is a beginner level course, having a basic understanding of the concepts of Cloud Computing will help ensure you gain the most value from the content.
This course includes:
In this course, we will learn hands-on strategies and techniques for migrating business applications to public cloud services. At the completion of this course, you will have a working perspective on the steps and processes required to build migration business case and to implement a migration plan. You will also have an understanding of some of the best practices around migration planning and migration execution.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
- [Presenter] Hello and welcome back. Now let's run through the Cloud Readiness Assessment for expertiseplease.com This process will give us a better understanding of how to plan for a Cloud Readiness Assessment Workshop. How to conduct a high level portfolio assessment. Conduct a detailed portfolio assessment. And how to define a migration roadmap using this first and second pass process. Following the success of the proof of concept run by his team, John the Sys Ops Team Lead at expertiseplease.com wanted to move forward with migrating services to the Cloud as quickly as possible. For a migration project to begin, John recognized the need for the business to run a portfolio rationalization exercise. A portfolio assessment will enable a business to identify which applications were ready to be migrated. Which were not, and what dependencies and considerations might need to be addressed to get a cloud migration project started. The portfolio assessment could determine which applications to migrate, replace or in some cases, to eliminate. To achieve this outcome, John our Sys Ops Team Lead took a bias for action. He proposed to the executive team that he'd run a cloud readiness workshop. Once John had agreement from the executive team, John invited the key stakeholders from the business and technical teams, and he set a date for a three hour workshop. John's invite to the team, outlined the key decision points to consider in determining the strategy for moving to a public cloud provider. He stressed that the first decision point is discovery. With this assessment, we need to evaluate our current applications and data services. He explained that this exercise is based on in conjunction with members from the business teams and technical teams to ensure we have a 360 degree view of any impact change might have on all of these teams. To make things easier, John included a simple application register that he had created which listed the current systems known to him from his perspective as the Sys Ops lead. John stressed that this perspective was his and his alone and there may be many more that we need to consider as a group. John outlined the portfolio assessment process. We would first identify the applications, the dependencies and the licensing models in a first pass. This first pass can be used to do a high level portfolio assessment. And for us to roughly group applications together. On the first pass, we should be looking at cloud compatibility, the current licensing models, and any compliance requirements that we might have. Using that assessment criteria, we can make a strategic decision based on business priorities. And ultimately come up with a draft application migration roadmap. On the day of the cloud readiness workshop, the team ran a high level order of all of the systems currently used by the business. And the first 30 or 45 minutes, John outlined the benefits of cloud services to help explain these benefits in terms that would add perspective for the business stakeholders attending the meeting. As an online business, expertiseplease.com already had a relatively high level of knowledge on the benefits of online services. But not everyone was aware of public cloud services. Depending on where your organization is on the experience curve, you may want to add a knowledge sharing session prior to running any practical discussions. I would recommend using the cloudacademy.com courses such as, what is cloud computing to help a wider team get up to speed with cloud computing basics. So then we are roughly on the same level of understanding about cloud computing. What the opportunity was and the objectives of this workshop. The team ran their first pass on a portfolio assessment. In the first pass of the portfolio assessment, the objective was to identify all of the systems currently used by the business. As importantly, identifying the dependencies and indirections of each of those applications. As each application and system was identified and discussed, John would write it on a post-it note and stick it to one side of the whiteboard under the heading current systems. John then drew out four buckets on the other side of the whiteboard and explained each. Cloud native, these are applications that were built in the cloud using cloud architecture patents. They may use microservices, have API-driven interfaces, and they're built with higher availability and fault tolerance design patents. These services would also generally have metrics and monitoring built in and already may have a pay as you go licensing model. Cloud eligible, essentially those systems that could be moved to the public cloud. They may be already running on a virtualized infrastructure using a service such as VMware and they probably have clearly defined boundaries and dependencies. Ideally they will have or may already have a cloud-based licensing model. Bucket number three is cloud friendly. And these are the applications that can scale horizontally and can leverage standards-based interfaces like risk. And can support document formats such as json or xml. And ideally the vendor of the service will have a cloud image that could be purchased or utilized. And our fourth bucket is not cloud ready. This is anything that is not likely to be cloud friendly in the near future. Due to architectural limitations such as perhaps being hardware specific. The systems might run on non x86 architectures. Which are not currently supported by most of the cloud vendors. Or they may have a licensing restriction i.e. be bound to a specific processor or hardware board. An application may also be deemed not cloud ready if it has an on premise dependency. As an example, the scanners expertiseplease.com used to scan documents and legal agencies, are bound to a propriety black box client server application. The team then discussed and evaluate each application under the headings of compliance, licensing models, dependencies, and compatibility. To agree which of the four buckets each application belongs to? As we discuss each, John the team lead moves each of the application post-it notes to one of these four buckets. For most systems, the process of placing applications in one of the four buckets is straightforward. If we don't know enough about the systems yet, then it is best to pause and recommend running a system audit first. Having an application register that can be distributed prior to an assessment workshop really helps. Next we look for a snapshot view. So our buckets and application are collated into a percentage. Which enables the team to make a short assessment of where we are on our cloud readiness journey. We see that 88% of the expertiseplease.com application portfolio, is eligible for cloud transformation. The next step was to run a second pass and qualify each application against the six migration strategies. Rehost, replatform, repurchase, refactor, retain, or retire. John explained that this was not a technical design discussion. The team needed to stay focused on the business priorities and objectives. John wrote the name of the strategy on a new post-it note and stuck it next to each of the application names on the board as the discussion progressed. Lifting and shifting images from NAS storage in the data center to a cloud object store provided a simple rehosting opportunity. That would provide more elasticity, ease of use and cost efficiency. It made sense to rehost the core business application on cloud compute services. So the business had more elasticity, security and flexibility. The team did recognize however, that expertiseplease.com needed to refactor this core business application. If it was to achieve the business goal of launching new services and reacting faster to customer requirements, we needed to re-engineer this monolithic application to use microservices and manage services if we were going to achieve that. That means components of the application could scale up and down rather than us needing to scale horizontally to meet more capacity. Refactoring the application in this way is seen as a priority for ensuring expertiseplease.com getting the most advantage from cloud services. It is however, seen as the most complex part of the project. Rehosting the IDS and IPS services to cloud compute instances could provide us with more security ease of use and cost efficiency. And refactoring, adding a caching layer to optimize the service that improves our elasticity and flexibility. Replatforming the oracle database to a cloud platform could provide more flexibility and elasticity. Repurchasing, if we shift the database from Oracle to an open-source database like PostGres, that could provide significantly more cost efficiency for the business. It would seem as important to retire the monolithic business appy eventually and the proprietary scanning services. That would ensure the expertiseplease.com had few technical dependencies that could restrict who they worked with and how they worked with them in the future. Based just on business priorities, the ML server and the time management system and billing application were all seen as capable of staying where they were. So they sit under the retain strategy. Alright with that process done, John drew out three swim lanes. The first was called quick wins. The second optimization. And the third, transform. The team then reviewed this backlog of apps and strategies and roughly assembled them into these three swim lanes. For quick wins, the team identified the following. Rehosting the image content. Rehosting the core business app to cloud compute. Rehosting the IDS and IPS services to cloud compute. Replatforming the Oracle database to cloud based Oracle instances. In the optimizing swim lane, the team identified the following. Refactoring by adding a caching layer to optimize a service and reduce load on the front end service. Repurchasing by shifting our database from the licensed Oracle version we have, to an open source platform. That would reduce significant costs to the business. And the transformation swim lane, the team identified refactoring the core business application. Now of course there's many, many steps that are involved in that. So at this point, we're just focused on the business priorities. The actual timing and phasing of these three steps can be figured out at our next phases. The objective is to arrange tasks to rough time boxes based on the business priority and complexity. So with these phase roughly assembled, a transformation road map and plan is beginning to take shape. Each of our applications is classified by our migration strategy and grouped in simple priorities swim lanes. So the outcomes of the Cloud Readiness Workshop could include parts or all of the following. A business value matrix. An application register that might also include a system audit. And our first pass portfolio assessment. With our application a cloud native, cloud eligible, cloud friendly, or not cloud ready. This gives us a rough snapshot of how ready our organization is for a cloud transformation project. The second pass of our portfolio assessment provides us with more detail on those applications identified as eligible for migration to public cloud services. Each application is identified as compatible with one of the six common strategies. And we have an outline of the perceived business benefits identified with each of those. So the outputs of the second stage are, a portfolio assessment, evaluating and ratifying each of our identified applications against the six common migration strategies. Rehost, replatform, refactor, repurchase, retain or retire. This analyis helps us prioritize. It provides us with a better understanding of the business value of each strategy. And allows us to quickly group applications together based on complexity. We can then prioritize sprints within the phases based on our business requirements. So what are the next steps after our Cloud Readiness Workshop? It is now possible for the technical teams to further define, quantify and prioritize a task backlog for each of these migration steps we proposed. That detail will help the business make resource and budgeting decisions. If the project is given a green light, the task matrix can be used to evaluate and select public cloud services that can meet these requirements. Now the expertiseplease.com team recognized the need to implement HR methodology to effectively execute and manage the migration of workloads from end to end. Now this requires expertiseplease.com to plan, schedule and execute migrations in repeatable sprints. Incorporating lessons learned after every sprint. Now each migration sprint should go through an appropriate acceptance test and change controlled process. So in addition to the migration strategy, expertiseplease.com needs to develop and implement an effective cloud governance and operating model that addresses access, security, compliance and automation requirements. Now the team know that these things are perhaps a little beyond their current scope of knowledge so the decision is made to involve providers in this next architecture phase. To ensure the best practices adhered to and that the latest technology is and expertise is involved in the design process. So the objectives of these subsequent meetings will be to develop a migration process for each application workload. This process includes application migration tools, identifying data migration tools, validation methods and appointing roles and responsibilities. Okay that brings this lecture to a close. This lecture has given us a better understanding of how to plan for a Cloud Readiness Assessment Workshop. How to conduct a portfolio assessment and how to define a readiness assessment plan.
About the Author
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.