Cloud migrations rarely fail on the target design; they fail on the checks nobody signed off: an unscoped migration account, a firewall rule meant to last a weekend, a service account copied across with its old password, or an on-premises server left running after cutover. This template is a tickable cloud migration security checklist covering identity, landing zone readiness, data transfer, logging, cutover and decommissioning, in the order a migration actually runs. Each check has an ID you can reference in change records and a column for evidence, so the same sheet works as a go/no-go gate per migration wave. It is written for migration leads, cloud security engineers and change approvers. For why each control matters, read the Cloud Migration Security guide; this page verifies. For who owns which control after the move, see the Shared Responsibility Models Guide.
How to use this template
Replace text in square brackets, such as [Organisation], [wave name], [landing zone] and [SIEM], with your own details.
Run sections 2 to 4 once per programme and sections 5 to 9 once per migration wave. Section 10 is the sign-off record for each wave.
Mark each line Pass, Fail, Partial or Not applicable, name the person who checked it and attach evidence (policy export, screenshot, ticket, log query result).
Any Fail on a check marked (gate) blocks cutover for that wave until it is fixed or a named risk owner accepts it in writing.
The checklist is provider-neutral. Map each check to your provider's own setting names: AWS, Google Cloud and Microsoft Azure all publish migration frameworks and landing zone guidance, listed in the references.
1. Migration record
Field
Entry
Programme and wave
[Programme name], [wave name and number]
Workloads in this wave and migration strategy per workload
Known weaknesses carried by rehosted workloads (unsupported operating systems, local admin accounts, missing patches) are listed with a fix-after-move date or accepted by a named owner.
[ ]
2.6
The provider's assurance has been reviewed against the NCSC cloud security principles, with attention to principle 9 (secure user management), 10 (identity and authentication), 12 (secure service administration) and 13 (audit information and alerting for customers).
[ ]
2.7
Discovery and assessment appliances run with read-only accounts where the tool allows it, those accounts are recorded, and each has a removal date.
[ ]
3. Pre-migration: landing zone readiness
None of these should be "to follow". Workloads that land before the guardrails become permanent exceptions. See the Cloud Landing Zone Security Guide.
ID
Check
Result and evidence
3.1 (gate)
Account, subscription or project structure separates production, non-production, security tooling and log archive.
[ ]
3.2 (gate)
Organisation-level guardrail policies are active: allowed regions, no public storage by default, required encryption, and protection against disabling logging.
[ ]
3.3 (gate)
Audit logging for control plane activity is on in every target account and region and ships to the log archive and [SIEM].
Human administrators sign in through the corporate identity provider with phishing-resistant MFA; no long-lived local cloud users exist for people.
[ ]
4.2 (gate)
The cloud root or global administrator accounts are secured, have no access keys, and are reserved for break-glass use. See the Break-Glass Account Guide.
[ ]
4.3
Dedicated migration identities exist for replication and transfer tools, scoped to the target accounts and resources they need, each with an owner and an expiry date.
[ ]
4.4
Workloads will use the platform's workload identity (instance roles, managed identities, service accounts with short-lived tokens) instead of copied passwords or static keys.
[ ]
4.5
Hybrid identity synchronisation accounts are scoped, monitored and protected as privileged identities.
[ ]
4.6
A role model exists for the target (who can deploy, who can change network, who can read data), approved by the security owner. See the Cloud IAM Review Checklist.
[ ]
5. During migration: data transfer
ID
Check
Result and evidence
5.1 (gate)
The transfer path matches the data classification: private connection, VPN or offline transfer device for sensitive data; public internet only for non-sensitive data.
[ ]
5.2
Data is encrypted in transit (TLS 1.2 or later, or an encrypted tunnel) and at rest in staging storage.
[ ]
5.3
Staging buckets, shares and disks are private, access-logged and listed for deletion after cutover.
[ ]
5.4
Integrity is verified after transfer (checksums, row counts or tool verification reports) and results are attached.
[ ]
5.5
Temporary firewall rules and network paths opened for replication each carry a ticket reference and an expiry date.
[ ]
5.6
Test environments do not receive production data unless masked or approved for the same classification.
[ ]
6. During migration: workload hardening
ID
Check
Result and evidence
6.1
Migrated images are patched and scanned before production traffic; findings above [High] are fixed or accepted.
[ ]
6.2
Local administrator and default accounts carried over from the source are removed or managed by a privileged access tool.
[ ]
6.3 (gate)
Secrets from check 2.3 are in the secrets manager and removed from files and environment variables. See the Secrets Management Guide.
[ ]
6.4
Roles attached to workloads grant only the permissions the application uses, with no wildcard access to storage or identity services.
[ ]
6.5
Instance metadata services are configured to require session tokens where the provider offers the option.
[ ]
6.6
Security groups and network rules expose only the ports in the dependency map from check 2.1.
[ ]
7. Cutover and rollback
ID
Check
Result and evidence
7.1 (gate)
Go/no-go criteria include security conditions (no open gate failures, logging verified, detection alerts flowing) alongside performance ones.
[ ]
7.2 (gate)
The rollback plan is written, tested in a non-production rehearsal and names the point of no return.
[ ]
7.3
Logs from the migrated workload (operating system, application, platform) are confirmed arriving in [SIEM] before cutover, not after.
[ ]
7.4
DNS changes, certificates and load balancer listeners are reviewed so that no old endpoint keeps serving traffic unnoticed.
[ ]
7.5
The security operations team knows the cutover window and has the expected change list to separate planned activity from suspicious activity.
[ ]
8. Post-migration: validation
ID
Check
Result and evidence
8.1
Posture management shows no new critical findings for the migrated resources, or each one is ticketed.
[ ]
8.2
Access reviews confirm only the role model from check 4.6 is in use; temporary elevated access granted during cutover is removed.
[ ]
8.3
Detection use cases (unusual sign-ins, key creation, logging changes, public exposure) have fired in testing for the new accounts. See the Cloud Logging and Audit Trail Guide.
[ ]
8.4
Backup jobs for the migrated workload have run and one restore has been tested.
[ ]
8.5
Incident response runbooks are updated with cloud log sources, contacts and the provider's support route.
[ ]
9. Post-migration: decommissioning
ID
Check
Result and evidence
9.1 (gate)
Migration identities from check 4.3 and discovery accounts from check 2.7 are disabled and deleted; their keys are revoked.
[ ]
9.2
Replication agents and migration appliances are uninstalled and their accounts on source systems removed.
[ ]
9.3
Temporary firewall rules, VPN tunnels and network paths from check 5.5 are closed.
[ ]
9.4
Staging storage from check 5.3 is deleted and the deletion is logged.
[ ]
9.5
Source servers are shut down after the agreed retention period, and storage media are sanitised using a method chosen under NIST SP 800-88 Rev. 2 or destroyed, with a certificate kept.
[ ]
9.6
Old DNS records, service accounts in the on-premises directory and monitoring entries for retired servers are removed, and the asset inventory is updated.
[ ]
10. Findings and sign-off
Field
Entry
Gate checks passed
[n of n]
Open findings and risk owners
[ID]: [owner], [due date]
Accepted risks
[ID]: [reason], [accepted by], [review date]
Decision
[Go / Go with conditions / No go]
Security owner and change approver sign-off
[Name, date], [Name, date]
Implementation guidance
Start with the landing zone. Run sections 3 and 4 before the first pilot wave. They are programme-level checks and get cheaper to pass the earlier they run.
Pilot on a low-risk workload. Choose an application with internal data and few dependencies, run every section, and adjust the checklist to your provider's setting names before the main waves.
Make expiry dates real. Migration identities, staging storage and temporary rules are the residue most often left behind. Put each expiry in a ticket with an owner so section 9 has a list to work from.
Size to the programme. A small organisation moving a few servers can run the whole sheet by hand in one session per wave. A large programme should automate checks 3.2, 3.3, 6.4 and 8.1 through policy as code and posture findings, and review only exceptions.
Know how to roll back. Keep the source environment intact, with its access controls, until the rollback deadline in section 1 has passed. Decommission only after sign-off in section 10.
Measure. Track gate checks passed at first attempt per wave, migration identities still active after their expiry date (target zero), temporary firewall rules past expiry (target zero), days from cutover to source decommissioning, and workloads with logs confirmed in [SIEM] before cutover (target all).
Strategy and the checks that matter most
Strategy
Where to focus
Retire
9.5 and 9.6: archive data securely and sanitise; do not just switch off
Retain
5.5 and 9.3: the hybrid paths stay open longer, so give them owners and reviews
Rehost and relocate
2.5, 6.1 to 6.3: old weaknesses and secrets move with the workload
Replatform and refactor
4.4 and 6.4: adopt workload identity and least-privilege roles while code is changing
Repurchase (SaaS)
2.6, 4.1 and 9.6: provider assurance, single sign-on and removal of the old system's accounts
Framework mapping
Checklist section
NIST SP 800-53 Rev. 5
NIST CSF 2.0
2. Discovery and risk
CM-8, SA-9
ID.AM-01, ID.AM-08
4 and 6. Identity and hardening
AC-2, AC-6, IA-5
PR.AA-05
3 and 7. Logging and readiness
AU-2
PR.PS-04
5. Data transfer
SC-8, SC-28
PR.DS-01, PR.DS-02
7 and 8. Rollback and recovery
CP-10
RC.RP-03
9. Decommissioning
MP-6
ID.AM-08
Attack techniques these checks reduce include MITRE ATT&CK T1078.004 Cloud Accounts, T1552.001 Credentials In Files and T1530 Data from Cloud Storage.
NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security.
nhimg.org
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.