Don’t Get Lost in the Clouds – How and Why to Use AWS MAP
Sure, most of us know that cloud is the future. We don’t need to be convinced to move more and more of our workloads to those shiny hyperscaler cloud platforms. But, you may be shocked to learn that this opinion is still not universal. Indeed, many businesses around the world are cloud-sceptic, cloud-cautious or cloud-afraid.
Yes, FUD is strong among those that still associate a server with something heavy buzzing loudly in the company basement. That’s why the clever people at AWS are constantly thinking of how to extend their business to those still living with a server rack, or how to show the proper use of cloud to those who are already there, but are not fully tapping AWS’s potential.
Judging from the fact that AWS grew from a mere backend to an online bookstore to the behemoth that we know today, they probably have a pretty good idea how to do that. And one of the models they now champion as part of this journey is the AWS Migration Acceleration Program.
So, what’s MAP all about?
The Migration Acceleration Programme (MAP) is a proven cloud migration programme from AWS, which can help accelerate cloud migration and/or modernisation. And there is a lot of demand for such a support programme, for several reasons.
Expertise. Firstly, there are many businesses who would benefit from Cloud migration or Cloud modernisation, but do not have the necessary know-how on how to do the first steps.
Costs. Then — migration costs money. Cloud adoption is providing cost benefits in the long run (otherwise we would all be still administering Cisco routers in some cold room), but the beginnings can feel like a bottomless money pit. All those assessments, redesigns, plans and deliberations cost time and money and may be prohibitive to a budget-conscious CIO.
Excellence. And lastly — Cloud adoption is providing benefits only if it’s done right. Bad cloud migrations often not only miss the promised savings, but also create a lot of bad PR.
How does MAP actually help?
MAP addresses these issues in two ways.
Proven competency. First — by ensuring that migration projects are prepared by competent people. MAP projects can be delivered only in cooperation with AWS Professional Services or with AWS Partner (such as us).
Funding. Second — AWS sweeten the necessity of hiring a pro by actually footing the part of the bill.
Great, so how do you get started with MAP?
Sounds fun? Of course it does. So what does a company need to do, to benefit from the program? Apart from operating workloads that could be either shifted into the cloud or greatly modernised?
Well, first of all, the workloads must be large enough for AWS to benefit from the investment. At the very beginning, MAP was available to customers with projected Annual Recurring Revenue (ARR) greater than $500k. Some time later, so called “MAP-Lite” was introduced, targeting customers with ARR smaller than that — however, benefits for those whose ARR is below $250k are limited.
In the next sections we’ll explore a big picture of what AWS is offering us for each phase, and those readers who are interested in exact numbers can easily find them in AWS Partner Network materials. (If you don’t have access to those materials feel free to reach out to us).
Divide and conquer
MAP manages the migration process by dividing this big, scary monster of effort into more manageable steps. The project is divided into three phases, creatively named Assess, Mobilise, and finally Migrate and Modernise.
Those phases address the whole process, starting with inducing customer’s curiosity and ending with leaving the customer in charge of operating their new, shiny cloud solution.
The AWS MAP Program Steps
The Assess phase focuses on creating a business case for migration. That requires the AWS partner to understand the business of the customer, scope the needs, and then identify the workloads that should be migrated and/or modernised.
It’s also the time to understand the requirements — such as SLAs, performance requirements, uptime, security and compliance constraints. Based on that, the partner creates a high-level strategy. In this document, all current workloads are categorised by 7Rs — Retire, Retain, Rehost, Relocate, Refactor, Replatform, Repurchase. This categorisation will provide an overview of the future cloud-hosted landscape, that will determine the modernisation scope and will drive the migration/modernisation approach.
The strategy is built carefully, and creating it requires obtaining a basic understanding of each workload that builds the current solution. Any shortcut taken at this phase will create unexpected problems at the later phases.
When the strategy is completed, two other important documents are created – draft the solution architecture and the costs projection. The solution architecture may already contain a detailed design of the future Landing Zone – but it can be a high-level draft as well.
With these documents ready, the next step is to approach the customer and spark their curiosity in modern cloud solutions by presenting the complete idea. This should result in obtaining the single most important deliverable of the phase — the green light to go ahead and mobilise.
It’s worth noting that AWS often foot the bill for this phase (up to certain amounts – please consult the AWS Partner Network for details).
The Mobilise phase is the followup — where we really get going. In this phase we start building the team — your AWS Partner should bring all the necessary knowledge, but it’s also good to supplement that with some insider customer know-how. This is especially important considering that it’s often not the AWS Partner who is to operate the whole system in the future.
With the team in place, we can start identifying workloads for pilot migrations or MVPs. This is an important part — Pilot migration is aimed to verify the draft approach outlined in the previous phase.
It’s required to have a pilot for representatives of each of the 7Rs that are present in assessment report. Of course it’s much easier if we only, for example, Rehost, but this stage can get pretty big if we have six or seven different approaches in the plan.
It’s therefore vital for the success of this phase that the planned roadmap takes the size of the pilot into account, and that we have all the skills in the migration team that we’ll need.
As for other deliverables of the phase, AWS would like to see disaster recovery and backup practices here, the approach to testing, some RACI matrices regarding responsibilities for each application, and of course a detailed solution architecture.
The architecture should contain a design of the landing zone(s), a security plan, and details regarding reliability, performance and cost optimisation of the future system. All that should be concluded with a Well Architected Report (conducted by a certified engineer).
The good thing is, the pilot migrations/MVPs can happen in a non-production environment — there’s nothing stopping production-level pilots from being proposed.
And it’s important to underline the general mantra of the Mobilise phase – the goal is to ensure that customer is ready for the migration and modernisation, that the resources are earmarked and management buy-in is confirmed, and that everybody involved can actually perform all required activities.
AWS will not fully finance this phase. Significant customer contribution is required — but one can expect roughly half of the costs to be covered (limits apply).
3. Migrate & Modernise
The final phase, Migrate & Modernise, has a nice, self-explanatory title — and in theory this is the phase when – if the previous phases have been completed well – everything should go just right. The actual migration approach was tested extensively in the Mobilise phase, the target Operational Model has been drafted — so now it’s just time to apply everything. Easy, right?
Well, the trick is to migrate and/or modernise the workload at scale, without disturbing business operations, while at the same time not to pressuring the operations teams too much. AWS recommends dividing the migration into defined milestones or waves, and launching them at a sustainable pace.
Apart from that, it’s time to work with the customer on the implementation of operating model deliverables identified in the previous phase. Citing AWS, these deliverables are, but not limited to; business continuity strategy, patch and release management, ops health monitoring, incident/problem management, and cost/billing management.
And last but not least, each workload requires creation of dedicated optimisation plans — remember the continuous improvement mantra.
So the last phase doesn’t just require you to press the big red launch button and go celebrate, but to make sure teams know how to optimise and operate their solution.
In the future, some costs are also returned by AWS — but the biggest reward is to actually take a step back after the last migration wave, and admire the new creation while reaping the benefits. The journey from datacenter to cloud — or from amateur-hour cloud to proper implementation — is rarely unimpressive.
MAP = Acceleration
To sum up, MAP is a great program to accelerate cloud migration and modernisation and is one of those rare opportunities where everybody is left smiling — AWS with a new happy customer, the customer with their nifty, shiny, new solution, and the AWS partner, satisfied with yet another cloud success story.
Get in Touch.
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.