To secure a cloud migration, inventory what you are moving and the data it holds, settle who is responsible for each layer, build identity, logging and network controls before the first workload moves, then migrate in waves with security checks at each cutover.
What changes when you move to the cloud?
NIST SP 800-144 frames public cloud as displacing data and services from inside the organization to outside it, and lists security and privacy considerations when outsourcing data, applications and infrastructure. The NIST definition in SP 800-145 describes resources that can be rapidly provisioned and released with minimal management effort. Both points matter for migration: you hand some layers to a provider, and you gain the ability to create new things very fast, including mistakes.
What should you do before moving anything?
Inventory. List applications, their dependencies, the data each holds and who depends on them. You cannot protect what is not on the list, and migrations are where forgotten servers and shadow integrations surface.
Classify data. Decide which data may leave which jurisdiction, which needs stronger encryption, and which should not move yet. Some regulators and contracts constrain where data may live, so involve legal and compliance early.
Settle responsibility. For each service you will use, write down which layers the provider operates and which you do. The UK NCSC cloud security principles are a useful checklist of questions for a provider, covering data in transit protection, asset protection and resilience, separation between customers and more.
Choose a pattern per workload. Rehosting a server unchanged carries its old weaknesses with it. Replatforming or rebuilding costs more but lets you remove them. Decide deliberately, and write down the reason.
What do you build first?
Build the foundation before the workloads, because retrofitting is harder.
- Identity. One identity provider, MFA for every human account, short lived credentials for workloads and least privilege roles. MITRE ATT&CK lists Cloud Accounts under Valid Accounts, which is a reminder that stolen credentials are an entry point.
- Logging. Turn on provider audit logs in every account from day one and send them to a store the workload accounts cannot alter.
- Network. Segment environments, default to private addressing and expose services deliberately.
- Guardrails. Policies that block public storage, open management ports and unencrypted volumes by default.
- Secrets and keys. A managed place for them, with ownership assigned.
How do you move safely?
Migrate in waves, with the least critical workloads first so the team learns on low stakes. For each wave, run a short checklist: scan the image or build for known vulnerabilities and secrets, review the configuration against the guardrails, test access paths, confirm logging, and agree a rollback.
During cutover keep the old environment running and read only until you have verified data integrity. Afterward, decommission it. Old environments left running are a classic inventory gap, because nobody patches or watches them.
A constructed example
A company moves a customer portal with a rehost. The inventory shows a batch job on the same server that writes customer exports to a shared folder, which nobody remembered. After the move, that folder maps to a storage bucket whose default access was broader than the old file share. Because the team ran a configuration review as part of the wave checklist, they caught it before cutover, restricted the bucket and added an alert on any public setting.
How do you know it worked?
Measure outcomes, not activity. Check that every account has audit logging, every human identity has MFA, no storage is public without an approved exception, and every workload has an owner. Run a restore test from a backup in the new environment, and run a basic incident drill that starts from the cloud logs.
How to check or apply this
- Build the application and data inventory and classify the data.
- Write the shared responsibility split per service.
- Pick rehost, replatform or rebuild for each workload and record why.
- Stand up identity, logging, network and guardrails first.
- Migrate in waves with a standard security checklist.
- Keep the old environment read only until data is verified, then retire it.
- Test restore and incident response in the new environment.
Quick check
Is lift and shift secure?
It can be, but it carries every existing weakness into the new environment. Add the cloud foundation controls and review configuration before cutover.
What is the most common migration gap?
Leftover systems and data nobody inventoried, in the old environment or in a new default configuration that is broader than the original.
Sources
- NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
- NIST SP 800-145, The NIST Definition of Cloud Computing
- UK NCSC, The cloud security principles
- MITRE ATT&CK T1078, Valid Accounts
Last reviewed: 18 October 2026.
