Cloud Migration Assessment Checklist (2026): 10 Evidence Gates

A cloud migration assessment is a structured evidence review that answers two questions: what must move, and is each workload ready to move? The assessment should connect architecture, dependencies, performance, security, data, compliance, cost, and operating requirements to one migration decision record.

This 2026 checklist is built for CIOs, cloud program leads, enterprise architects, and migration partners preparing a workload portfolio. It replaces universal savings promises and arbitrary go/no-go thresholds with named evidence, accountable owners, and explicit next actions.

The assessment phase should produce a decision that another team can audit. Microsoft’s Cloud Adoption Framework calls for architecture, performance, security, code, database, dependency, compliance, and reliability information. Google Cloud Migration Center treats discovery and assessment as related activities that inform planning and execution.

What should a cloud migration assessment checklist produce?

A useful cloud migration assessment produces a workload evidence pack, a migration-path decision, a risk register, a cost-model input set, and a wave-readiness record. Each gate should name the evidence collected, the decision it supports, the owner, and the next review date.

Gate	Evidence to collect	Decision signal	Required output
1. Portfolio scope	Application, service, database, environment, business owner, criticality, and lifecycle	The workload has a defined boundary and accountable owner	Workload inventory
2. Architecture and dependencies	Components, network flows, APIs, batch jobs, shared services, SaaS, and external integrations	Components can move together or have a documented connectivity plan	Validated dependency map
3. Performance and capacity	CPU, memory, storage, IOPS, network throughput, concurrency, latency, peaks, and job throughput	Target sizing and performance requirements use representative baselines	Current-state baseline
4. Security and identity	Accounts, service identities, secrets, encryption, firewall rules, access controls, vulnerabilities, and logging	Blockers have owners, mitigations, and an agreed disposition	Security backlog and gate status
5. Data, compliance, and reliability	Data classification, residency, retention, encryption, regulatory obligations, SLA, RPO, and RTO	Target regions and services can satisfy the workload’s obligations	Requirements register
6. Application and database fit	OS, runtime, middleware, framework, database engine/version, licensing, shared databases, and compatibility findings	Unsupported components have a remediation or alternative path	Compatibility register
7. Migration path	Business value, technical constraints, modernization effort, and the 7 Rs: rehost, replatform, refactor, rearchitect, repurchase, retire, retain	The selected path is justified by evidence, not habit	Portfolio decision record
8. Cost and scenarios	Current baseline, licenses, storage, data transfer, backup, monitoring, support, labor, modernization, and dual-run assumptions	The business case survives documented what-if scenarios	TCO model inputs
9. Wave readiness	Dependency grouping, landing-zone prerequisites, runbooks, testing, rollback, monitoring, owners, and acceptance criteria	The workload can enter a wave without unresolved critical unknowns	Wave entry record
10. Go/no-go decision	Blockers, mitigations, confidence, approver, decision status, and next review date	The decision is ready, conditional, or on hold with a reason	Signed decision record

Use the table as a working artifact. Link each row to the evidence location rather than marking a gate complete because a meeting occurred.

1. What belongs in the workload inventory?

The workload inventory defines the assessment boundary. Record each application, service, database, environment, owner, business function, criticality, lifecycle state, and upstream or downstream dependency before choosing a migration path.

Capture these fields for every workload:

• Identity: application name, service name, business capability, environment, owner, technical lead, and repository or CMDB reference.
• Business context: users, revenue or operational role, peak periods, criticality, service-level agreement, and maintenance windows.
• Technology: operating system, runtime, framework, middleware, server or VM type, storage, database engine and version, licensing model, and hosting location.
• Data: data owner, classification, residency, retention, encryption, volume, growth rate, and inbound or outbound data flows.
• Operations: monitoring, alerting, backup, recovery, deployment, support team, incident history, and current runbooks.
• Evidence quality: source of each field, collection date, confidence, and the person responsible for validating it.

An inventory row without an owner is an assessment gap. An inventory row without a collection date is a freshness risk. Keep those gaps visible instead of converting them into assumptions.

2. How do you map architecture and dependencies?

Dependency mapping shows which components must move together, which can remain connected to the source environment, and which integrations need a migration plan. Automated discovery reduces manual work, but workload owners must validate undocumented or informal connections.

Microsoft’s workload assessment guidance recommends combining automated tools with architecture documentation and subject-matter-expert review. Apply that sequence:

1. Discover components, network connections, APIs, queues, batch jobs, shared databases, identity providers, SaaS dependencies, and partner integrations.
2. Separate observed runtime connections from documented but unobserved dependencies. Both belong in the map, with a confidence label.
3. Ask application and service owners to confirm the map and explain exceptions, manual processes, and low-frequency jobs.
4. Store the dependency map in a central repository that records the evidence source, collection date, owner, and change history.
5. Group workloads into migration waves only after the map identifies the components that must move together or the temporary connectivity that will keep them working.

