A cloud migration is the moment your data is most exposed. It is copied, moved, transformed and re-permissioned, often under deadline pressure and often by people who are new to the target platform. Security that is bolted on after the move is always more expensive than security designed into it.
Why the stakes are high
IBM's 2025 Cost of a Data Breach research, conducted by the Ponemon Institute across 600 breached organisations, put the global average cost of a breach at US$4.44 million and the United States average at a record US$10.22 million (IBM newsroom). IBM's 2026 report puts the global average at US$4.99 million, a record high.
Two findings are directly relevant to migrations. Supply-chain and third-party compromise was among the costliest breach types and took the longest to contain. And one in five organisations reported a breach involving shadow AI, often without proper access controls. Migrations involve many third parties and, increasingly, AI tools.
The checklist
Before anything moves
- Classify your data. Know which datasets hold personal data, financial records, health data or intellectual property. Classification drives every control that follows.
- Map regulatory obligations. Data residency and privacy rules such as India's DPDP Act, GDPR and sector rules decide where data may live and who may access it.
- Design identity first. Single sign-on, multi-factor authentication, least-privilege roles and a named owner for every privileged account.
- Build a secure landing zone. Separate accounts or subscriptions per environment, network segmentation, guardrail policies and central logging, all in place before the first workload arrives.
During the migration
- Encrypt in transit and at rest, with keys you control and rotate.
- Use temporary, scoped credentials for migration tools and third parties, and revoke them when each wave completes.
- Log every data transfer and reconcile what left the source with what arrived at the target.
- Keep production data out of test environments, or mask it first.
- Scan infrastructure as code and images before deployment, not after.
After go-live
- Turn on posture management. CSPM or CNAPP tooling checks configurations against benchmarks and alerts on drift, such as a storage bucket made public.
- Monitor around the clock. Feed cloud logs into your SIEM and define who responds, how fast, to which alerts.
- Review access quarterly and remove what is no longer needed.
- Decommission the source securely. Old servers and backups hold the same data; wipe and certify them.
- Govern AI use. Approve which AI tools may touch which data, and monitor for unapproved use.
Common mistakes we see
- Copying on-premise firewall thinking into the cloud. Broad network rules replace identity checks, and one compromised server can reach everything.
- Leaving migration service accounts in place. Accounts created for a migration tool often keep full access for months after the wave is complete.
- Testing with real customer data. Copies of production data in test subscriptions are rarely protected to the same standard.
- Forgetting the source. The old data centre still holds everything until it is wiped, and it no longer gets the attention it used to.
- No owner for alerts. Posture tools raise findings, but without a named team and response times, findings pile up unread.
Who does what
Security in the cloud is shared between you and the provider, and in a migration a partner adds a third party. Agree responsibilities in writing before the first wave.
| Area | Cloud provider | Your organisation | Migration partner |
|---|---|---|---|
| Physical data centres and hardware | Responsible | — | — |
| Identity, roles and access reviews | Provides tools | Owns and approves | Designs and implements |
| Landing zone and guardrails | Provides services | Approves | Builds and documents |
| Data classification | — | Owns | Supports |
| Migration credentials and tools | — | Approves | Uses, scopes and revokes |
| Monitoring and incident response | Platform signals | Owns outcome | Operates, if contracted |
Zero trust in practice
Zero trust means every request is authenticated, authorised and encrypted, wherever it comes from. In a migration, that translates into three habits: never grant network-level trust to a workload because it is "inside", require identity for service-to-service calls, and assume any credential may leak and limit what it can do.
Key takeaways
- Classify data and design identity before building anything.
- Put the secure landing zone in place before the first workload moves.
- Treat migration credentials, tools and partners as temporary and scoped.
- Posture management and 24/7 monitoring are part of the migration, not a later project.