Before a cloud migration cutover, confirm that account structure and identity are set up, networks default to closed, data is encrypted and its location known, logging is on from day one, and a rollback exists. Moving fast is fine. Moving with open storage and root keys is how breaches begin.
Foundations first
- Separate accounts or projects for production, staging and shared tooling. A single account for everything makes every mistake a production mistake.
- Root or owner credentials locked away. Strong multi factor authentication, no access keys on the root identity, and use limited to emergencies.
- Single sign on for humans. No long lived personal keys on laptops.
- Roles for workloads. Applications use attached roles or federated identity, not keys pasted into config files.
- A tagging and ownership rule. Every resource has an owner and an environment tag, so nothing is anonymous when it needs attention.
Network and data
- Default deny. Nothing is publicly reachable unless a ticket says why.
- Storage buckets and databases private by default, with public access blocks enabled at account level where your provider offers them.
- Management ports such as remote shell and database ports are not open to the internet. Use a bastion alternative or session manager.
- Encryption at rest on all data stores, with key ownership decided on purpose.
- Know where data lives. Region choice has legal weight for personal data. Confirm which regions you are allowed to use.
- Clean the data you move. Old test dumps and unused tables are better left behind.
Logging and detection
Turn these on before workloads arrive, not after:
- Cloud control plane audit logs, sent to a separate account that engineers cannot alter.
- Network flow logs for production.
- Alerts for new public resources, new administrator roles and disabled logging.
Cutover day
- Compare the migrated inventory with the source. What did you forget to bring, and what did you bring that you should not have?
- Check that old credentials and firewall rules from the previous environment are not copied across.
- Run a vulnerability and misconfiguration scan on the new environment.
- Keep the old system read only for an agreed period, then decommission and wipe it. Forgotten old systems stay attackable.
- Have a rollback plan with a time limit for deciding.
After the move
Review costs and permissions after two weeks. Temporary broad roles created for migration are the usual leftovers. Remove them.
Safeguard's asset discovery and SBOM scanning can help produce the inventory you compare against at cutover. For provider specific detail, use your provider's own security baseline.
Quick check
Lift and shift or redesign first?
Either can be done securely. Lift and shift moves old weaknesses with it, so schedule hardening work immediately after, with owners.
What is the single most common mistake?
Leaving storage or management access open to the internet during migration and not closing it afterwards.
Last reviewed: 19 October 2026.
