Securing a cloud migration: what to set up before, during and after the move
Migrations create security gaps: temporary access that becomes permanent, test data copied without controls, and old systems left running. Most of the risk can be planned out.
Cloud migrations are busy, deadline-driven projects, and security shortcuts are tempting. Broad permissions get granted to make things work, data is copied to test environments, and firewall rules are opened "temporarily." The NSA and CISA's ten cloud security mitigation strategies, published in March 2024, give a sound list of what to get right. Here they are arranged by migration phase.
Before the move: build the landing zone
| Area | What to set up |
|---|---|
| Responsibility | Write down which controls you own for each service you'll use, per the shared responsibility model |
| Identity | Single sign-on from your identity provider, MFA, no long-lived access keys, separate admin roles |
| Accounts | Separate accounts or subscriptions for production, testing and security tooling |
| Network | Segmented networks, private connections back to on-premises, no default open ports |
| Encryption | Encryption on by default, with a decision on who manages keys |
| Logging | Audit logs on in every account from day one, sent to a central, protected location |
| Guardrails | Policies that block public storage and unapproved regions before any workload arrives |
Defining these as infrastructure as code means every new account starts with the same controls.
During the move
Use dedicated, time-limited credentials for migration tools, and remove them when each wave finishes. Encrypt data in transit, including transfers over the internet. Don't copy production data into test environments without masking sensitive fields. Keep a list of every temporary rule or exception, with an owner and an end date.
After the move
Remove migration accounts and temporary access. Close the firewall exceptions. Check every migrated workload against your guardrail policies with a posture management scan. Turn off and securely wipe the old on-premises systems once the cloud version is verified. Systems left running after a migration are often forgotten, stop being patched and become an easy target.
Finally, update the incident response plan. Investigating an incident in the cloud uses different logs, tools and contacts than on-premises.
What IT teams should do
- Build and test the landing zone controls before the first workload moves.
- Keep a register of temporary access and exceptions, each with an end date.
- Mask sensitive data before it reaches test environments.
- Set a date to decommission each old system and track it to completion.