Do not describe an AI-generated map as ground truth. A tool can miss an undocumented dependency; a validated map is the assessment artifact.

3. Which performance and capacity baselines are required?

Performance baselines should capture the workload’s resource use and business behavior across representative operating conditions. At minimum, record CPU, memory, disk I/O and IOPS, network throughput, concurrency, response time, job throughput, and peak periods.

For each metric, record:

• the measurement source and collection window;
• average, peak, and percentile values where they support the sizing decision;
• scheduled batch, seasonal, month-end, and other non-daily behavior;
• the current service-level objective or user-facing requirement;
• the proposed target capacity and the assumption behind it; and
• the post-migration metric that will prove whether the target was met.

There is no defensible universal observation window. A four-week period may miss a quarterly job, while a shorter window may be sufficient for a stable stateless service. Choose the window that covers the workload’s meaningful operating patterns and state what remains unobserved.

4. What security and identity evidence must pass review?

Security evidence should show how the workload authenticates, authorizes, encrypts, logs, and exposes services. The assessment should identify blockers and remediation owners; it should not pretend that a single time threshold makes an application safe to migrate.

Document:

• human users, service accounts, API keys, workload identities, privileged roles, and trust relationships;
• secrets in repositories, configuration stores, images, and deployment pipelines;
• encryption at rest and in transit, key ownership, certificate rotation, and data-protection requirements;
• firewalls, security groups, network access controls, ingress, egress, and administrative paths;
• vulnerability, patch, end-of-support, and configuration findings;
• logging, audit trails, detection coverage, incident response, and evidence retention; and
• each blocker, severity, owner, remediation, exception approver, due date, and residual risk.

Use the cloud migration risk assessment framework when the project needs a scored heatmap or detailed mitigation plan. This page’s job is to make sure the evidence and handoff exist.

5. How should data, compliance, and reliability shape the assessment?

Data classification, residency, retention, regulatory obligations, service levels, RPO, and RTO constrain the target architecture. Treat those requirements as design inputs that determine regions, services, replication, backup, access controls, and migration sequencing.

For every data store, record:

1. the data owner, business purpose, classification, residency, retention, and deletion requirement;
2. the database or storage engine, version, hosting model, size, growth, backup, and replication pattern;
3. inbound and outbound consumers, including applications, APIs, reporting, analytics, and batch jobs;
4. applicable standards or regulations, such as HIPAA, FedRAMP, ISO 27001, SOX, or internal policy;
5. availability, data-loss, recovery-time, latency, and maintenance requirements; and
6. the target region, service, control mapping, exception process, and validation test.

Keep the compliance requirement separate from the product choice. “Use service X” is an implementation decision; “data must remain in region Y and recover within Z” is an assessment requirement.

6. How do you test application and database compatibility?

Compatibility assessment compares the current operating system, runtime, framework, middleware, application code, database, and licenses with the proposed target. The output is a remediation plan or an explicit alternative, not a green label without supporting evidence.

Check:

• operating-system, runtime, framework, SDK, middleware, and database versions against target support policies;
• application code dependencies, native libraries, file-system assumptions, scheduled tasks, and deployment artifacts;
• database engine, version, extensions, replication, shared-instance usage, inbound and outbound flows, and downtime constraints;
• commercial software, support contracts, license mobility, and replacement options;
• unsupported or deprecated components, required upgrades, code changes, data conversions, and test environments; and
• the remediation owner, effort estimate, dependency, acceptance test, and fallback path for each finding.

Microsoft’s current assessment guidance separates application-code and database assessment from infrastructure discovery. Use the same separation in your evidence pack so a compatible VM does not hide an incompatible application or database.

7. How should the 7 Rs become a migration decision?

The 7 Rs turn assessment evidence into a migration path: rehost, replatform, refactor, rearchitect, repurchase, retire, or retain. Choose the path per workload, document the reason, and record the evidence that would change the decision.

Path	Use it when the evidence shows	Record before approval
Rehost	The workload can move with limited code change and the immediate goal is relocation	Target capacity, dependency plan, licensing, rollback, and later optimization work
Replatform	A managed service or runtime change removes operational work without a full redesign	Compatibility, data movement, service limits, and acceptance tests
Refactor	Code changes improve portability, operations, or delivery without changing the whole architecture	Code scope, test coverage, team capacity, and release plan
Rearchitect	The current design prevents the required scale, reliability, security, or operating model	Target architecture, dependency changes, sequencing, and transition state
Repurchase	A commercial or SaaS product meets the business need better than migration	Data export/import, integration, contract, identity, and exit requirements
Retire	The workload has no continuing business or technical justification	Owner approval, data-retention decision, and decommission plan
Retain	Moving now adds more risk or cost than value	Reason to defer, review date, source-environment support plan, and trigger to revisit

