Intro to AWS MAP

MAP is a comprehensive and proven cloud migration program. It is coming from AWS based on their professional experience for several years working with several customers. There are three main phases of this program: Assess, Mobilize, Migrate and Modernize. This program has got three main phases: assessment, mobilization, and migration. There are several acceleration tools involved. I will briefly touch on those. The Well-Architected Framework is highly recommended at each stage. The Well-Architected Framework, which most of us are familiar with, has five pillars, and now six pillars, comprising security, cost optimization, reliability, operations, and sustainability, and keeping that framework in mind when we are doing the migration at each stage is highly recommended by AWS.

When we get an opportunity from our sales team, from our account executive, the first thing is just a level check to understand that this is a migration project. We get projects to migrate from on-prem, a lot of migrations are coming from on-prem, some come from Azure or Google, and some come from platforms such as Cloudera. It can be a wide range. And the first thing, as part of that process and assessment is that we create an SMC. Now, this SMC is basically a simple calculator from AWS. The reason for creating the SMC is to get an idea of the total cost of operation for the customer after the migration. And the SMC is pretty simple. You start with this calculator, choose an appropriate service, configure it and go into its details. You will get some idea of how much it will cost. For example, the step functions elastic IP and most commonly is the EC2 service. You can configure it, the configuration is very simple. But like I said, I won’t go into the details of the tools to save some time, but the idea is that you go through, configure it and you get a total cost. And that total cost gets submitted to AWS and they qualify the deal as a migration program that they will be able to fund. That’s one of the first things that we do. Then the other things that are part of the assessment phase are validating the readiness for migration, forecasting the cost, and building a business case to migrate. I will talk about this.

The tools that we use with different goals in the assessment are to validate the readiness of the migration. We use Cloud Adoption Readiness Tool or the Migration Readiness Assessment. The Cloud Adoption Readiness Tool is basically a set of 16 questions, which have different areas – business, people, governance, platform, security, and operations. We walk through these questions, and we get a good report that covers different areas. Let me see if I can show that. This is a set of questions that are going by the different pillars, business, people, process, platform, etc. You work with the customer to understand their environment, understand their process, from both a business and technical point of view. You get a report kind of like this. That includes several important things. For example, a score from each pillar perspective, as well as a Heat MAP and Cloud Readiness MAP gives you an overall idea of where the client is.

You can also use the Migration Readiness Assessment. Now, this assessment is more comprehensive than CART. This is usually involving a workshop with the customer. It involves the same things but in a deeper level. When a customer is at a higher scale, they have higher capabilities on-prem and they are also looking to migrate at scale. That is when this is generally recommended. It is just the same thing, but in an advanced version, mostly done in a workshop with the customer.

To forecast the cost and create a business case, there are two important tools: AWS Migration Evaluator, formally TSO Logic. It basically is used to analyze the on-prem resources and project, what will be the cost and how much the customer will be able to save. There are different methods of discovery with this tool. Essentially, we are trying to get to a business case that in terms of cost optimization, it’s making sense for the customer to move to the cloud. The second option in this is the Migration Portfolio Assessment. That also helps us evaluate the total cost of ownership and right sizing recommendations and to estimate the migration project costs. It’s for the Cloud Readiness Assessment. It’s pretty much the same as this pillar – these business, people, governance, platform, security, and operations pillar, but at the at the next level. It is going to talk about IT governance, cloud objectives, supplier management, IT strategy and so on. It is done at the workshop level. As far as the acceleration, you can kick off the portfolio assessment from here. It will go through and give you a walkthrough/process and you will start accumulating the data and answer a bunch of questions. Like I said, I won’t go into the details of this, but one thing I am doing with this presentation is at the end of it, I am putting together links of all these tools, so you can explore them on their own. But the main thing to understand with this is that we have these options to do the assessment. So for cost optimization and business case development, we are looking at the AWS Migration Evaluator and the Migration Portfolio Assessment.

If you try to understand when to use which tool, you can see there are several details. The main thing is that the MPA tool (Migration Portfolio Assessment) is something the customer can do by himself. Whereas, the Migration Evaluator, when we are working with partners, we are coming in there and using that tool. So, if a customer wants to go without any engagement and wants to just play with it, himself, we tell them okay, you can look at the MPA program. But most of the time when we are going through the process, we use the Migration Evaluator Logic.

