A working cloud migration checklist covers seven stages: objectives and scope, readiness assessment, workload strategy selection, landing zone design, security and compliance, data validation, and post cutover operations. If you're starting today, the first move is simple: assign an owner to run automated discovery and inventory before anything else gets scheduled.
TL;DR:
- Defining clear business objectives, scope, and compliance constraints is essential to prevent scope creep and legal issues during migration.
- Automating discovery combined with manual validation helps accurately map application dependencies and identify high-risk orphaned applications.
- Selecting the correct migration strategy using the 7 R's framework ensures workloads are moved cost-effectively and aligned with compliance needs.
- Building a secure, well-designed landing zone before migration reduces misconfigurations, sets proper security policies, and streamlines compliance.
- Ongoing post-migration governance includes continuous optimization, regular security reviews, and establishing a Cloud Centre of Excellence for consistent resource management.
Table of Contents
- What belongs in your cloud migration plan before anything else moves
- How do you build a reliable cloud readiness assessment?
- Which migration strategy fits each workload?
- What does a secure landing zone look like before migration starts?
- Security and compliance checklist for cloud migration
- How do you validate data before and after migration?
- What does cutover and rollback actually look like in practice?
- How much should cloud cost optimization cost you upfront?
- Who owns cloud governance after migration?
- What happens after the migration is technically done?
- The one-page cloud migration checklist
- Where most cloud migrations quietly go wrong
- How Nexus supports cloud migration and ongoing operations
- Sources
What belongs in your cloud migration plan before anything else moves
Most cloud migration plans fail for a boring reason: nobody wrote down what "done" looks like. Teams jump to picking a cloud provider or a migration tool before they've agreed on what the business is actually trying to buy with all this disruption. That's backwards, and it shows up later as scope creep, budget overruns, and a steering committee arguing about whether the project succeeded.
Start by defining business drivers in language a CFO would accept. "Modernize infrastructure" is not a driver. Microsoft's Cloud Adoption Framework treats this scoping work as a formal prerequisite to the assess-to-migrate sequence, not a nice-to-have planning exercise.
Scope and compliance constraints need equal attention here. Which applications are in scope for this wave? Which data falls under HIPAA, PCI DSS, or contractual data residency clauses that limit which regions or providers you can even consider? Get this wrong and you'll discover mid migration that a workload can't legally move where you planned to put it.
Your objectives section should nail down:
- Specific, numeric KPIs for cost, performance, and availability, tied to a measurement date
- Explicit in scope and out of scope systems, with compliance flags on anything touching regulated data
- A named executive sponsor and a defined approval gate before each migration wave begins
- A rollback threshold: the specific conditions under which a workload gets pulled back to its original environment
Skipping stakeholder mapping is where a surprising number of migrations quietly derail. Legal, finance, and the application owners who actually understand a workload's quirks need a seat at the table before the technical team starts moving things, not after.
How do you build a reliable cloud readiness assessment?
A cloud readiness assessment starts with automated discovery, but automation alone will lie to you. Discovery tools are excellent at finding servers, network flows, and installed software. They're much worse at telling you who owns an application, why it exists, or whether the "unused" database it queries nightly is actually a finance team's quarter end reconciliation job.
Combine the automated scan with manual validation from the people who run these systems day to day. That means interviewing application owners, confirming runtime performance metrics against what monitoring tools report, and flagging anything the discovery tool couldn't classify.
Dependency mapping is the part teams underestimate most. A workload that looks simple in isolation can turn out to share a database with four other applications, none of which appear in the same team's asset list. IBM's guidance on migration strategy stresses that tightly coupled applications and shared databases need to move together or not at all, because splitting them mid migration creates latency and consistency problems that are hard to diagnose after the fact.
A practical sequence for this phase:
- Run automated discovery across compute, storage, network, and licensing.
- Cross reference discovery output against your CMDB or asset register, and reconcile the gaps.
- Interview owners for the top 20% of applications by business criticality.
- Map data flows and dependencies, flagging shared services and hard coded connections.
- Score each workload for migration complexity, criticality, and compliance sensitivity.
- Publish a validated inventory as the single source of truth for wave planning.
Pro Tip: Treat any application with no identifiable owner as high risk by default, not low priority. Orphaned applications are usually orphaned because nobody wants to admit they still depend on them, which makes them the ones most likely to break something unexpected during cutover.
Which migration strategy fits each workload?
Assigning the wrong migration approach to a workload is one of the most expensive mistakes in a cloud transition guide, and it's avoidable with a structured decision process. The industry standard framework here is the 7 R's of cloud migration: retire, retain, rehost, relocate, repurchase, replatform, and refactor.
Each R answers a different business question. Retire removes applications nobody uses; this category can represent a noticeable portion of a typical portfolio once you look honestly. Retain keeps a workload on premises because of latency, licensing, or compliance reasons that don't justify the migration cost. Rehost, commonly called lift and shift, moves a workload as is for speed, usually the fastest path but rarely the cheapest long term because it doesn't touch inefficient architecture. Relocate shifts entire infrastructure blocks, like a VMware environment, without re-architecting individual applications. Repurchase swaps a legacy system for a SaaS equivalent. Replatform makes targeted improvements, like moving a database to a managed service, without a full rebuild. Refactor rebuilds the application to be cloud native, the most expensive and slowest option but the one that unlocks the biggest long-term cost and scalability gains.
Build a simple decision matrix scoring each workload against:
- Technical complexity and how tightly it's coupled to other systems
- Business criticality and tolerance for downtime during the move
- Compliance and data sensitivity requirements
- Available budget and timeline for that specific application
A payroll system tied to a decade old licensing agreement might get retained this cycle. A stateless web front end with no compliance baggage is a rehost candidate you can move in a weekend. The trade-off to watch: rehosting fast feels like progress, but if you rehost everything without a replatform or refactor plan for your most expensive workloads, your cloud cost optimization numbers will disappoint everyone after six months.
What does a secure landing zone look like before migration starts?
A landing zone is the governed environment your workloads land in, and building it after you've started migrating is how misconfigurations become permanent. AWS's Well-Architected Migration Lens groups this work under "mobilize," the phase between assessment and actual migration where you build the foundation that reduces migration risk before a single production workload moves.
Account structure comes first. Decide whether you're running a multi-account or multi-subscription model that separates production, staging, and sandbox environments, and define network topology, including hybrid connectivity if some workloads stay on premises during a phased cloud migration roadmap.
Identity and access management needs to be locked down before, not after, workloads arrive:
- Enforce MFA across every administrative account, no exceptions for "temporary" migration access
- Define service accounts with least-privilege scopes tied to specific automation tasks
- Separate human access from machine access, with different review cadences for each
- Build your IAM policy against the buy versus build decision your team actually has capacity to manage
Logging, monitoring, and tagging need to exist from the first resource you provision, not bolted on after a cost report surprises finance. Tag every resource with owner, cost centre, and environment at creation time. Retrofitting tags across a sprawling environment is a project unto itself.
Pro Tip: Build your tagging taxonomy and enforce it with policy as code before the first workload lands, not as a cleanup task after migration. Untagged resources accumulate fast, and nobody ever volunteers to go back and fix six months of them.
Security and compliance checklist for cloud migration
Cloud security failures are overwhelmingly a customer configuration problem, not a provider failure, according to guidance in the cloud migration checklist literature. That single fact should reframe how your team treats security during migration: it belongs in the landing zone design, not in a review meeting the week before go-live.
Encryption needs to be non-negotiable at rest and in transit, with a defined key management lifecycle: who can rotate keys, how often, and what happens when an employee with key access leaves the organization. Secrets management deserves the same rigour. Hardcoded credentials in migration scripts are a common finding in post-migration security reviews, and they're entirely preventable with a secrets manager from day one.
Network segmentation should follow least-privilege principles, with workloads grouped by sensitivity and trust boundaries enforced between them. Run a cloud security posture management (CSPM) tool continuously, not as a one-time pre-migration scan, because configuration drift starts the moment your first engineer makes a manual change under deadline pressure.
Your compliance checklist should map explicitly to the standards you're bound by:
- SOC 2 controls around access logging, change management, and vendor risk
- HIPAA requirements for encryption, audit trails, and business associate agreements if health data is involved
- PCI DSS segmentation and tokenization requirements for anything touching payment data
- ISO 27001 documentation requirements if your organization holds or is pursuing certification
Cloud misconfiguration remains one of the most consistently cited causes of cloud security incidents, which is exactly why security teams increasingly insist on baking controls into the landing zone template rather than auditing for them after the fact, as reinforced in Pace Wisdom's migration guidance.
Update your incident response playbook before cutover, not after. A cloud native incident response checklist looks different from an on-premises one: your escalation paths, evidence collection methods, and even your legal notification timelines can shift once workloads sit in a shared responsibility model with a cloud provider.
How do you validate data before and after migration?
Data migration is where good plans go wrong quietly. A workload can look perfectly functional after cutover while sitting on subtly corrupted or incomplete data that nobody notices until a monthly report doesn't reconcile.
Pick your migration pattern per dataset rather than defaulting to one approach for everything. Some datasets tolerate a clean cutover during a maintenance window. Others, particularly high-transaction systems, need incremental sync with a final delta migration to minimize downtime. Replication with a cutover point works well for databases where you can afford a brief pause; continuous sync suits systems that can't.
- Document the chosen migration pattern for each dataset, along with the justification.
- Run row counts and checksums on source and destination before declaring a dataset migrated.
- Perform referential integrity checks to confirm relationships between tables survived the move intact.
- Reconcile a sample of records manually against source system reports, not just automated totals.
- Run performance and load tests against latency and throughput targets set in your objectives phase.
- Get sign off from the data owner, not just the migration engineer, before moving to production traffic.
IBM's migration guidance points to running parallel environments during transition as a practical safety net, letting teams compare live performance against the legacy system before fully committing. It costs more to run two environments briefly, but it's cheaper than a rollback discovered three weeks after cutover. Teams handling CMS or content-heavy migrations sometimes lean on purpose-built tooling, similar to how Strapi migration plugins handle structured content transfers, to reduce manual reconciliation work.
What does cutover and rollback actually look like in practice?
Wave sequencing determines how much risk you're carrying at any given moment. Start with a pilot wave of low-risk, low-visibility workloads to validate your process end to end. Follow with a low-risk wave at larger volume, then medium-risk applications, and only move critical, customer-facing systems once your team has run the playbook successfully several times. Rushing straight to your most critical workload because it's the one leadership cares about most is how a promising migration roadmap turns into a public incident.
Your cutover checklist needs specific, written triggers, not judgment calls made under pressure:
- A defined change freeze window with communicated start and end times to all stakeholders
- A documented traffic switch procedure, including DNS changes and load balancer reconfiguration
- Pre-written rollback scripts, tested in a staging environment, not written for the first time during an incident
- Explicit rollback trigger conditions: specific error rates, latency thresholds, or failed health checks that automatically pause the cutover
Hypercare, the stabilization period immediately after cutover, needs named ownership and monitoring thresholds agreed on in advance. IBM's framework for migration success stresses that rollback plans and success metrics must be defined and tested for each workload before production traffic moves, not improvised afterward.
Pro Tip: Assign hypercare ownership to a named individual for each workload, not a shared team inbox. When something breaks at 2 a.m. three days after cutover, "the cloud team" won't respond as fast as a person whose name is on the pager.
How much should cloud cost optimization cost you upfront?
Cloud cost optimization isn't a phase you get to after migration. It's a discipline you build into the plan before the first workload moves, and treating it as an afterthought is how organizations end up with a cloud bill that shocks the CFO in month four.
Budgeting starts with a tagging strategy that ties every resource to a cost centre and owner from creation, enabling chargeback or showback reporting that finance can actually use. Set reserved instance or savings plan commitments only after you understand steady-state usage patterns, and use spot or preemptible capacity for workloads that tolerate interruption, like batch processing or non-production testing environments.
Poorly managed cloud environments routinely carry significant avoidable waste, largely from idle or oversized resources that nobody revisits after initial provisioning, a pattern Microsoft's cost optimization guidance identifies as one of the most durable and preventable sources of overspend, described in detail in its cloud cost optimization principles.
Build these controls into your cloud cost management strategies from day one:
- Automated shutdown schedules for non-production environments outside business hours
- Continuous rightsizing reviews, not a one-time exercise during the migration project
- Budget alerts tied to actual spend thresholds, escalating to named owners, not a shared dashboard nobody checks
- A monthly review cadence pairing finance and engineering to review billing anomalies together
Oracle's guidance on FinOps practice reinforces that this needs to be cross-functional from the start. Visibility into budgets, tagging, and billing reviews before migration produces measurably better outcomes than trying to retrofit governance onto an environment that's already sprawling. If your organization is layering AI or machine learning workloads into the migration scope, the same governance guardrails apply, and teams exploring AI consulting engagements for SME clients often find the cost visibility work is identical to traditional workload governance, just with more unpredictable consumption patterns.
Who owns cloud governance after migration?
A Cloud Centre of Excellence, or CCoE, centralizes governance, cost management, and resource allocation decisions so they don't fragment across a dozen teams making inconsistent choices. Creating one early, according to guidance on cloud centres of excellence, prevents the security and operational sprawl that shows up later as duplicated tools, inconsistent tagging, and nobody quite sure who approves a new production deployment.
Write a CCoE charter that defines its authority explicitly: does it approve architecture decisions, or only recommend them? Build a RACI matrix for cloud operations so that when something breaks, everyone knows who's accountable versus who's just informed.
Your governance and people checklist should include:
- A named CCoE lead with clear escalation authority over architecture and security exceptions
- An upskilling plan with specific certification targets, tied to your primary cloud provider's own credential tracks
- A defined threshold for when to bring in managed services or an external partner rather than stretching internal capacity
- Written policies for resource ownership, release management, and who can grant security exceptions
Change management deserves explicit attention here too. Migrations fail organizationally as often as they fail technically, and a structured approach to change management during digital transformation helps close the gap between "the migration is technically complete" and "the organization actually operates differently now."
What happens after the migration is technically done?
The work doesn't end at cutover. Establish baselines against your original KPIs from the objectives phase and document what actually happened versus what you projected, including honest notes on what took longer or cost more than planned.
Ongoing rightsizing doesn't stop being relevant once migration wraps. Usage patterns shift as applications settle into their new environment, and waste that wasn't visible during the rush of migration often surfaces three or four months later. Patch management and vulnerability scanning need a defined cadence, not an ad hoc response to the next headline vulnerability.
Your post-migration checklist should include:
- A 30-day post-cutover review comparing actual performance and cost against pre-migration baselines
- A recurring FinOps review cycle, monthly at minimum for the first two quarters
- A security review cadence covering CSPM findings, IAM drift, and patch compliance
- A defined trigger point for evaluating managed services if internal capacity can't sustain the operational load
This is also the point to revisit whether workloads you rehosted for speed are now candidates for replatforming or refactoring, since the cost and performance data you've gathered post-migration is far better than anything you had during the original assessment phase.
The one-page cloud migration checklist
- Assess: Complete inventory, dependency mapping, and readiness scoring; sign off by application owners.
- Plan: Set objectives, KPIs, and scope; sign off by executive sponsor.
- Strategy: Assign a 7 R's approach per workload; sign off by architecture lead.
- Landing zone: Build accounts, IAM, networking, logging; sign off by security lead.
- Secure: Complete encryption, CSPM, and compliance mapping; sign off by compliance officer.
- Migrate: Execute wave by wave with tested rollback scripts; sign off by migration lead.
- Verify: Validate data integrity and performance against acceptance criteria.
- Optimize: Review cost and performance at 30, 60, and 90 days post-cutover.
Where most cloud migrations quietly go wrong
The failure pattern Nexus sees most often isn't technical. It's governance arriving after the fact: teams build a landing zone reactively, patching IAM and tagging gaps months into a migration instead of designing them upfront. A CCoE formed before wave one starts consistently outperforms one assembled after the first postmortem.
If your team is weighing an AWS-specific migration path or reviewing governance models for a multi-cloud environment, get that structure settled before migration, not during hypercare.
— Nick - Sr. Executive
How Nexus supports cloud migration and ongoing operations
Most teams reading this checklist are weighing two options: build all this governance and security capacity in-house, or bring in a partner who's already run the playbook. A partner consolidating cloud migration, security, and compliance under one contract can avoid the need to manage separate vendors for architecture, threat monitoring, and audit prep.
An engagement can start with a discovery and readiness assessment, move into a fixed-fee roadmap covering landing zone design and workload sequencing, and continue into managed operations with a single SLA covering migration and 24/7 threat detection afterward. This approach can reduce the coordination overhead of managing separate vendors for cloud architecture, penetration testing, and compliance assessments across SOC 2, HIPAA, or PCI DSS. If your organization is scoping a migration and wants a second set of eyes on your landing zone or security posture before wave one begins, Nexus's IT and cybersecurity services page outlines how to start that conversation.
Sources
- The 7 R's of Cloud Migration | IBM
- Migrate overview - Cloud Adoption Framework | Microsoft Learn
- Migration Lens - AWS Well-Architected Framework
- Cloud cost optimization: principles that still matter | Microsoft Azure Blog