Esc
↑↓ navigate   Enter open   Esc close
Advanced Vocabulary 14 min read

Cloud Migration Strategy Vocabulary: The 6Rs, CAF, and Migration Waves Explained

Master the vocabulary of cloud migration for IT professionals. The 6Rs framework, Cloud Adoption Framework, landing zones, migration waves, TCO analysis, and the language of migration planning discussions.

#cloud#migration#architecture#devops#vocabulary

Cloud migration projects fail not because of technical obstacles alone — they fail because teams lack a shared vocabulary. When your cloud architect says “we need to rearchitect this for cloud-native” and your PM hears “minor refactoring”, you have a communication problem. This guide gives you the precise terms that cloud engineers, architects, and project managers use when planning and executing migration projects.

Why Migration Vocabulary Matters

Cloud migration is a cross-functional discipline. Infrastructure engineers, application developers, security teams, finance, and management all participate in migration decisions. Without shared vocabulary, requirements get lost in translation, risk assessments are vague, and cost estimates are inaccurate.

The language in this article comes from the AWS Cloud Adoption Framework (CAF), Google Cloud Migration Framework, Azure Cloud Adoption Framework, and Gartner research on application portfolio management.

Section 1: The 6Rs Migration Framework

The 6Rs is the standard framework for categorising how each application in your portfolio should be treated during migration. Expect to discuss this in architecture reviews, migration planning sessions, and stakeholder presentations.

Rehost (Lift-and-Shift) Moving an application to the cloud with no changes to its architecture, code, or configuration. The fastest and cheapest migration path, but yields the fewest cloud benefits. Often used as a first step to meet a data-centre exit deadline.

“We’re rehosting the legacy billing system — it’s a lift-and-shift to EC2. We can optimise it later, but right now we need to exit the data centre by Q3.”

Replatform (Lift-and-Shape) Moving to the cloud with minor optimisations that don’t require code changes — for example, moving from self-managed MySQL to Amazon RDS, or changing the web server configuration. Sometimes called “lift-tinker-and-shift.”

“The Java app is being replatformed — we’re swapping the on-prem Oracle DB for Aurora PostgreSQL and moving files to S3. No code changes, just configuration.”

Refactor / Re-architect Significantly modifying the application to take advantage of cloud-native features. Often involves breaking a monolith into microservices, adopting serverless compute, or redesigning for auto-scaling. Highest effort, highest long-term benefit.

“The order processing engine is a refactor — we’re decomposing it into Lambda functions and SQS queues. It’ll take 6 months but we’ll get auto-scaling and 90% cost reduction in off-peak hours.”

Repurchase (Drop-and-Shop) Replacing the existing application with a SaaS alternative. Common for CRM, HR, and ERP systems.

“Instead of migrating our on-prem CRM to the cloud, we’re repurchasing — moving everyone to Salesforce. The legacy system is too expensive to maintain.”

Retire Decommissioning applications that are no longer needed. Often discovered during migration discovery — a significant percentage of enterprise portfolios are unused.

“Discovery showed 30% of our portfolio is candidate for retirement — these services have zero users in the last 6 months. Retiring them saves us $400K/year in licensing.”

Retain (Revisit) Keeping the application on-premises for now, with a plan to revisit the migration decision later. Common for applications with regulatory constraints, hard dependencies on physical hardware, or uncertain future.

“The manufacturing execution system has a hardware dependency on the PLC network — we’re retaining it on-prem and revisiting in 18 months when the plant control infrastructure is upgraded.”

Section 2: Migration Assessment and Portfolio Analysis

Application Portfolio Assessment A structured inventory of all applications in an organisation, including technical details (technology stack, architecture, dependencies), business context (business criticality, cost, owner), and migration suitability. The foundation of any migration programme.

“Before we can plan the migration, we need a full application portfolio assessment — we need to know what we have, who owns it, and what it depends on.”

Migration Fit Scoring A scoring model that rates each application on its suitability for migration, typically using criteria like: technical complexity, business criticality, dependency count, compliance requirements, and team availability. Output drives migration wave planning.

“The scoring model flagged the payment gateway as high-risk: 14 dependencies, PCI scope, and no documentation. That moves it to a later wave.”

Dependency Mapping Identifying the technical dependencies between applications — which systems call which, what databases are shared, what APIs are called at runtime. Critical for sequencing migrations correctly; migrating a service before its dependencies creates outages.

“Dependency mapping revealed that 8 services all call the user-service library directly. We need to migrate the user-service first, before any of the consumers.”

Migration Readiness Assessment (MRA) A formal evaluation of an organisation’s readiness to execute cloud migration — assessing people (skills, change management), process (DevOps maturity, governance), and technology (current state, security posture). Often a prerequisite for a cloud vendor’s migration programme.

“AWS Professional Services ran an MRA with us — we scored low on security controls and medium on DevOps maturity. That shaped our pre-migration capability-building programme.”

Section 3: Cloud Adoption Framework (CAF)

The Cloud Adoption Framework (CAF) is a migration methodology published by major cloud vendors (AWS, Azure, Google). It provides a structured approach to migration covering six perspectives: Business, People, Governance, Platform, Security, and Operations.

Landing Zone A pre-configured, secure, multi-account cloud environment that serves as the foundation for all workloads. A well-designed landing zone enforces organisational policies, network topology, identity management, and guardrails before any application migration begins.

“We spent three months building the landing zone before migrating a single workload — identity federation, network segmentation, logging pipelines, and security controls all set up in code.”

