Cloud Migration Security: A Phase-by-Phase Checklist for SMBs

Short answer: Cloud migration security means treating the move as a security project, not just an infrastructure one. Set up identity, account structure, network boundaries, encryption and logging before the first workload lands, move data over encrypted channels, then sanitise the old environment and keep change records so auditors can follow the migration period.

Related guides:

• HIPAA compliance in cloud-based healthcare
• Challenges in cloud computing
• Best CSPM tools for 2026

Key takeaways

• The cloud provider secures the infrastructure. You still own identities, access policies, configuration and data, in every service model.
• Build the landing zone first: account structure, identity, guardrails and logging exist before any production workload or data moves.
• The biggest security risks of cloud migration are usually self-inflicted: over-permissioned accounts, long-lived access keys, public storage, and logging switched on too late.
• The old environment is part of the migration. Plan data sanitisation and access removal for it, and keep the records.
• SOC 2 and ISO 27001 auditors will look at the migration period. Run it through your normal change management process so the evidence exists.

What changes about security when you move to the cloud?

You stop owning the data centre, but you keep owning almost every decision that makes a workload secure or exposed.

All three major providers describe this split in their own words. AWS calls it "security of the cloud" versus "security in the cloud": AWS protects the infrastructure, and customers are responsible for configuring the services they use, managing user access, encrypting data and setting up monitoring. Microsoft's shared responsibility documentation states that for all cloud deployment types, you own your data and identities, including accounts, access management and the endpoints that connect to your services. Google Cloud's shared responsibilities and shared fate guidance says customers always remain responsible for their access policies and data.

NIST's SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing, sets out what organisations should consider when outsourcing data, applications and infrastructure to a public cloud. It is old but still a useful planning read.

In practice, your on-prem controls such as firewall rules, hardening and backups do not disappear. Some move to the provider and some become settings you own. Write down which is which for each service. If you are spreading workloads across more than one provider, our multi-cloud security guide covers how the split differs between AWS, Azure and Google Cloud.

Phase 1: How should you plan a secure cloud migration?

Inventory what you are moving and decide where each piece of data may live before anyone provisions infrastructure.

1. Inventory workloads and data. List each application, database, file share and integration, who owns it, and what data it holds (customer data, credentials, health data, payment data).
2. Classify data and set rules. Decide which regions are allowed, which data must use customer-managed encryption keys, and what must never leave its current boundary.
3. Run a migration risk assessment. Add the migration to your risk register: data exposure during transfer, downtime, loss of logs, misconfiguration, and dependency on new third parties. Add the provider and any migration contractors to your vendor inventory.
4. Choose the migration pattern per workload. A lift-and-shift VM keeps OS patching on your side; managed services shift more to the provider.
5. Define rollback and success criteria. Security sign-off (logging working, access reviewed, scans clean) should be a cutover gate, not an afterthought.

Phase 2: What does a secure landing zone need before workloads arrive?

A landing zone is the pre-built foundation of accounts, identity, network and guardrails that every workload lands in, and it should be finished before any production data moves.

Identity first. Under the shared responsibility model, identities and access policies are always yours to secure, whatever the service type. AWS's IAM security best practices are a good template for any cloud:

• Use federation through your identity provider so people get temporary credentials, not individual cloud users with passwords.
• Give workloads roles with temporary credentials instead of long-lived access keys. Where a key is unavoidable, rotate it and track when it was last used.
• Require MFA. AWS recommends phishing-resistant MFA such as passkeys and security keys wherever possible.
• Lock away the root or global admin account, protect it with MFA, and do not use it for daily work.
• Grant least privilege, and set guardrails across accounts so no single team can disable logging or open storage to the public.

Account structure. Separate production, non-production, security tooling and log archive into different accounts, subscriptions or projects. A compromised dev account should not reach production data or audit logs.

Network segmentation. Keep databases and internal services in private subnets with no public IPs. Expose only load balancers or gateways.

Encryption and key management. Turn on default encryption at rest for storage and databases, enforce TLS in transit, and decide who can administer keys.

Logging from day one. Enable control-plane audit logs (for example AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) in every account, send them to the separate log archive account, and restrict deletion. If logging starts after migration, you have no record of how the environment was built.

Misconfiguration guardrails. CISA's Cloud Security Technical Reference Architecture treats cloud security posture management as a core part of secure cloud adoption and migration. In practice, that means continuous checks for public buckets, open security groups, unencrypted volumes and disabled logging.

Phase 3: How do you move data without exposing it?

Move data over encrypted channels, with dedicated short-lived migration credentials, and keep a record of every copy you create.

• Encrypt in transit. Use TLS, private connectivity or VPN for replication and transfer jobs.
• Use dedicated migration identities. Create a role just for the migration, scoped to the target buckets or databases, and delete it when the job finishes.
• Avoid stray copies. Staging buckets, database dumps on laptops and temporary file shares are where migrations leak. List each one and set an expiry date.
• Verify integrity. Compare record counts and checksums between source and target so you know nothing was corrupted or missed.
• Handle secrets separately. Do not carry passwords or API keys over in config files. Move them into a secrets manager and rotate them on the way.

Phases 4 and 5: How do you cut over, operate and decommission safely?

Cut over only after a security gate passes, then run an access review and shut the old environment down properly rather than leaving it running "just in case".

