5 Best Practices for Becoming an AWS Migrations Competency Partner

We here at Mission recently announced that we have achieved AWS Migration Competency. This is a big win, as this designation provides third-party validation of what we and our customers have always known: that Mission provides the deep expertise required to help SMB, Startup and Enterprise businesses successfully move to AWS. With our experience and knowledge, Mission can navigate all phases of complex migration projects - discovery, planning, execution, and optimization.

Attaining the AWS Migration Competency is no easy task, and there is no formula or blueprint online on how to do this (trust me, I looked). Yes, AWS provides their checklist of requirements, and that’s helpful because those are the activities that need to be done, but when I searched online I couldn’t find even one helpful blog post or article from an AWS partner that provided best practices on how to attain the AWS Migration Competency specifically. 

I’m writing this blog post for three reasons. First, I want to provide guidance to other AWS partners who are looking to attain this competency by recommending 5 best practices. As someone who was involved in attaining the competency, sometimes I felt lost, and there was not a lot of helpful content out there. Secondly, I want to communicate to all readers how important attaining the Migration Competency was to Mission, and lastly, I want to demonstrate the extensive due diligence Mission undertakes when migrating a customer to AWS.  

The Importance of the AWS Migration Competency

Many businesses are overdue for cloud transformation. However, these businesses have a knowledge gap because they don’t understand life on the cloud is different from life on-premises. Because of this, many tech teams and leadership teams don’t know where to begin. They don’t know what questions to ask, nor do they know how to financially plan for a migration. This knowledge gap results in either paralysis, so companies don’t migrate, or missteps, because the business tried to migrate alone, and they were not aware of the things that could go wrong.  

It is for these reasons that businesses require the expertise of AWS consulting partners, like Mission. Whether you’re a Premier or Advanced partner, all consulting partners have a responsibility to be diligent and thorough when migrating a business to the cloud, especially migrating production workloads. Any mistakes during a migration can be detrimental to a business. We here at Mission understand this, and take this very seriously. Because of this, we felt it was critical to attain the Migration Competency, not only to show prospects we are migration experts, but also to drive continuous improvement in our migration practice.   

Best Practice #1: Case Studies Must Account for Migration Strategy, Complexity and Workloads Migrated

When vying for an AWS competency, all partners must demonstrate their capabilities through case studies, but the Migration Competency is a bit unique because the case studies used must consider migration complexity and the number of workloads migrated. 

Migration Complexity is determined by the migration strategy a partner uses to migrate the application, and the effort taken to migrate that application. There are six migration strategies, but only four of them are related to the migration process. Below are the 4 migration strategies, along with their migration complexity and complexity per app:  

When determining which customers to use as case studies, we recommend giving serious thought about the migration strategy that was used. Using a case study where the migration strategy was simply a Rehost may not be very beneficial because the complexity is low, especially compared to a Refactor migration strategy. However, if you’re going to use a case study where the migration strategy is a Refactor, then be prepared to provide documentation that proves the strategy was really a Refactor.

In conjunction with Migration Complexity, partners must account for Workloads Migrated, which simply refers to the applications and source servers that were migrated. The key thing to understand here is that the AWS Migrations Competency determines the number of workloads migrated by the complexity-weighted per application and source servers. This is done through two simple formulas:

• Complexity-weighted number of apps = (number of migrations apps) x (migration complexity per application)
• Complexity-weighted number of source servers = (number of migrations source servers) x (migration complexity per application)

If you have a customer that you’ve done a Rehost-based migration for 5 applications where the complexity per app is deemed a 2, then the Complexity-weighted number of apps that were migrated is 10 (5 x 2). However, a customer where you’ve completed a Replatform-based migration for 5 applications, where the complexity per app is a 4, will result in a much higher Complexity-weighted number of apps of 20 (5 x 4). You can see how it’s more advantageous to use a case study with a more complex migration strategy because the complexity score is higher. This same thinking should be applied to the number of source servers migrated. 

This is important because the requirement for the Migrations Competency is that all the case studies used must account for > 50 complexity-weighted applications and > 500 complexity-weighted source servers. If you decide to use case studies that are all low migration complexities, then the actual number of applications and source servers migrated will need to be a very high number. Also remember, the maximum number of case studies that can be used for the Migration Competency is 10 and the minimum is 5, so this definitely takes some strategic thinking. 

Best Practice #2: Case Studies Should Tell a Story

Case studies used in competencies typically have more technical details than traditional marketing case studies that are used on a company’s website. Interestingly, with this Migration Competency, we were informed that the publicly referenceable case studies (because at least 2 of them must be public) should tell a migration story. The story must describe the customer and pattern and must reference AWS. Additionally, the publicly referenceable case study should explain the challenges the customer was facing and the ways migrating to the cloud would solve them. Lastly, the case studies should explain the outcome and benefits from migrating to AWS and describe the AWS services and third party services used. Below is a summary of three case studies that Mission has published that tell a migration story: 

