Cloud Migration and the AWS CAF (Task 1.3)

Migration to the AWS Cloud and the AWS CAF

Source: https://aws.amazon.com/cloud-adoption-framework/

The exam tests four things from this topic: why organizations migrate, how the AWS CAF organizes the journey, which migration strategy (the 6 Rs) fits each application, and which data-transfer tool moves the data. Every concept below is explained in brief, then with an example, then with a real use-case.

Why Migrate? (Business Benefits the Exam Expects)

Brief: Companies migrate for measurable business outcomes, not just cheaper servers. The exam expects you to recognize these four:

• Reduced business risk — AWS handles security patching, hardware failure recovery, and capacity planning, so aging hardware and unpatched software stop being daily operational risks.
• Improved ESG performance — AWS runs workloads on high-utilization hardware powered increasingly by renewable energy, so the carbon footprint per workload is lower than a typical on-premises data center.
• Increased revenue — global reach and faster time-to-market: a product can launch in 30+ Regions in one afternoon instead of years of data-center expansion.
• Increased operational efficiency — managed services and automation eliminate manual toil (patching, backups, capacity management), freeing engineers for product features.
• The team inventory finds 15 applications nobody has used in 2 years → Retire.
• 60 mainstream apps (ERP, internal tools) must move unchanged within the deadline → Rehost with AWS Application Migration Service.
• 20 apps move to SaaS equivalents (HR, ITSM) → Repurchase.
• 10 apps get a small change: self-managed DBs move to RDS → Replatform.
• 5 mission-critical customer-facing monoliths will later become microservices → Refactor (post-deadline roadmap).
• 10 systems bound to licensed mainframe hardware stay → Retain.
• 40 TB of nightly backups must move now over a 200 Mbps link → a network transfer would take ~19 days of saturated bandwidth, so they order two Snowball Edge devices instead.
• "Same mess, more expense" — rehosting everything, changing nothing, then wondering why the bill is 3x the TCO model. Rehosting is a STARTING point; the savings come from the follow-up optimization (rightsizing, replatforming, managed services).
• TCO that lies — models that omit egress fees, data-transfer during migration, dual-running costs (old + new environment live simultaneously), retraining, and the engineering time to refactor integrations.
• Migrating to the cloud, not IN the cloud — landing workloads in a Region with no architecture plan for HA (single AZ), no tagging, no IaC. The migration ends; the debt begins.
• People as an afterthought — the technical migration succeeds and the operational one fails because nobody trained the on-call team. This is why the CAF's People perspective exists.

Real use-case: A regional bank facing a $4M hardware refresh defers the purchase, exits its data-center lease, and moves to AWS — then redirects 60% of its infrastructure team from maintenance work to building customer-facing digital services.

The AWS Cloud Adoption Framework (AWS CAF)

Brief: The CAF is AWS's playbook for planning cloud adoption. It organizes guidance into six perspectives — three business-facing and three technical-facing. Each perspective is a stakeholder lens that tells you who owns which part of the transformation.

Memory hook: the first three (Business, People, Governance) focus on people and process; the last three (Platform, Security, Operations) focus on technology.

The exam question style is matching — "which perspective owns this activity?" — so learn one signature story per perspective:

Business Perspective

Brief: Builds the business case and proves the migration pays off. Typical owners: CFO, finance analysts, product managers.

Example: Before migration begins, this group runs the TCO analysis, sets success metrics (cost per transaction, deployment frequency), and ranks applications by business value to decide the migration order.

Real use-case: A retailer's finance team shows that moving its e-commerce stack to AWS cuts infrastructure spend 32% and doubles release cadence — the numbers that win board approval for the program.

People Perspective

Brief: Prepares the workforce for the change: training, hiring, career paths, incentives, and culture. Typical owners: HR, people managers, training leads.

Example: A cloud academy retrains Linux admins into cloud/DevOps engineers, and job families plus incentives are updated to reward automation instead of manual firefighting.

Real use-case: An insurer retrains 200 infrastructure engineers through AWS certification paths; attrition during the two-year migration stays at 6% instead of the feared 20%, because staff see a career path, not a layoff.

Governance Perspective

