Moving to AWS: the Cloud Adoption Framework and migration strategies

Why this matters

Most companies that use AWS did not start there. They arrived with years of servers, databases and licensed software, and moving them is a business project as much as a technical one. Budgets have to be justified, staff have to learn new skills, risks have to be managed, and every application needs a decision about what happens to it.

A manager will be asked to build the business case. A salesperson will be asked which AWS service actually moves a database, and the answer is not the one with "Application" in its name. A junior engineer will be handed a spreadsheet of a few hundred servers and asked which ones can simply be switched off. This lesson gives each of them the framework AWS uses to organise a move, the vocabulary for the decision made about each application, and the services and resources that help along the way.

The lesson

Cloud adoption strategies

Adopting the cloud well is a transformation of how the organisation works, not only a change of where servers run. AWS's guidance treats it in two layers.

The first layer is organisational readiness: does the company have the strategy, skills, governance, security and operations to succeed in the cloud? That is what the AWS Cloud Adoption Framework (AWS CAF) addresses, and it is covered in detail below.

The second layer is the migration itself, which AWS describes as three phases. Assess: understand the current estate and build the business case. Mobilize: plan in detail, close gaps in skills and readiness, and prepare the landing environment. Migrate and modernise: move the workloads and improve them once they are running on AWS.

Within the migration, a company does not choose one strategy for everything. It runs portfolio discovery, which means listing every application with its usage, dependencies and owner, and then chooses a migration strategy for each one. A common pattern is to move quickly first, often unchanged, to meet a deadline such as the end of a data-centre lease, and to optimise later once the workloads are on AWS.

The reasons for adopting the cloud at all are the benefits from lesson 1: variable instead of upfront expense, elasticity, agility and global reach. The CAF turns those benefits into business outcomes a board can measure.

Resources to support the cloud migration journey

AWS offers migration services, published guidance and people. Learn what each service does and, just as important, what it does not do.

Planning and tracking:

• AWS Migration Hub is one place to discover servers, plan migrations and track the status of every application being moved, whichever AWS or partner tool performs the move. AWS stopped offering Migration Hub to new customers in November 2025 and points them to AWS Transform instead, but the exam guide still names Migration Hub, so know what it does. AWS Service Catalog, which lets teams launch approved products, and AWS Systems Manager, which manages running resources, do not track migrations.
• AWS Application Discovery Service collects configuration, utilisation and dependency data from on-premises servers, so a company knows what it has and which applications must move together. Despite the similar name, it moves nothing.
• Migration Evaluator analyses an on-premises estate and produces a data-driven business case with projected AWS costs. AWS Cost Explorer is the trap here: it reports on spending that has already happened in AWS, so a company with no AWS usage has nothing for it to analyse.

Moving the workloads:

• AWS Application Migration Service replicates physical, virtual or cloud-hosted source servers into AWS and launches them as Amazon EC2 instances. It automates rehosting, the "lift and shift" strategy described below.
• AWS Database Migration Service (AWS DMS) moves databases into AWS, including into Amazon RDS (lesson 16). The source database stays fully operational during the migration.
• AWS Schema Conversion Tool (AWS SCT) converts a database schema, which is the structure of tables, views and stored procedures, from one database engine to another.

Guidance and people:

• AWS Prescriptive Guidance is a self-service library of AWS-vetted strategies, patterns and implementation guides for migrating and modernising, which a team can read without contacting AWS.
• AWS Professional Services is a team of AWS experts that customers can engage to plan and carry out a migration. AWS Partner Network (APN) partners and AWS solutions architects also advise. Lesson 26 covers partners and professional services.
• The AWS CAF itself, and the AWS Well-Architected Framework (lesson 2) for the design of each workload once it lands.

Some services in the same scenarios do something else entirely. AWS Cost and Usage Reports holds detailed billing data, AWS Certificate Manager manages TLS certificates, and AWS Resource Access Manager shares resources between accounts. None of them supports a migration with advice or patterns.

The AWS CAF: business outcomes, perspectives and transformation phases

The AWS CAF draws on AWS's experience with many customers to help an organisation plan its cloud transformation. Do not confuse it with the Well-Architected Framework: the Well-Architected Framework has six pillars for reviewing the design of a workload, while the CAF has six perspectives for preparing an organisation.

Business outcomes. The CAF describes four outcomes a transformation should deliver. Matching an example to its outcome is a likely task.

• Reduced business risk: improved reliability, increased performance and enhanced security, so fewer outages and incidents.
• Improved ESG performance: better environmental, social and governance results, for example lower energy use from AWS's efficient, shared infrastructure, and clearer reporting on carbon emissions.
• Increased revenue: new products and services, new customers and new market segments, often reached because products launch faster.
• Increased operational efficiency: lower operating costs, higher staff productivity and a better employee and customer experience, for example by retiring old hardware and automating routine IT work.