Cutover gate. Before switching traffic, confirm: logs are arriving in the archive, vulnerability and configuration scans are clean or risk-accepted, backups have been restored at least once, and DNS and certificate changes are documented.

Operate. In the first weeks, run an access review of everyone and everything with permissions in the new environment, remove migration-only roles and contractor access, and confirm alerts reach a person.

Decommission. The old servers, storage arrays and backups still hold your data. Revoke network paths and accounts to the legacy environment, then sanitise media before disposal or return to the hosting provider. NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, published September 2025 and superseding Rev. 1, is the standard reference for choosing sanitisation methods and documenting them. Keep certificates of sanitisation or destruction from any disposal vendor. With a colo or hosting provider, confirm in writing what happens to drives and backups when the contract ends.

How do you keep SOC 2 and ISO 27001 evidence intact during a migration?

Treat the migration as a series of changes inside your existing control environment, so the evidence auditors expect is created as you go.

A SOC 2 Type 2 report covers a period of time, and if your migration falls inside it, the auditor will want to see how the move was controlled. Change management sits under CC8.1 in the AICPA's 2017 Trust Services Criteria. ISO/IEC 27001:2022 auditors will similarly look for planned changes, updated risk assessments and controls for cloud services and secure disposal.

Evidence worth keeping:

• Change tickets or pull requests for landing zone and infrastructure changes, with approvals
• The updated risk assessment and system description showing the new architecture
• Access review results before and after cutover
• Proof that logging and monitoring were continuous, including any gap between environments
• Decommissioning records and sanitisation certificates for the old environment
• Updated vendor records for the cloud provider and migration contractors

If you run both environments for a while, both are in scope. Say so in your system description. Our guide to SOC 2 evidence for change management goes deeper on what a good change record looks like.

What if you are migrating health data?

Sign a business associate agreement with the cloud provider before any electronic protected health information (ePHI) moves, and only use services the provider lists as covered.

HHS's guidance on HIPAA and cloud computing says a cloud service provider that creates, receives, maintains or transmits ePHI is a business associate, and the covered entity or business associate must enter into a HIPAA-compliant BAA with it. HHS also states that a provider holding only encrypted ePHI without the decryption key is still a business associate. For the full HIPAA picture, see our HIPAA cloud guide.

Cloud migration security checklist and common mistakes

Phase	Security checklist items	Evidence to keep
1. Plan	Data inventory and classification, region rules, migration risk assessment, vendor records updated, BAA or DPA signed where needed	Risk register entry, data map, signed agreements
2. Landing zone	Federated SSO with MFA, no daily root use, no long-lived keys, separate accounts, private networking, default encryption, audit logs to a locked archive, posture checks on	Infrastructure-as-code repo, guardrail settings, logging configuration
3. Migrate data	Encrypted transfer, scoped migration role, list of temporary copies with expiry, integrity checks, secrets rotated	Transfer logs, checksum results, change tickets
4. Cut over	Security gate passed, restore test done, monitoring and alerting confirmed	Cutover approval, scan results, restore test record
5. Operate and decommission	Access review, migration roles removed, legacy access revoked, media sanitised, contracts closed	Access review sign-off, sanitisation certificates

Common mistakes:

• Migrating first, securing later. Workloads land in a default account with broad admin access, and the cleanup never fully happens.
• Copying on-prem service accounts as access keys. Static keys in config files are among the easiest credentials to leak. Scan repositories and config for secrets before you move them.
• Forgotten staging storage. Temporary buckets, sometimes public, outlive the project.
• Late logging. No audit trail for the weeks when the most changes happened.
• Forgetting the old environment. Live VPN tunnels, active admin accounts and unwiped disks at the old host.
• No change records. The migration happened in a chat channel, and the auditor sees a gap in the period.

How SecureSlate helps

SecureSlate keeps cloud migration security visible and auditable:

• Agentless, read-only cloud integrations flag misconfigurations such as missing logging, public storage buckets or overly broad admin permissions in your new accounts.
• Multi-framework control mapping links migration evidence to SOC 2, ISO 27001, HIPAA and other built-in frameworks.
• Access reviews track the post-cutover review.
• Risk management and vendor risk management record migration risks, your cloud provider and contractors.
• Code security and secrets detection flag hard-coded credentials before they follow you into the cloud.
• Audit management keeps change tickets, sanitisation certificates and logs organised for the auditor.

Start your free SecureSlate trial

FAQ

What are the biggest security risks of cloud migration?

In our experience the most common risks are over-permissioned identities, long-lived access keys, publicly exposed storage, logging enabled too late, and data left behind on the old environment. Most sit on the customer side of the shared responsibility model.

Should we build a landing zone if we only have a few workloads?

Yes, scaled to your size. Even two accounts (production and everything else), federated login with MFA, default encryption and a protected audit log give you most of the benefit and are much harder to add later.

Does a cloud migration affect our SOC 2 audit?

It can. If the migration falls within your Type 2 period, the auditor will usually ask how changes were approved, how access was controlled and whether logging was continuous.

How do we sanitise data from the old environment?

Follow NIST SP 800-88 Rev. 2 to choose a method based on media type and data sensitivity, document what was done, and get certificates from any hosting or disposal provider. For cloud storage you are leaving, deleting data and the encryption keys that protect it is a common approach.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.