Brief: Keeps the cloud program aligned with company policy and compliance: portfolio management, budget guardrails, tagging standards, license tracking. Typical owners: enterprise architects, program managers, finance.

Example: A cloud center of excellence (CCoE) defines mandatory cost-allocation tags, approved Regions for each data class, and license-compliance rules for Microsoft software.

Real use-case: A pharmaceutical company uses governance controls to prove every regulated workload landed in a validated environment — passing its FDA inspection without a single finding.

Platform Perspective

Brief: Designs and builds the technical foundation — the landing zone, networking, and application architectures. Typical owners: solutions architects, infrastructure engineers.

Example: Building the multi-account structure with AWS Organizations and Control Tower, shared networking with Transit Gateway, and choosing a migration strategy per application.

Real use-case: A streaming company's platform team builds a self-service landing zone (central logging, IAM baselines, shared network) so 40 application teams can deploy safely without waiting on central IT.

Security Perspective

Brief: Bakes security into the environment from day one: identity and access, detective controls, data protection, incident response. Typical owners: CISO, security engineers.

Example: Enabling GuardDuty across all accounts, requiring IAM roles instead of long-lived access keys, encrypting data with KMS, and rehearsing incident-response runbooks.

Real use-case: A fintech sets a Service Control Policy that blocks public S3 buckets org-wide. Six months later an engineer misconfigures a bucket — the SCP silently prevents the exposure, and the incident never happens.

Operations Perspective

Brief: Defines how workloads run day-to-day: monitoring, incident and problem management, change and release management. Typical owners: IT operations, SREs.

Example: CloudWatch dashboards and alarms per workload, documented runbooks for the top 10 incidents, and blue/green deployments replacing risky weekend change windows.

Real use-case: A SaaS provider moves from quarterly maintenance windows to daily zero-downtime releases; mean time to recover drops from 4 hours to 20 minutes.

Migration Strategies: The 6 Rs (plus Relocate)

Brief: Every application in the portfolio gets exactly one strategy, chosen by deadline, budget, and appetite for change. The exam presents a scenario and expects the matching R.

Rehost ("Lift and Shift")

Brief: Move the application to EC2 exactly as it is — same OS, same code, same architecture. No changes, lowest per-app effort, fastest way out of a data center.

Example: The on-premises server's image is converted and launched as an EC2 instance; the app reconnects to its database and serves traffic the same afternoon.

Real use-case: A retailer exiting a data-center lease in 9 months rehosts 60 mainstream internal apps with AWS Application Migration Service (MGN) — servers replicate continuously and cut over in waves, meeting the deadline with zero code changes.

Relocate

Brief: Move a whole platform to AWS without touching the applications running on it. Unlike rehost (per-server), relocate moves the hypervisor or management layer itself.

Example: Hundreds of VMware VMs move from on-premises vSphere to VMware Cloud on AWS — no guest-OS conversion, no reinstall, no application changes.

Real use-case: A manufacturer with 300 VMware VMs and no time for per-server work relocates the entire estate in weeks; applications never notice the move.

Replatform ("Lift, Tinker, and Shift")

Brief: Keep the application architecture but make a few targeted optimizations during the move — typically swapping self-managed middleware or databases for managed AWS services.

Example: The app stays on EC2, but its self-managed MySQL database moves to Amazon RDS — gaining automated backups, patching, and Multi-AZ failover without changing application code.

Real use-case: A media company moving 10 apps replaces their hand-run PostgreSQL installs with RDS; the DBA's weekly patching ritual disappears and failover becomes automatic.

Repurchase

Brief: Decommission the current application and buy a SaaS equivalent. You trade customization for zero maintenance.

Example: An aging self-hosted HR system is switched off; employees move to a SaaS HR platform, and the internal team that maintained it is redeployed.

Real use-case: A logistics company maintains a 12-year-old internal ITSM tool with one full-time developer; it repurchases SaaS ITSM, saves ~$180K/year, and reassigns the developer to customer-facing work.

Refactor / Re-architect

Brief: Rebuild the application cloud-native — usually monolith to microservices. Highest upfront cost and risk; highest long-term agility, scalability, and cost benefit.

