Multi-Cloud & Migration Strategies

Every organisation running workloads today is facing the same pressure: move faster, spend less, scale without limits, and do not go down. The answer the industry converged on is cloud. But moving to the cloud is not a single decision, it is a sequence of architectural, financial, and operational decisions that, made correctly, transform how a business operates. Made poorly, they create a mess that is more expensive and harder to manage than what you had before. This guide covers the full migration journey: why organisations move, how they decide what to do with each workload, which AWS services make each move possible, and at the end, what it means to think beyond a single cloud provider entirely. Every concept is introduced with the problem first, then the strategy, then the implementation, then the limits of that approach. Table of Contents - The Case for Cloud Migration - What You Are Actually Solving - The 7Rs - Migration Strategy for Every Workload - Discovery and Planning - Before You Move Anything - AWS Migration Hub - Centralising the Journey - AWS Application Migration Service (MGN) - Lift and Shift at Scale - AWS Database Migration Service (DMS) - Moving Your Data - AWS Snow Family - When the Network Is Not Enough - AWS DataSync - Continuous Online Data Transfer - AWS Transfer Family - Managed File Transfer Protocols - VMware Cloud on AWS - The Hybrid Bridge - Migration Execution - The Three-Phase Model - Post-Migration Optimisation - The Work That Actually Delivers Value - Vendor-Neutral: Designing for Multi-Cloud The Case for Cloud Migration - What You Are Actually Solving The Problem With On-Premises Infrastructure An organisation running its own data centre is solving a set of problems that are not its core business. Procuring servers. Managing physical security. Negotiating power and cooling contracts. Patching hardware firmware. Replacing failed disks. Planning for capacity 18 months ahead because hardware lead times are long. None of that creates value for the business. It is overhead. And it scales linearly, more workload means more hardware, more staff, more data centre space. Beyond the operational burden, on-premises infrastructure has three structural problems: Capital expenditure - Servers are bought years before they are fully utilised. The capital is spent upfront. Utilisation rates in enterprise data centres average 15-25%. You are paying for 100% of the capacity to use 20% of it. Rigidity - Scaling up takes months (procurement, delivery, racking, configuration). Scaling down means idle hardware you already paid for. You cannot respond to demand, you guess in advance and live with the consequences. Risk concentration - Your data centre is your single point of failure. A power event, a cooling failure, a network cut. The redundancy you can afford to build is limited by what you can physically fit in the building. What Cloud Migration Actually Delivers Cloud migration is not about moving servers. It is about changing the economic and operational model of running technology. Operational expenditure - You pay for what you use, when you use it. Capital is not locked up in hardware. Infrastructure cost becomes variable, not fixed. Elasticity - Capacity scales in minutes, not months. A spike in demand is handled automatically. A drop in demand means costs drop automatically. Global reach - AWS operates in 33 regions worldwide. Deploying your application closer to your users is a configuration change, not a construction project. Managed services - Every service you stop running yourself databases, message queues, load balancers, monitoring is a service your team stops maintaining and patching. That time goes back to building your product. Security posture - AWS invests billions in physical and logical security that no individual organisation can match. The shared responsibility model means AWS handles the security of the infrastructure; you handle the security of what you run on it. Migration is the means. These outcomes are the goal. The 7Rs - Migration Strategy for Every Workload The Problem You have 200 applications. Some are modern. Some are ancient. Some are business-critical. Some are barely used. You cannot treat all of them the same way. Moving a legacy mainframe billing system the same way you move a containerised web application is wrong. You need a framework for making the right decision for each workload. That framework is the 7Rs. The Framework The 7Rs are seven migration strategies. Every workload fits into one of them. The right choice depends on the workload's business value, technical complexity, age, and strategic direction. R1 - Retire What it is: Decommission the application entirely. Turn it off. When to use it: The application provides no current business value, has no active users, or its functionality is already covered by another system. Analysis during the discovery phase often reveals that 10-20% of an application portfolio is in this category systems that nobody noticed were no longer being used. What happens: Nothing moves to the cloud. The cost disappears entirely. This is the highest ROI migration strategy because there is nothing to migrate. Question to ask: When did anyone last log into this system? If the answer is "I am not sure," it may be a candidate for retirement. R2 - Retain What it is: Keep the application where it is. Do not migrate it now. When to use it: The application has a compliance requirement to remain on-premises. It depends on hardware that cannot be virtualised. It is being replaced soon and migration is not worth the investment. Or the technical complexity and risk of migration are not justified by the business benefit. What happens: The application stays in the existing environment. It is explicitly excluded from the migration scope not forgotten, but intentionally deferred. Important distinction: Retain is a decision, not an avoidance. You acknowledge the workload and consciously choose not to move it. Workloads with no clear decision are a risk, they fall through the cracks of a migration programme. R3 - Rehost (Lift and Shift) What it is: Move the application to the cloud with no changes. The same operating system, the same application binaries, the same configuration, running on EC2 instead of a physical server. When to use it: Speed is the priority. The application is stable but not worth re-architecting. You want to exit a data centre by a deadline. The organisation needs cloud experience before attempting more complex migrations. What happens: The application runs exactly as it did on-premises. No functionality changes. No performance improvements. No cost optimisation yet. The trade-off: You get off the physical infrastructure quickly. But you pay cloud prices for on-premises thinking. An application running on an oversized server on-premises runs on an oversized EC2 instance in the cloud. The savings come later, during optimisation, not from the migration itself. AWS service: Application Migration Service (MGN). Covered in section 5. R4 - Replatform (Lift, Tinker, and Shift) What it is: Make targeted optimisations during migration without changing the core application architecture. When to use it: The application would benefit from a managed service, but a full rewrite is not justified. You want to reduce operational overhead without redesigning the system. Examples: - Move from self-managed MySQL on EC2 to Amazon RDS for MySQL. Same database engine, same data, same queries. But now AWS manages backups, patching, replication, and failover. - Move from a self-managed message queue on EC2 to Amazon SQS. Same messaging pattern, no queue infrastructure to manage. - Containerise the application without changing the application code, then run it on ECS instead of EC2. Same application, smaller and more portable runtime. What happens: The application moves to the cloud with some managed services replacing self-managed components. Operational overhead decreases. The application is not refactored, it works the same way from the outside. The trade-off: More work than rehost, but not as much as refactor. The optimisation payoff is real but bounded, you are still running an application that was not designed for the cloud. R5 - Refactor / Re-architect What it is: Redesign the application to use cloud-native capabilities. Change how it works, not just where it runs. When to use it: The application has scaling problems that the current architecture cannot solve. Business agility requirements demand faster deployment cycles. The cost of running the current architecture in the cloud would be high relative to a re-architected version. The application is strategically important enough to justify the investment. Examples: - Break a monolithic application into microservices, each deployed independently. - Move from a batch processing system to an event-driven architecture using Lambda and SQS. - Replace a relational database with DynamoDB for a workload that needs to scale to millions of requests per second. - Redesign a stateful application to be stateless, enabling horizontal scaling. What happens: The application emerges from migration as a fundamentally different system. It scales elastically. It costs less at scale. It deploys faster. But the engineering investment is significant. The trade-off: Highest effort, highest reward. This is the strategy that delivers genuine cloud-native benefits, not just running the same thing somewhere else. R6 - Repurchase What it is: Replace the application with a SaaS (Software as a Service) product. When to use it: A commercial SaaS product covers the use case better than your existing application. The cost of maintaining the existing application exceeds the SaaS subscription cost. The organisation no longer wants to be in the business of running that type of software. Examples: - Replace a self-hosted CRM with Salesforce. - Replace a self-hosted HR system with Workday. - Replace a custom email platform with