4 Reasons Why You Should Migrate Your Website to AWS
Learn more about the benefits of moving your website to the AWS cloud.
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.
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.
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:
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.
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:
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:
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.
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.
Empower your team to accelerate their speed by freeing them from the constraints of on-premises data centers and providing the flexibility to pay only for what they use.