Example: A monolithic Java e-commerce app is decomposed into ~20 containerized microservices on ECS behind an API gateway, each with its own database and independent scaling.

Real use-case: A travel-booking monolith that could only scale as one unit is refactored into microservices; the search service now scales independently during holiday peaks, cutting compute cost 40% while improving response time.

Retire

Brief: Decommission applications nobody needs. Enterprise discovery typically finds 10–20% of a portfolio is already dead — turning migration planning into immediate savings.

Example: The application inventory shows 15 systems with zero logins in 2 years; they are simply switched off during migration planning.

Real use-case: A bank's assessment finds 40 of 300 apps unused; retiring them removes $1M/year in license, hardware, and support costs before any migration begins.

Retain

Brief: Deliberately keep some systems on-premises — for regulatory, latency, licensing, or cost reasons. Retaining is a decision, not a failure.

Example: A mainframe-bound legacy system with an expensive hardware-tied license stays in the current data center and is revisited in 3 years.

Real use-case: A hospital keeps its radiology imaging system on-premises because the PACS vendor does not support cloud deployment yet and the license is tied to physical hardware.

Data Migration: Picking the Right Tool

Brief: Three tools move data into AWS. The choice depends on what the data is (database vs files) and how much of it there is versus how fast your network is.

AWS Database Migration Service (DMS)

Brief: Migrates databases — homogeneous (Oracle→Oracle) or heterogeneous (Oracle→Aurora) — with minimal downtime. The source keeps serving traffic while changes replicate continuously.

Example: A cutover that takes minutes, not a weekend: DMS copies the full table data first, then applies ongoing changes; you switch the application's connection string once replication lag reaches zero.

Real use-case: An airline's reservations database migrates from on-premises Oracle to Aurora PostgreSQL during a 15-minute maintenance window on a Tuesday night — bookings continue through the change.

AWS Snow Family

Brief: Rugged physical devices (Snowball Edge up to ~80 TB usable per device; Snowmobile up to 100 PB, a 45-foot shipping container) for offline transfer when the network is too slow, unreliable, or air-gapped.

Example: One Snowball Edge carries roughly what a 100 Mbps link moves in 7–8 days of saturated bandwidth; ship several in parallel to go faster.

Real use-case: A genomics firm with 8 PB of sequencing data and a 1 Gbps link would need ~2 years to upload; instead, 80 Snowball Edge devices ship over six weeks.

AWS DataSync

Brief: Agent-based, scheduled, accelerated transfer of file data between on-premises NFS/SMB shares and S3, EFS, or FSx — with integrity verification and in-flight compression.

Example: A small VM agent is deployed next to the file server; a scheduled task moves changed files to S3 at up to 10 Gbps.

Real use-case: A design studio migrates 40 TB of project files from an aging NAS to S3 over a weekend using DataSync's parallel transfers — then keeps the agent running as an ongoing sync until the NAS is retired.

Rule of thumb the exam loves: slow/unreliable network or tens of TB and more → Snowball Edge / Snowmobile; databases → DMS; file shares → DataSync.

Worked Example: Putting It All Together

A retailer with 120 on-premises applications must exit a data-center lease in 9 months:

