If you’ve landed here from a class, a certification exam, or a quick search, you’ve probably noticed something: “the 7 steps of cloud migration” means two different things depending on where you look. That’s not a typo on your part; it’s a genuine naming collision in the industry, and it’s worth five seconds to sort out before you read further.
There are two commonly referenced frameworks:
- The Seven-Step Model of Migration into the Cloud: the specific, named academic/technical model most often cited in cloud computing coursework and certification material: Assessment → Isolation → Mapping → Re-Architect → Augmentation → Testing → Monitor.
- The general 7-step migration process: a looser, practitioner-oriented sequence used across the industry to describe any cloud migration project at a high level: Assess → Plan → Design → Pilot → Migrate → Validate → Optimize.
Both are legitimate. They’re just answering different questions: one is a formal named model, the other is a generic project outline. This article defines both clearly, in full, so you get the right one whether you’re prepping for an exam or planning an actual migration.
TL;DR
- The Seven-Step Model of Migration into the Cloud is the specific named academic framework: Assessment, Isolation, Mapping, Re-Architect, Augmentation, Testing, Monitor.
- The general 7-step migration process most businesses actually follow is: Assess, Plan, Design, Pilot, Migrate, Validate, Optimize.
- Migration strategy (how you move each workload) is a separate decision from migration process (the steps you follow); see the 6 R’s comparison table below.
- Understanding application dependencies is the single biggest barrier organizations report when migrating to the cloud, ahead of technical feasibility and cost comparison.
- Tool choice matters: AWS Application Migration Service (MGN) has replaced CloudEndure as AWS’s primary migration tool. If you’ve seen “CloudEndure” in older guides, this is the current name.
Part 1: The Seven-Step Model of Migration into the Cloud
This is the model most textbooks, courses, and certification exams refer to when they ask you to “explain the seven-step model of migration into the cloud.” If you’re here for a definition, this is the section you want.
Step 1: Assessment
Audit your existing infrastructure, applications, and data, and build a data migration plan that evaluates prospective cloud providers against six criteria:
- Certifications and standards: does the provider meet your industry’s compliance requirements?
- Technology and service roadmap: how is the platform investing in the capabilities you’ll need in 2–3 years, not just today?
- Data governance and security: request internal security audit reports and review data-handling policies.
- Service dependencies and partnerships: understand the provider’s vendor ecosystem and accountability structure.
- Reliability and performance: check historical performance against published SLAs.
- Business health and company profile: assess the provider’s financial stability and market position.
If you’d rather not run this scoring exercise from scratch, Our Cloud Assessment Workshop is built specifically for this step: a structured, guesswork-free evaluation before you commit to a platform or timeline.
Quick checklist:
- Inventory all applications, dependencies, and data stores
- Score 2–3 candidate cloud providers against the six criteria above
- Document current infrastructure costs as a baseline for post-migration comparison
Step 2: Isolation
Assemble a cross-functional team spanning engineering, security, and business stakeholders, and prepare your data for transfer. This means removing duplicated or unnecessary data segments and organizing what remains into a format compatible with your chosen cloud platform.
Quick checklist:
- Name a cross-functional migration owner and a decision-maker from each affected team
- De-duplicate and clean the data set slated for migration
- Confirm data format compatibility with the target platform
Step 3: Mapping
With your data prepared, choose your cloud platform:
- Amazon Web Services (AWS): the broadest service catalog and largest market share; typically a strong fit for large enterprises with complex requirements, though pricing can run higher.
- Microsoft Azure: strong hybrid-cloud integration and competitive pricing; a natural fit for organizations already invested in the Microsoft ecosystem.
- Google Cloud Platform (GCP): cost-effective and AI/data-focused; popular with startups and data-driven teams.
For a deeper side-by-side breakdown of compute, pricing, and DevOps tooling across all three, see our AWS vs. Azure vs. Google Cloud comparison. If you’d rather have this scoped for your specific workload mix, Our Cloud Solutions team handles architecture and provider selection directly.
Quick checklist:
- Shortlist providers against workload requirements, not just brand familiarity
- Run a cost estimate for your actual workload mix on each shortlisted platform
- Confirm regional availability and data-residency requirements
Step 4: Re-Architect
Adapt your application to run natively in the cloud. This typically involves selecting the right instance type, provisioning virtual machines, and packaging your application into a deployable image. Some applications need real architectural changes, not just a lift-and-shift, to take advantage of cloud-native scaling, managed services, or containerization (via Kubernetes) rather than running as-is on rented infrastructure.
Quick checklist:
- Identify components that need re-architecture vs. those that can lift-and-shift as-is
- Right-size instance types against actual (not estimated) resource usage
- Evaluate containerization or Infrastructure-as-Code (e.g., Terraform) for repeatable, version-controlled deployments
If your re-architecture involves moving data pipelines or a data warehouse rather than just application infrastructure, this typically becomes its own workstream. See Liquid Technologies’ Data Engineering services for cloud-native data migration and Snowflake architecture.
Step 5: Augmentation
Go beyond a straight deployment and use cloud-native capabilities to elevate the whole operation: dynamic scaling to match demand, and integration with other cloud-native services rather than isolated point solutions.
Quick checklist:
- Configure auto-scaling policies based on real traffic patterns
- Identify integration points with other cloud-native services (queues, managed databases, event triggers)
Step 6: Testing
Run the migrated environment through structured test scenarios using representative data, and compare outputs against your pre-migration baseline to catch accuracy issues, performance regressions, or unexpected behavior before go-live.
Quick checklist:
- Define acceptance criteria before testing begins, not after
- Run load testing at expected peak, not just average, traffic
- Compare functional outputs against the pre-migration baseline
Step 7: Monitor
Migration isn’t the finish line; ongoing monitoring is what protects the investment. Keep training data and configurations current, track performance against your baseline, and monitor cost alongside performance so efficiency gains don’t quietly erode.
Quick checklist:
- Set up cost and performance dashboards from day one, not after issues appear
- Schedule a 30/60/90-day post-migration review
- Assign clear ownership for ongoing optimization (see FinOps note below)
Part 2: The General 7-Step Migration Process
If you came here to actually plan a migration rather than answer a definition question, this is the practical version most organizations use as a project outline. It overlaps conceptually with Part 1 but is organized around project phases rather than the named academic steps:
| # | Phase | What happens |
|---|---|---|
| 1 | Assess | Audit infrastructure, apps, and data to scope the project |
| 2 | Plan | Define strategy, timeline, budget, and select a provider |
| 3 | Design | Architect security, networking, storage, and scalability |
| 4 | Pilot | Migrate one low-risk workload first to validate the process |
| 5 | Migrate | Move workloads in planned phases |
| 6 | Validate | Test performance, security, and functionality |
| 7 | Optimize | Monitor and refine cost, performance, and security continuously |
The practical difference: the seven-step academic model (Part 1) describes how a single application gets re-architected and deployed. This general process (Part 2) describes how a whole migration project gets managed, including the pilot phase most real-world projects rely on to de-risk the full rollout.
Migration Strategies: The 6 R’s
Separately from which steps you follow, you also need to decide how each workload gets moved. This is the “6 R’s” framework:
| Strategy | What it means | Best for | Trade-off |
|---|---|---|---|
| Rehost (“lift and shift”) | Move as-is with minimal changes | Fast timelines, low upfront cost | Doesn’t capture cloud-native efficiency gains |
| Replatform | Lift with light optimization | Teams building cloud confidence | Some engineering effort required |
| Refactor | Rebuild for cloud-native architecture | Long-term flexibility and scalability | Highest upfront cost and time |
| Repurchase | Replace with a SaaS equivalent | Commodity workloads (e.g., CRM, email) | Loss of customization |
| Retire | Decommission unused applications | Simplifying the portfolio pre-migration | Requires a full usage audit first |
| Retain | Keep on-premises for now | Compliance, latency, or dependency constraints | Delays full cloud benefit realization |
Note: earlier versions of this guide listed a “Re-training” strategy, which was an error. The correct sixth strategy is Retain, and we’ve added Repurchase here since it’s commonly needed for SaaS-replaceable workloads.
Which Approach Fits Your Situation?
A quick decision framework:
- Need to move fast and cheap, plan to optimize later? → Rehost, using the general 7-step process (Part 2).
- Studying for an exam or need the formal definition? → The seven-step academic model (Part 1) is what’s being asked for.
- Planning an actual enterprise migration? → Use Part 2 for project management, but apply Part 1’s Re-Architect and Testing rigor at the application level.
- Migrating a legacy, tightly-coupled system with minimal risk tolerance? → Start with Retain/Replatform on the components you can’t safely refactor yet, and Rehost the rest as a pilot.
Migration Tools Worth Knowing
- AWS Application Migration Service (MGN): AWS’s current migration tool, which replaced CloudEndure as the primary AWS lift-and-shift service. If you’ve seen CloudEndure referenced in older material, MGN is the tool you actually want today.
- Azure Migrate: Microsoft’s assessment and migration hub for Azure-bound workloads.
- Google Migrate for Compute Engine: Google’s equivalent tool for lift-and-shift migrations into GCP.
What the Data Says About Migration Challenges
According to Flexera’s 2026 State of the Cloud Report, understanding application dependencies and assessing technical feasibility are the top two migration challenges reported across organizations of all sizes, ahead of cost comparison. The same report found hybrid cloud architectures are now used by roughly three-quarters of organizations, and that wasted cloud spend on infrastructure and platform services has risen to around 29% after several years of decline, a reminder that Step 7 (Monitor) isn’t optional overhead: it’s where a lot of migrations quietly lose their ROI.
Case Study: Cloud Integration in a Regulated Enterprise Environment
A transparency note before this section: Liquid Technologies doesn’t yet have a published case study framed specifically as a “cloud migration” engagement. Rather than manufacture one, here’s the closest genuine, verifiable example from the existing portfolio.
Liquid Technologies’ work on ProCheck, an IoT-based operations platform built for Fortune 50 pharmaceutical manufacturers, involved integrating real-time cloud data processing into a highly regulated industrial environment, the same core challenge (dependency mapping, data governance, phased rollout) that Steps 1, 2, and 6 above address. The engagement combined cloud-based data processing, digital twins, and real-time reporting to give plant executives visibility they didn’t have before, and reduced operational delays through better-coordinated, cloud-integrated monitoring.
It isn’t a lift-and-shift migration narrative in the traditional sense, but it’s a real, citable example of Liquid Technologies operating in the same problem space this article covers: regulated, data-heavy environments where getting Assessment and Testing right matters more than moving fast.
