Who Secures What After a Cloud Migration? The Shared Responsibility Truth

What security am I responsible for after moving to the cloud? If you've typed that into a search bar, you're not alone. I get this question constantly, and the answer is almost always the same: it depends on what you moved and how you moved it. But the one thing that doesn't change is this—you never outsource accountability for your data. I'll say it plainly: if you think your cloud provider is now your security team, you're setting yourself up for a breach. Let's bust that myth and a few others.

Doesn't the cloud provider handle security for me?

No. This is the misconception that gets people fired. Under the AWS shared responsibility model, AWS secures the infrastructure that runs all AWS services—the hardware, software, networking, and facilities. But your responsibility is determined by the services you pick (AWS Shared Responsibility). That means if you lift-and-shift a virtual machine, you're patching the guest OS, managing the firewall, and securing the application. If you use a managed database, the provider handles more, but you still own your data, encryption choices, and access permissions. The Azure model says the same: you always retain responsibility for data classification, protection, encryption, endpoints, accounts, and access management (Microsoft Learn). So no, the provider doesn't do it all. You do.

Is rehosting or replatforming more secure?

Neither is inherently more secure—but they shift where the work lives. Rehosting, or lift-and-shift, moves applications as-is with no code changes. It's the fastest and simplest, but rehosted apps aren't cloud-native and are harder to scale (DigitalOcean). On the security side, that means you keep patching the OS and managing everything above the hypervisor. Replatforming makes minor optimizations, like moving to a cloud-managed database, without changing core architecture (DigitalOcean). That can offload some patching to the provider, but it also introduces new configuration surfaces you must lock down. I've seen teams assume replatforming automatically improves security. It doesn't. It changes the checklist.

But won't moving to the cloud improve my compliance posture?

It can—if you plan for it. Compliance isn't a feature you enable; it's a continuous process. Under the shared responsibility model, data residency and regulatory requirements often force you to keep certain workloads on-premises. That's why the Retain strategy exists: it keeps applications on-premises for compliance, technical, or timing reasons (DigitalOcean). AWS specifically calls out data residency compliance as a retain use case (AWS Prescriptive Guidance). So if you're in a regulated industry, you might end up with a hybrid estate. In fact, 73% of organizations already operate hybrid cloud estates, up 3 percentage points year over year (Flexera 2026). The cloud doesn't erase compliance; it redistributes it.

What about data security during the migration itself?

This is where I see the most hand-waving. Common migration challenges include data security, compatibility with existing infrastructure, and under-assessing the application portfolio, which leads to missed dependencies (DigitalOcean). The assessment phase should map every dependency and estimate costs, but too many teams treat it as a paperwork exercise. Microsoft's Cloud Adoption Framework recommends discovering all dependencies first and grouping workloads into migration waves to avoid service disruptions (Microsoft CAF). If you skip that, you'll move something that talks to a database you forgot about, and you'll either break it or expose it. I've watched a financial services client nearly migrate a customer database without its encryption keys because no one mapped the dependency. That's not a cloud problem; that's a planning problem.

How do I handle access management after migration?

You treat it as your job, not the provider's. 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 doesn't change just because you're in the cloud. If anything, it gets more complex because your identities might span on-premises and multiple clouds. The AWS Well-Architected Framework provides best practices for designing secure workloads, and AWS offers a free tool to review them (AWS Well-Architected Framework). Use it. I'd rather you spend a week tightening IAM policies than explain to a regulator why a former employee still had production access six months after leaving.

Should I refactor for better security?

Refactoring—re-architecting to use cloud-native capabilities like microservices, serverless, or containers—delivers the most benefit but requires the most effort (DigitalOcean). It can improve security by breaking a monolith into smaller, independently deployable components. Red Hat describes microservices as easier to build, test, deploy, and update (Red Hat). But AWS warns that refactoring is the most complex and costly strategy, and for large migrations, it's not recommended because it modernizes applications during the migration (AWS Prescriptive Guidance). So don't refactor just for security. Refactor when you need the agility or scalability, and treat security as a design requirement, not an afterthought. If you're migrating hundreds of apps, rehost or replatform first, then refactor the ones that matter.

My take: the cloud doesn't absolve you of security and compliance—it makes them your explicit responsibility. The shared responsibility model is not a slogan; it's a contract. You own your data, your identities, and your configurations, no matter how many services you consume. Plan for it during assessment, enforce it with IAM and encryption, and keep a FinOps-like discipline around security reviews. If you do that, the cloud can be more secure than your data center. If you don't, you've just outsourced your infrastructure and kept all the risk.

Sources

• AWS Shared Responsibility - https://aws.amazon.com/compliance/shared-responsibility-model/
• Microsoft Learn (security) - https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-strategy
• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• 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/