The Cloud Migration CIO’s Playbook explains the broader 7Rs sequence. This checklist supplies the evidence that lets a portfolio team apply it consistently.

8. How should the cost and TCO model be built?

A migration TCO model compares the current state with one or more target scenarios using explicit assumptions. It should include infrastructure, licenses, storage, data transfer, backup, monitoring, support, labor, modernization, migration tooling, and any period when source and target environments run together.

Build the model in five steps:

1. Establish the current baseline with a source, date, unit, and owner for each cost.
2. Separate one-time migration costs from recurring operating costs.
3. Model at least one target scenario and identify the assumptions that drive the result.
4. Stress-test the variables most likely to change the decision, such as utilization, data growth, transfer volume, licensing, support, and dual-run duration.
5. Record the confidence of each input and the evidence required to replace an estimate with a measured value.

Google Cloud Migration Center’s assessment workflow groups discovered assets, compares migration scenarios, and generates a TCO report. The method generalizes across providers: a TCO result is only as credible as its inventory, utilization, dependency, and assumption records.

Use the cloud migration cost calculator guide for detailed cost-model inputs and formulas. Do not replace that work with a blanket claim that a migration must save a fixed percentage.

9. What makes a workload ready for a migration wave?

A workload is wave-ready when its scope, dependencies, target path, security and compliance requirements, operating model, test plan, rollback, owner, and cost assumptions are documented well enough for the team to execute and measure the move.

Before adding a workload to a wave, verify:

• every dependency is in the same wave or has a tested connectivity plan;
• the landing zone has the required identity, network, logging, policy, backup, and access controls;
• performance, availability, RPO, RTO, and security acceptance criteria are measurable;
• data movement, reconciliation, cutover, rollback, and support procedures are tested;
• the workload owner, technical lead, approver, and incident path are named;
• unresolved risks have a mitigation, owner, due date, and explicit approval to proceed; and
• the wave has a review point after testing and after production cutover.

Google Cloud’s migration planning guidance says discovery and assessment should continue as data improves and should inform dependency mapping, risk work, and migration-wave planning. Treat the evidence pack as a maintained record, not a one-time questionnaire.

10. What should the final go/no-go decision record contain?

The final decision record should state the workload scope, evidence date, selected migration path, blockers, mitigations, cost assumptions, wave, approver, and next review. A clear record can be ready, conditional, or on hold without hiding uncertainty.

Status	Use it when	Minimum record
Ready	Required evidence meets the team’s agreed entry criteria and no unresolved blocker prevents the planned move	Evidence links, path, wave, acceptance tests, rollback, owner, and approver
Conditional	Known gaps have bounded mitigations, owners, dates, and an explicit risk acceptance	Gap, impact, mitigation, trigger, approver, and condition for continuing
Hold	Missing or contradictory evidence could change the path, cost, security posture, compliance fit, or wave sequence	Unknown, evidence needed, owner, next review date, and decision not to proceed

Record confidence for the decision, not just a colored status. A “ready” decision with an unvalidated dependency map is a low-confidence decision and should be treated accordingly.

Which migration assessment tools are current in 2026?

Assessment tools automate collection, dependency analysis, compatibility checks, scenario modeling, or migration tracking; they do not replace owner validation or the final decision record. Choose a tool by the workload types, environments, data-access constraints, and evidence fields it can support.

Environment or provider	Current starting point	Useful assessment output
Microsoft Azure	Azure Migrate and the Azure Cloud Adoption Framework	Discovery, dependency analysis, performance, compatibility, code, database, and reliability inputs
Google Cloud	Google Cloud Migration Center	Discovery, infrastructure assessment, dependency grouping, scenario comparison, TCO, and migration planning
AWS	AWS Transform for new projects	Current migration and modernization workflows, automation, tracking, and recommendations

AWS Migration Hub stopped accepting new customers on November 7, 2025. AWS says existing customers can complete in-flight projects, while AWS Transform is the recommended path for new migration and modernization work; see the AWS Migration Hub availability notice before naming a tool in a new assessment.

What should you do after the assessment?

Turn the decision record into a sequenced plan with owners, evidence links, and review dates. Link detailed work to the page that owns it so the assessment hands off cleanly instead of becoming another generic recommendation:

1. Use the Cloud Migration CIO’s Playbook for the portfolio-wide strategy and wave sequence.
2. Use the cloud migration risk assessment framework for scored risks and mitigation.
3. Use the cloud migration cost calculator guide for detailed TCO inputs and scenarios.
4. Use cloud migration best practices for broader execution practices.
5. If external support is required, use cloud migration consulting services to scope and compare a partner engagement.

The assessment is complete when the next team can trace every major migration decision to evidence, an owner, an assumption, or an explicitly accepted risk.