{"id":593842,"date":"2025-04-28T10:00:00","date_gmt":"2025-04-28T08:00:00","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/migrating-to-aws-understanding-cloud-migration-patterns-and-why-they-matter\/"},"modified":"2025-04-28T10:00:00","modified_gmt":"2025-04-28T08:00:00","slug":"migrating-to-aws-understanding-cloud-migration-patterns-and-why-they-matter","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/cz\/expert-view\/migrating-to-aws-understanding-cloud-migration-patterns-and-why-they-matter\/","title":{"rendered":"Migrating to AWS: Understanding Cloud Migration Patterns and Why They Matter"},"content":{"rendered":"\n

Moving production workloads to the Cloud is complicated, and no single migration to\u00a0AWS (Amazon Web Services)<\/a>\u00a0is 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.<\/strong><\/p>\n\n\n\n

Download Now: Maximise Your Cloud Benefits with AWS
[Guide]<\/strong><\/a><\/p>\n\n\n\n

When planning migrations, we often talk about \u201cMigration Patterns,\u201d why they matter and how they shape our delivery strategy.<\/p>\n\n\n\n

A widely adopted way of conceptualising migrations is the \u201c7 Rs\u201d. A quick search of the web will highlight these \u201cRs\u201d as a starting guide on how best to move to the AWS Cloud.<\/p>\n\n\n\n

\n

The seven (7) Rs of migrations are:<\/h2>\n\n\n\n
    \n
  1. Refactor<\/strong>\u2013 Break down the workload into application services that can be operated by modern Cloud-native services<\/li>\n\n\n\n
  2. Re-platform<\/strong>\u2013 Move a workload to the Cloud with minor optimisation, to leverage common Cloud-managed services<\/li>\n\n\n\n
  3. Repurchase<\/strong>\u2013 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<\/li>\n\n\n\n
  4. Rehost<\/strong>\u2013 Migrate the workload without modification to the technology stack. Commonly referred to as \u201cLift and Shift\u201d<\/li>\n\n\n\n
  5. Relocate<\/strong>\u2013 Typically applicable to the migration of heavily virtualised environments that can be moved onto an equivalent virtualised AWS infrastructure<\/li>\n\n\n\n
  6. Retain<\/strong>\u2013 Do nothing; operate the workload in its current environment and de-scope from the migration<\/li>\n\n\n\n
  7. Retire<\/strong>\u2013 Phase out the workload in its current environment and de-scope from the migration entirely<\/li>\n<\/ol>\n<\/div>\n\n\n\n

    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 \u201cR\u201d of Re-Platform, with organisations looking to migrate to AWS before modernising with Cloud-native services.<\/p>\n\n\n\n

    At Devoteam, the way we see migration patterns is slightly different and is more specific to the workloads in scope. By diving down beyond the \u201cR\u201d we find commonality amongst the specific technology patterns for the workloads in question.<\/p>\n\n\n\n

    Here are some arbitrary examples (this list is not extensive):<\/p>\n\n\n\n

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

      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.<\/p>\n\n\n\n

      The following diagram depicts one of several migration patterns used by Devoteam, to assist one of our recent clients:<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      In this case, an on-premises data store (NFS) was being re-platformed onto AWS S3<\/strong><\/a>. 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<\/strong><\/a> 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)<\/strong><\/a> 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).<\/p>\n\n\n\n

      Proving The Pattern<\/h2>\n\n\n\n

      Having selected your preferred migration patterns, your organisation will now be equipped to progress in a more controlled manner.<\/p>\n\n\n\n

      Your next steps should be:<\/strong><\/p>\n\n\n\n

        \n
      1. Launch Multiple Proof-of-Concept Exercises<\/strong>\u2013 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.<\/li>\n\n\n\n
      2. Pilot before Committing<\/strong>\u2013 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.<\/li>\n\n\n\n
      3. Building the Migration Plan<\/strong>\u2013 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.<\/li>\n<\/ol>\n\n\n\n

        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.<\/p>\n\n\n\n

        You should also consider engaging with an authorised AWS Partner, like Devoteam, for tailored, professional migration advice and hands-on assistance. Get in touch.<\/a> <\/p>\n\n\n\n

        \n
        \n

        Maximise Your Cloud Benefits with AWS<\/strong><\/h2>\n\n\n\n
        \"\"<\/figure>\n<\/div>\n\n\n\n
        \n
        \n
        \n

        Ready to migrate to AWS but unsure where to start? Learn how to avoid common migration pitfalls and achieve real business transformation.<\/p>\n\n\n\n