The six perspectives. Each perspective groups related capabilities. The first three are business capabilities, the last three technical.

• Business: makes sure cloud investments accelerate digital transformation and business outcomes. Capabilities include strategy management, portfolio management, product management and innovation management.
• People: bridges technology and business, with culture evolution, transformational leadership, cloud fluency, workforce transformation and change acceleration. Staff who lack cloud skills, or leaders who expect resistance to new ways of working, point here.
• Governance: orchestrates cloud initiatives while maximising their benefits and minimising transformation risk. Capabilities include program and project management, benefits management, risk management, cloud financial management, application portfolio management and data governance. Governance runs the programme and manages its risk; it does not set the business strategy, which is the Business perspective.
• Platform: builds an enterprise-grade, scalable hybrid cloud platform and modernises existing workloads, with platform architecture, data architecture, platform engineering, data engineering, modern application development and continuous integration and delivery (CI/CD).
• Security: achieves the confidentiality, integrity and availability of data and cloud workloads, with security governance, identity and access management, threat detection, vulnerability management, data protection and incident response.
• Operations: makes sure cloud services are delivered at a level that meets the needs of the business, with observability, event management, incident and problem management, change and release management, configuration management and patch management. Platform builds the environment; Operations runs it day to day.

The transformation phases. The CAF describes a journey in four phases, repeated as the organisation matures:

1. Envision: identify transformation opportunities and how the cloud supports business outcomes.
2. Align: find capability gaps and cross-organisational dependencies, then create strategies to improve cloud readiness and bring stakeholders into agreement.
3. Launch: deliver a small number of pilot initiatives in production and show business value early.
4. Scale: expand the proven pilots to the desired scale.

A company that has found gaps and is building a readiness plan is aligning; one about to run its first pilots in production is launching.

Choosing a migration strategy, and where database replication fits

AWS lists seven migration strategies, often called the seven Rs. Each is a decision about one application.

• Retire: switch off applications nobody needs. Portfolio discovery often finds applications that nobody has used for a long time, and retiring them cuts cost and shrinks the migration.
• Retain (or revisit): keep the application where it is for now, perhaps because it was recently upgraded or depends on specialised on-premises hardware, and revisit the decision later.
• Rehost ("lift and shift"): move servers to Amazon EC2 as they are, without changing the applications. It is the fastest route for a large estate under a deadline, and AWS Application Migration Service automates it.
• Relocate: move a large number of servers from an on-premises virtualisation platform, such as VMware vSphere, to a cloud-based version of the same platform, without buying new hardware, converting the servers to EC2 instances or changing the applications.
• Repurchase ("drop and shop"): replace the application with a different product, usually software as a service (SaaS), such as moving from a self-managed customer relationship management (CRM) system to a SaaS CRM.
• Replatform ("lift, tinker and shift"): make targeted optimisations while keeping the core architecture and code. Moving a self-managed MySQL database to Amazon RDS for MySQL, so AWS handles patching and backups, is the classic example.
• Refactor (or re-architect): change how the application is built, often to use cloud-native features, to meet new business needs. Rebuilding a monolith, an application built as one large unit, as microservices on AWS Lambda so each part scales and changes independently is refactoring.

Two of these move workloads with no change to the application at all: rehost and relocate. Replatform changes a little, refactor changes the architecture, and repurchase changes the product.

Database replication is how a database moves with very little downtime. Stopping a database, exporting it and copying the export takes a long outage, and restoring last night's backup loses the day's changes. Instead, AWS DMS first loads the existing data into the target and then replicates ongoing changes from the source, which keeps running and serving users. The target stays current, so the final cut-over, when applications switch to the new database, takes minutes.

When the source and target engines are the same, such as MySQL to RDS for MySQL, DMS can move the data directly. When they differ, such as Oracle to Amazon Aurora PostgreSQL, the schema and stored procedures must be converted first with AWS SCT, and then DMS moves the data. SCT converts structure; it does not replicate live data.

What the exam is really asking

For a strategy question, find the amount of change. "As they are", "quickly", "deadline" point to rehost; "same virtualisation platform" to relocate; "managed database, no code change" to replatform; "microservices", "serverless", "re-architect" to refactor; "SaaS product" to repurchase; "unused" to retire; "keep for now" to retain. For a service question, separate discovering (Application Discovery Service), costing (Migration Evaluator), tracking (Migration Hub), moving servers (Application Migration Service), moving databases (DMS) and converting schemas (SCT).