Migrating to AWS: Understanding Migration Patterns and Why They Matter

Moving production workloads to the Cloud is complicated, and no single migration to AWS (Amazon Web Services) is the same as the next. At Ubertas Consulting, we know this from our own experience, the hard lessons learned, and our numerous success stories combined.

When planning migrations, we often talk about “Migration Patterns,” why they matter and how they shape our delivery strategy.

A widely adopted way of conceptualising migrations is the “7 Rs”. A quick search of the web will highlight these “Rs” as a starting guide on how best to move to the AWS Cloud.

The seven (7) Rs are:

1. Refactor– Break down the workload into application services that can be operated by modern Cloud-native services
2. Re-platform– Move a workload to the Cloud with minor optimisation, to leverage common Cloud-managed services
3. Repurchase– Often applicable to SaaS (Software as a Service) offerings, where there is an option to operate the technology in the Cloud rather than continuing on-premises
4. Rehost– Migrate the workload without modification to the technology stack. Commonly referred to as “Lift and Shift”
5. Relocate– Typically applicable to the migration of heavily virtualised environments that can be moved onto an equivalent virtualised AWS infrastructure
6. Retain– Do nothing; operate the workload in its current environment and de-scope from the migration
7. Retire– Phase out the workload in its current environment and de-scope from the migration entirely

Use the above as an effective tool in differentiating workload components, and their individual migration objectives and target states. In our experience, most migrations fall into the “R” of Re-Platform, with organisations looking to migrate to AWS before modernising with Cloud-native services.

At Ubertas Consulting, the way we see migration patterns is slightly different and is more specific to the workloads in scope. By diving down beyond the “R” we find commonality amongst the specific technology patterns for the workloads in question.

Here are some arbitrary examples (this list is not extensive):

1. On-prem physical MySQL database clusters will be re-platformed to Amazon Aurora MySQL, using the Database Migration Service (DMS)
2. MongoDB instances will be re-platformed to Amazon DocumentDB
3. Self-hosted Kubernetes environments will be re-platformed to an AWS EKS (Elastic Kubernetes Service) Cluster running both EC2 and Fargate workloads
4. On-premises data (often tape) archives will be re-platformed to AWS S3
5. On-premises Windows hosts will be re-hosted on Amazon EC2
6. On-Cloud Windows VM’s (virtual machines) will be re-hosted on Amazon EC2, importing VM (virtual machines) images into EC2 AMI (AWS Machine Images)

It is more much effective to engage with your developers and solution architects when planning at this level.  Finding common migration patterns, across the migration project, simplifies and de-risks the proceeding stages of the migration process.

The following diagram depicts one of several migration patterns used by Ubertas Consulting, to assist one of our recent clients:

In this case, an on-premises data store (NFS) was being re-platformed onto AWS S3. There were large data volumes to migrate over a prolonged period, due to several rounds of A/B testing, plus the fact that the on-premises data store received high numbers of writes. This was further compounded by the migration of other workloads occurring in series, leading to a far longer-than-average migration window. The data being transferred was also extremely sensitive, and although encrypted, it was preferable for it not to transit the public internet. Direct Connect was used to solve these two problems, ensuring a low-latency, private path to AWS. Once inside, the data was stored in private S3 buckets, encrypted with customer managed KMS (Key Management Service) keys (not shown in the diagram). S3 lifecycle rules were configured to automatically move S3 objects into deeper levels of archive storage; this minimises S3 costs whilst keeping data on retention (i.e., for legal reasons).

Proving The Pattern

Having selected your preferred migration patterns, your organisation will now be equipped to progress in a more controlled manner.

Your next steps should be:

1. Launch Multiple Proof-of-Concept Exercises– Test the feasibility of each pattern, by deploying it as a rapid proof-of-concept in your provisioned Landing Zone. Even at this early stage, deployments should be codified using infrastructure-as-code to allow for rapid, iterative experimentation until the pattern is successfully validated. You should have a working, demonstrable proof-of-concept by the end of this step.
2. Pilot before Committing– Undertake short migration pilots for each pattern, to migrate a pre-selected workload to AWS. The objective is to pilot both the technology and the approach, documenting timings to inform the wider migration plan.
3. Building the Migration Plan– Armed with the knowledge of each migration pattern, and having proven its deployment and operation within AWS, only now are you able to carefully plan your migration for real. This plan will effectively combine the output of the pilots with the needs of the business.

The key to success is being ready to start your migration to AWS, with each pattern well understood, proven, and planned for. At Ubertas Consulting, we have found this to be the single most crucial element of any successful migration. If this approach is adopted, then executing the plan and mobilising your migration team will be fully de-risked and become the most predictable part of your migration journey.

If you would like to learn more about successfully preparing and executing a migration to AWS, we recommend reading the Migration Acceleration methodology documents, published by AWS.

AWS Migration Acceleration Program (MAP) – Amazon Web Services

You should also consider engaging with an authorised AWS Partner, like Ubertas Consulting, for tailored, professional migration advice and hands-on assistance.

Steven Crowley
Co-Founder, Ubertas Consulting

LinkedIn