• Reduced business risk — AWS handles security patching, hardware failure recovery, and capacity planning, so aging hardware and unpatched software stop being daily operational risks.
• Improved ESG performance — AWS runs workloads on high-utilization hardware powered increasingly by renewable energy, so the carbon footprint per workload is lower than a typical on-premises data center.
• Increased revenue — global reach and faster time-to-market: a product can launch in 30+ Regions in one afternoon instead of years of data-center expansion.
• Increased operational efficiency — managed services and automation eliminate manual toil (patching, backups, capacity management), freeing engineers for product features.
• The team inventory finds 15 applications nobody has used in 2 years → Retire.
• 60 mainstream apps (ERP, internal tools) must move unchanged within the deadline → Rehost with AWS Application Migration Service.
• 20 apps move to SaaS equivalents (HR, ITSM) → Repurchase.
• 10 apps get a small change: self-managed DBs move to RDS → Replatform.
• 5 mission-critical customer-facing monoliths will later become microservices → Refactor (post-deadline roadmap).
• 10 systems bound to licensed mainframe hardware stay → Retain.
• 40 TB of nightly backups must move now over a 200 Mbps link → a network transfer would take ~19 days of saturated bandwidth, so they order two Snowball Edge devices instead.
• "Same mess, more expense" — rehosting everything, changing nothing, then wondering why the bill is 3x the TCO model. Rehosting is a STARTING point; the savings come from the follow-up optimization (rightsizing, replatforming, managed services).
• TCO that lies — models that omit egress fees, data-transfer during migration, dual-running costs (old + new environment live simultaneously), retraining, and the engineering time to refactor integrations.
• Migrating to the cloud, not IN the cloud — landing workloads in a Region with no architecture plan for HA (single AZ), no tagging, no IaC. The migration ends; the debt begins.
• People as an afterthought — the technical migration succeeds and the operational one fails because nobody trained the on-call team. This is why the CAF's People perspective exists.

Running this program — the TCO analysis, the training academy, the tagging standards, the landing zone, org-wide GuardDuty, the new operations runbooks — is exactly what the six CAF perspectives coordinate.

Senior-Level: Migration Execution and Anti-Patterns

Wave planning, not big bang. Real migrations move in waves: discover (dependencies, data flows), mobilize (landing zone, CCoE), then migrate wave by wave — lowest-risk apps first (internal tools), mission-critical last. Dependency mapping is the hard part: application A calls B's database directly; if they migrate in different waves, you just bought yourself a cross-network latency problem or an outage. Tools: AWS Application Discovery Service, Migration Evaluator.

The classic anti-patterns (interview-grade):

• Reduced business risk — AWS handles security patching, hardware failure recovery, and capacity planning, so aging hardware and unpatched software stop being daily operational risks.
• Improved ESG performance — AWS runs workloads on high-utilization hardware powered increasingly by renewable energy, so the carbon footprint per workload is lower than a typical on-premises data center.
• Increased revenue — global reach and faster time-to-market: a product can launch in 30+ Regions in one afternoon instead of years of data-center expansion.
• Increased operational efficiency — managed services and automation eliminate manual toil (patching, backups, capacity management), freeing engineers for product features.
• The team inventory finds 15 applications nobody has used in 2 years → Retire.
• 60 mainstream apps (ERP, internal tools) must move unchanged within the deadline → Rehost with AWS Application Migration Service.
• 20 apps move to SaaS equivalents (HR, ITSM) → Repurchase.
• 10 apps get a small change: self-managed DBs move to RDS → Replatform.
• 5 mission-critical customer-facing monoliths will later become microservices → Refactor (post-deadline roadmap).
• 10 systems bound to licensed mainframe hardware stay → Retain.
• 40 TB of nightly backups must move now over a 200 Mbps link → a network transfer would take ~19 days of saturated bandwidth, so they order two Snowball Edge devices instead.
• "Same mess, more expense" — rehosting everything, changing nothing, then wondering why the bill is 3x the TCO model. Rehosting is a STARTING point; the savings come from the follow-up optimization (rightsizing, replatforming, managed services).
• TCO that lies — models that omit egress fees, data-transfer during migration, dual-running costs (old + new environment live simultaneously), retraining, and the engineering time to refactor integrations.
• Migrating to the cloud, not IN the cloud — landing workloads in a Region with no architecture plan for HA (single AZ), no tagging, no IaC. The migration ends; the debt begins.
• People as an afterthought — the technical migration succeeds and the operational one fails because nobody trained the on-call team. This is why the CAF's People perspective exists.

How to prove migration success: define metrics BEFORE wave 1 — cost per workload, RTO/RPO achieved, deployment frequency, incident count. A migration that cannot show numbers was a leap of faith.

Gotchas & interview notes: know MGN's mechanics for rehost (continuous block-level replication from source servers, test instances for rehearsal, non-disruptive cutovers) and DMS's (full load + CDC — change data capture — keeping source and target in sync until cutover). When asked "how do you migrate with near-zero downtime?", the answer is ALWAYS replication + cutover-window, never a dump-and-restore.