• Evolve Media, a global content publisher and marketing solution provider with more than 40 media brands drawing an audience of 120+ million readers, required an experienced AWS Consulting Partner to plan, support, and execute its migration from a collocated data center to AWS – and do so within a three-month timeframe. Mission and Evolve completed the cutover of 50 applications before the deadline, sparing the customer from additional data center costs and establishing a more technologically-efficient and cost-effective infrastructure on AWS going forward. Evolve Media has already reported saving 20% on infrastructure costs because of the transition to AWS, and expects to save 30-40% through further cost optimization.  
• Ultivue and their proprietary InSituPlex technology enables unsurpassed biomarker detection and tissue analysis. As Ultivue experienced rapid growth, the on-premises IT infrastructure began to exceed its capacity. End users occasionally experienced slow application response times, and storage needed to scale more quickly. Ultivue turned to Mission, which moved Ultivue’s on-premises IT infrastructure to AWS with multi-availability zones and automatic failover to a backup environment. Other key aspects include a common authentication source for on-premises and cloud end users; load balancing so clients can access research; and additional nodes that spin up automatically when workload activity spikes. By moving to AWS, Ultivue’s application performs consistently, even as the number of users has tripled. Lastly the move to AWS, eliminated large upfront CapEx for building on-premises data centers.
• mPulse Mobile, the leader in conversational AI solutions for the healthcare industry, needed support migrating the workloads of a company it had acquired from RackSpace to AWS. mPulse did not have the internal bandwidth to execute a migration of this magnitude – the 400+ gigabyte production database, being written to every single second, was both high volume and high velocity. The migration also needed to be completed with full HIPAA compliance. Mission was brought in to migrate the healthcare technology company’s Rackspace-hosted Oracle database to AWS. Mission worked closely with mPulse for weeks, ultimately completing the migration with less than one hour of database downtime – well within mPulse’s requirements. mPulse calculates that the successful migration from Rackspace to AWS saves the company $10,000 every month – while also simplifying its infrastructure and HIPAA compliance.

Best Practice #3: Demonstrate a Consistent Migration Methodology

A consistent migration methodology is something that is critical to AWS. AWS understands that all partners will have their own unique migration methodology, and that’s perfectly fine. What AWS is looking for is consistency of that methodology, meaning that all of the customers that a partner migrates to AWS should follow that same process. Even though AWS partners will have their own unique migration methodology, there are specific items that the migration process should have:  

• TCO Analysis: Businesses migrating to AWS need to know what it’s going to cost to operate in the cloud. This is done through a TCO analysis and report which is generated using a tool such as CloudChomp (this is the tool that Mission uses for TCO Analyses).  
• Migration Readiness Assessment (MRA): The MRA is a discussion to get alignment of the key stakeholders within the organization. In addition to discussing the results of the TCO report, the purpose of the MRA is to assess a business’s current state, identify any readiness gaps and to make recommendations to fill those gaps so the business is prepared to migrate. 
• Discovery and Planning: AWS partners and the business they are migrating need to understand what they are looking to migrate, so doing a deep dive to understand the application landscape and the application dependencies is needed. 
• Landing Zone: Businesses need to understand where they are migrating to, so presenting a landing zone is recommended. However, there are activities such as setting up the basic accounts and planning the network, the security controls, the user management, etc. Also, explaining where on AWS the business’ applications are going to land is highly recommended.
• Migration Plan: Both the AWS consulting partner and the business they are migrating need to understand the migration plan, but coordinating the roles and responsibilities for the migration is equally important. The migration plan should discuss the migration pattern for each application, along with the application architecture, migration tooling, the cutover plan, etc. Moreso, the migration plan should explain who is responsible for the specific activities in the migration plan. For example, specifying which group is responsible for things like code updates, cutovers, modernizations etc, will eliminate ambiguity regarding who is delivering what part of the migration plan. Lastly, the migration plan should state when each activity in the plan occurs and what dependencies, if any, that activity may be reliant on.  
• Optimization Plan (post-migration): Migration to AWS is just the start of the cloud journey for a business. AWS wants partners to demonstrate they’ve created an optimization plan for one or more of the following: cost optimization, application optimization, process optimization or operational optimization. For all businesses migrating to the cloud, cost optimization is critically important right at the outset, so Mission recommends to plan for instance right-sizing, recommend reserved instances or savings plans, or leverage spot instances.

Best Practice #4: Document, Document, Document

I don’t need to elaborate very much with this tip. When a partner is executing on migration, they should be documenting all of their activities and that documentation should explain why the partner executed the work the way they did. Also, partners should date all of their documentation. Some examples of documentation would be: Discovery Reports, TCO Analysis, documents that demonstrate how the pillars of the Well Architected Framework were used during the migration, Responsibility Matrix (RACI), SOWs, Landing Zone Designs, Design Plans, Project Plans, Cutover Plans, Architectural Diagrams and End of Project Customer Satisfaction Surveys.

Best Practice #5: Reach Out to AWS for Help

AWS has tons of useful migration documentation, but partners should really be reaching out to their Partner Development Manager (PDM) and their Partner Solutions Architect (PSA). Mission is in constant communication with our PDM and PSA, and we repeatedly sought their guidance during the Migration Competency project. We met on a weekly basis, and we were introduced to other AWS representatives that provided us guidance during this project. This guidance was helpful because we learned how we could better leverage our case studies and migration documentation to ensure a smooth audit -- and because we learned some ways to continue to improve our migration processes and practice. We also learned what other partners who attained the Migrations Competency did well, and where others fell short. I couldn’t encourage partners enough to work extra closely with their AWS counterparts when trying to attain this competency.