Most teams believe that once they move to the cloud, security becomes the provider's problem. That's wrong. Under the shared responsibility model, you always own your data, endpoints, and access management, no matter which cloud you pick (Microsoft Learn). I've seen this misconception sink compliance audits and expose data. So let's walk through how we actually handle security and compliance during a cloud migration.
This is for engineers, architects, and security folks who are planning or in the middle of a migration and need to keep auditors happy. We'll go step by step, from assessment to post-migration monitoring.
1. Map your compliance obligations before you touch a server
Before you pick a migration strategy, list every regulation that applies: GDPR, HIPAA, PCI DSS, SOC 2, whatever. Then map each to the cloud services you plan to use. The shared responsibility model is your starting point: with IaaS like Amazon EC2, you manage the guest OS, patches, and security group firewall; with abstracted services like Amazon S3, AWS runs the infrastructure but you still own your data, encryption choices, and IAM permissions (AWS Shared Responsibility). That split dictates your controls.
2. Inventory and classify data during assessment
The assessment phase isn't just about dependencies and cost. You need a full inventory of servers, services, and apps, plus a dependency map (Microsoft Learn). While you're at it, classify data by sensitivity. This step is where you decide what can move and what can't. For example, if you have data residency requirements, you might need to retain certain workloads on-premises (AWS Prescriptive Guidance). Don't skip this—under-assessing the application portfolio leads to missed dependencies and security gaps (DigitalOcean).
3. Choose migration strategies with security in mind
Not all strategies are equal for compliance. Rehost (lift and shift) is fast but doesn't improve security posture; you're just moving the same vulnerable OS to the cloud. Replatform (lift, tinker, and shift) lets you swap in managed services like Amazon RDS, which can offload patching. Refactor (re-architect) gives the most control but is the most complex; AWS even notes that for compliance reasons, refactoring can mean splitting a database so some tables stay on-premises (AWS Prescriptive Guidance). For large migrations, AWS recommends sticking to rehost, replatform, relocate, and retire—refactor is not recommended because it's too complex to manage across many apps.
4. Implement identity and access management from day one
Under the Azure shared responsibility model, customers always retain responsibility for endpoints, accounts, and access management—role-based access control, multifactor authentication, and conditional access (Microsoft Learn). That's non-negotiable. Before you migrate a single workload, set up your IAM policies, enforce MFA, and use least privilege. If you're using AWS, IAM permissions are your job even for abstracted services like S3 (AWS Shared Responsibility). We've seen teams treat IAM as an afterthought and then scramble to lock things down post-migration. Don't be that team.
5. Encrypt data in transit and at rest
Encryption decisions are always the customer's responsibility (Microsoft Learn). For data in transit, use private connections like ExpressRoute or VPN instead of the public internet, which is the least secure option (Microsoft CAF). For data at rest, enable encryption on all storage services—S3, EBS, RDS, whatever. This isn't optional; auditors will ask. And if you're moving large volumes, consider Azure Data Box for offline migration to avoid exposing data over the internet (Microsoft CAF).
6. Test, validate, and monitor continuously
Before cutover, validate that your security controls work in the new environment. Inadequate validation testing is a common pitfall that can derail ROI (DigitalOcean). After migration, monitor for anomalies. The Azure migration framework's Monitor stage is there for a reason. Use cloud-native tools to track access patterns and detect threats. Also, keep an eye on cost—wasted cloud spend on IaaS and PaaS rose to 29% in 2026 (Flexera 2026). Security misconfigurations often lead to unexpected costs, like open S3 buckets that get exploited.
What can go wrong
Here's a real scenario: A team rehosts a legacy app to EC2 without patching the OS. They assume AWS handles security. Six months later, a vulnerability is exploited because the guest OS wasn't updated—that's their responsibility (AWS Shared Responsibility). The breach exposes customer data, and the compliance audit fails. This happens because they didn't map responsibilities early.
What I'd actually do
Start with a security-first assessment: inventory data, classify it, and map compliance requirements to the shared responsibility model. Then, for each workload, pick a migration strategy that improves security—replatform to managed services where possible. Implement IAM and encryption before migration, not after. And continuously monitor post-migration. If you're in a regulated industry, consider retaining sensitive workloads on-premises until you've proven your cloud security controls. Remember, 73% of organizations operate hybrid cloud estates (Flexera 2026), so you're not alone in keeping some things on-prem.
Security and compliance aren't blockers; they're design constraints. Treat them as such from day one, and you'll avoid the audit nightmares that plague so many migrations.
Sources
- Microsoft Learn (security) - https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
- AWS Shared Responsibility - https://aws.amazon.com/compliance/shared-responsibility-model/
- Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework
- Microsoft CAF - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/get-started/migrate
- Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!