Cloud Foundation The collection of infrastructure, governance, and operational capabilities that underpin the landing zone — security baseline, network architecture, identity, and cost management tooling.

“The cloud foundation team owns the landing zone and sets guardrails. Application teams provision into the foundation without touching the underlying security controls.”

Operating Model How the organisation will operate in the cloud long-term — who owns what, how changes are made, how incidents are managed, how cost is governed. A new operating model is often required when moving from data-centre operations to a cloud-native model.

“The biggest challenge wasn’t technical — it was the operating model shift. Moving from a ticket-based change process to self-service infrastructure with guardrails required a different way of working.”

Cloud Centre of Excellence (CCoE) A cross-functional team responsible for defining cloud standards, best practices, and guardrails across the organisation. Acts as an enablement team rather than a gatekeeper.

“Our CCoE maintains the landing zone modules, publishes approved patterns, and runs internal training. Application teams get fast approval when they use approved patterns.”

Section 4: Migration Execution Vocabulary

Migration Wave A group of applications migrated together in a coordinated sequence. Applications are grouped by dependency relationships, team availability, and risk profile. Early waves typically contain simple, low-risk applications for learning; later waves include complex, business-critical systems.

“We’re running six migration waves over 14 months. Wave 1 is 12 non-critical dev/test environments — learning run. Wave 5 is the production ERP — that’s the most complex one.”

Cutover Window The scheduled time period during which the migration of a specific application from on-premises to cloud is completed. Usually scheduled during low-traffic windows (nights, weekends). The cutover window must be short enough to minimise downtime.

“The payment system has a 4-hour cutover window on Saturday night — midnight to 4am. If we’re not green by 3:30am, we execute the rollback procedure.”

Parallel Run Operating both the old (on-premises) and new (cloud) systems simultaneously, routing traffic to both, and comparing results before committing to the cloud version. Reduces risk but doubles cost temporarily.

“We ran the reporting database in parallel for 3 weeks — both systems received all writes, and we compared query results nightly. No discrepancies detected before we cut over fully.”

Rollback Plan A documented procedure for returning to the pre-migration state if the cloud deployment fails or performance is unacceptable. Should be tested before the cutover window, not written on the day.

“Our rollback plan is: repoint DNS to on-prem ELB within 4 minutes, restore database cluster from the pre-cutover snapshot, and notify stakeholders within 10 minutes. We tested the rollback procedure last week.”

Migration Factory A repeatable, industrialised migration process applied to large-scale migrations — a team structured as an assembly line, with standardised templates, tooling, and quality checks for each application type. Enables migrating dozens of applications per week at scale.

“We’re running a migration factory for the 400 non-critical applications — the same playbook, the same automation, the same team structure. Our run rate is 20 migrations per week.”

Hypercare Period An intensive monitoring period immediately after cutover, during which additional engineers are on-call and response times are faster than normal SLAs. Typically 1–4 weeks.

“All migrated services are in hypercare for 30 days post-cutover — the on-call team is doubled and P1 response time is 15 minutes instead of the standard 30.”

Section 5: Cost and Financial Vocabulary

Total Cost of Ownership (TCO) Analysis A comparison of the full cost of running workloads on-premises versus in the cloud, including: hardware depreciation, data-centre facilities (power, cooling, space), licensing, operations staff, and cloud service costs. TCO analysis is used to justify migration investment to finance.

“The TCO analysis showed a 35% 3-year cost reduction if we migrate — but that only holds if we rightsize the instances and use reserved capacity for stable workloads.”

CapEx vs. OpEx Shift On-premises infrastructure is typically CapEx (capital expenditure — upfront investment in hardware). Cloud is OpEx (operational expenditure — pay-as-you-go). This accounting shift has tax and financial planning implications.

“The CFO loves the OpEx model — cloud costs match revenue seasonality, and there’s no 3-year hardware depreciation cycle to manage.”

Rightsizing Selecting the smallest cloud instance size that meets performance requirements. Over-provisioned on-premises servers often run at 10–15% CPU utilisation; rightsizing matches cloud resources to actual workload demand.

“After the lift-and-shift, we ran 30 days of utilisation data and rightsized: dropped 40% of instances by one or two size levels. Saved $18K/month.”

Reserved Capacity / Savings Plans Committing to a cloud resource for 1 or 3 years in exchange for a significant discount (typically 30–70%) versus on-demand pricing. Used for stable, predictable workloads.

“We bought 1-year reserved instances for the database tier — 45% discount over on-demand. For variable app tier workloads, we use savings plans for flexibility.”

Section 6: Migration Discussion Language

These phrases appear frequently in migration planning discussions, architecture reviews, and status updates:

ContextPhrase
Recommending a migration path”Given the application’s dependency profile and team capacity, I’d recommend replatforming rather than refactoring — the business value doesn’t justify a 6-month re-architecture.”
Discussing risk”This is a high-blast-radius migration — if it fails, it takes down the entire checkout flow. We need a fully tested rollback procedure before we schedule the cutover.”
Wave planning”I’d move this to Wave 4 — it has a dependency on the identity service, which isn’t migrating until Wave 3.”
Stakeholder update”We’re on track for Wave 2 cutover this weekend. Parallel run results are clean. Rollback is tested. We’re green.”
Surfacing risk”The dependency map shows a hidden dependency on an on-prem NFS share that wasn’t in the portfolio data. That’s a blocker — we need to resolve this before scheduling the cutover.”