When the assessment phase is complete, we are moving toward the mobilization phase. In the mobilization phase, we are going to do some discovery and planning of the customer workloads. Another important thing to look at in the mobilization phase is how the account structure of the customer environment is set up. AWS landing zone is highly recommended to be used in this phase to have a clearer picture of your organizational account. Most of the time, in the mobilization phase, we are doing some POC, we are doing some subset of the customer workload and migrating it over and we are coming up with the high-level migration plan.

The Application Discovery can be done in different ways during the mobilization phase. The main thing is that there is a discovery with an agent or without an agent. If you are using physical servers, then you have to go with the agent-based approach. If you are mostly dealing with the virtualized, VM-based environment, then a connector approach is sufficient. You are able to get different types of data configuration, data usage metrics, time series, performance information, and more details about the applications and the servers that they are running on which is essentially very useful when you are mapping it to the equivalent cloud services.

At the same time, when we are doing the Application Discovery, we are going to think about how these applications will be migrated and what our strategy will be to migrate each workload. This could range from rehosting to relocating. These are pretty standard. What you can think about, is rehosting, re-platforming, repurchasing, refactoring, or maybe retiring. Most of the time, when we are doing the migration, the first phase is that we do the lift and shift. Doing the lift and shift makes it much simpler to complete the migration and have a clear goal. Whereas, if the customer has important needs, the other approach is to modernize at the same time and that adds a little bit of complexity. But that’s also as per the customer requirement that you can do the re-platforming, you can do the refactoring. If you are talking about a monolith migration, then going into the cloud, it will transform into microservices. One important thing to remember is that as nClouds, we have the infrastructure and DevOps competency. We focus more on the infrastructure and DevOps side. And if the client has heavy needs on the application side, and needs application refactoring, either they do it themselves, or we bring in another partner and we work closely with them.

So during the migration phase, we basically finalized the landing zone details that we started in the mobilization phase. We choose the right strategy for each workload. And then there are again, different tools available for our leverage during the migration phase. We can do the AWS Server Migration, Database Migration, and Schema Conversion, and even more tools are available than the ones that I listed here.

But the important thing that I wanted to get the message or the gist of this presentation about is in this slide. Essentially, we are looking at a three-phase process and going into this, we need a deal qualification and an SMC ready, which is basically a very high-level estimate because we have not done the assessment. Before doing the assessment, we are making assumptions about how the client workload is going to look like in the cloud and in AWS, and how much it is going to cost. Then we enter into the assessment phase. In the assessment phase, as I mentioned, there are different tools available. We use the Migration Readiness Assessment. If the client is migrating at scale, and it’s complex, we can talk about doing the one-day workshop with the client going through tagging and discovery. The outcome of this is generally in SOW which is approved by AWS for funding. As we come out of the assessment phase, we get into the mobilization phase, where we are doing more of the portfolio assessment. And in this portfolio assessment, as I mentioned earlier, we can do a POC to understand what kind of workload it is, and if there are any important and significantly difficult portions of the migration, we can try them out. But with the mobilization phase, we are going to come out with a high-level migration plan. If there are any doubts, we want to clear those up. This can take up to three months, but generally, when we talk to customers, they are always looking to do it quickly to make sure their business needs are met and they are able to take advantage of the cloud as quickly as possible. Even though this is recommended by AWS, it takes three months, but usually, we condense it, and it can go from one to two months easily. And in this phase, in the assessment and the mobilization, we have the account executives involved, and we have the assets involved. In addition to the account executives and the SAs, we sometimes bring a project manager. The project manager helps keep track of the different deliverables because these phases can become quite detailed with each of these tools being used, outcomes from that tool, organizing that, and having a plan to make sure that we are hitting the timelines. That’s where the PMs help a lot. If any detailed POCs need to be done or any detailed technical work needs to be done, we also bring some cloud engineering from the delivery side, but that’s on a case-to-case basis. This is how we come out of the assessment and the mobilization phase and then we move to the migration phase. Now with the migration, it is generally completely done by the delivery with the help of the project management and the account executive stays in touch overall. Essentially, the migration is executed in terms of the waves, in terms of different workloads. As it progresses, it is continuously reviewed with the customer and also updated with AWS.

I put together these links. The goal for today’s presentation was to make sure that I communicate the overall process as well as the different tools and information available so we can go and dig that out as we go through this process.

Links & Credits:

SMC
AWS MAP Program
Cloud Adoption Readiness
Migration Readiness Assessment
Migration Evaluator Tool
Migration Readiness
Credits:

AWS MAP Resources and Training