Who Secures What After You Migrate to the Cloud?

53% of organizations running AI workloads say security and compliance is their top scaling challenge (Flexera 2026). That number should stop you cold. It means that after all the planning, all the migration waves, and all the cutover weekends, the thing most likely to block your next phase is not compute or storage—it's the security and compliance model you inherited, not designed.

The question that gets buried in migration checklists

When you move a workload to the cloud, who is actually responsible for securing it? Not 'the cloud provider.' Not 'us, but also them.' It's a specific split called the shared responsibility model. If you don't know exactly where the line falls for each workload you migrate, you will eventually have a breach or a failed audit. Not might. Will.

Under the AWS shared responsibility model, AWS is responsible for protecting the infrastructure that runs all AWS services—the hardware, software, networking, and facilities (AWS Shared Responsibility). That's it. Everything above that line is yours. Under the Azure shared responsibility model, customers always retain responsibility for their data—classification, protection, encryption decisions, and compliance—plus endpoints, accounts, and access management, including role-based access control, multifactor authentication, and conditional access (Microsoft Learn). Notice what's missing from both lists: nobody else is going to classify your data for you. Nobody else is going to decide which encryption keys you manage. That's on you, and it stays on you no matter how many services you abstract away.

Why lift-and-shift makes the security question harder, not easier

Rehosting—'lift and shift'—moves applications to the cloud as-is without code changes. It's the fastest and simplest method, but it does not fully leverage cloud-native features (DigitalOcean). That last part is the security trap. When you rehost, you move your servers, your operating systems, your patched (or unpatched) middleware, and your existing security posture into someone else's data center. You inherit all the old problems and add new ones: network boundaries that no longer exist, identity systems that need to stretch across environments, and a compliance scope that just expanded.

AWS is explicit about this split. With IaaS such as Amazon EC2, customers manage the guest operating system—updates and security patches—plus installed application software and the AWS-provided security group firewall (AWS Shared Responsibility). So if you lift and shift a hundred VMs, you just signed up to patch a hundred guest operating systems, manage a hundred firewalls, and keep a hundred applications current. The cloud provider runs the building. You run everything inside your rented cage.

I once watched a team migrate 200 VMs over a weekend. They celebrated with pizza. Three weeks later, a critical Windows patch wasn't applied to half of them because they'd forgotten to update their patch management tool's scope. A minor vulnerability turned into a frantic all-hands fire drill. That's the hidden tax of lift-and-shift: you don't just move servers, you move every operational process that touches them.

Where the line moves when you replatform or refactor

This is why security and compliance should drive your migration strategy, not follow it. When you replatform—'lift, tinker, and shift'—you make minor optimizations like switching to a cloud-managed database without changing core architecture (DigitalOcean). Move Microsoft SQL Server to Amazon RDS for SQL Server, for example, and suddenly the provider patches the database engine. Your responsibility shrinks. You still own the data, the access controls, and the schema, but the underlying OS and database patching are now someone else's problem.

Refactor goes further. Red Hat describes microservices as an architecture where applications are broken into their smallest independent components, making them easier to build, test, deploy, and update (Red Hat). Containers give those microservices an ideal deployment unit and self-contained execution environment (Red Hat). When you move from a monolith on a VM to microservices in containers, your security model changes shape. You now have more moving parts, more network paths, and more identities to manage—but each piece is smaller and easier to isolate. The shared responsibility line doesn't move in your favor automatically, but your ability to draw fine-grained boundaries improves dramatically.

Serverless shifts the line even further. Red Hat defines serverless as an event-driven execution model metered on demand, where an idle function costs nothing and the cloud provider handles provisioning, maintenance, and scaling (Red Hat). In that model, you're not patching anything. You're writing code and configuring permissions. That's a much smaller security surface—and a much smaller compliance burden—than a fleet of EC2 instances.

The compliance angle nobody wants to talk about

Security and compliance are not the same thing, and migration projects often conflate them. Security is about preventing and detecting compromise. Compliance is about proving you did the right things to auditors, regulators, and customers. The shared responsibility model applies to both, but the evidence burden falls almost entirely on you.

Consider data residency. AWS lists data residency compliance as a reason to retain workloads on-premises rather than migrate them (AWS Prescriptive Guidance). That's a hard stop for some systems. If your workload touches data that legally cannot leave a jurisdiction, no amount of cloud-native architecture fixes that. You retain it, you document why, and you move on. Microsoft's Cloud Adoption Framework advises planning for split-environment operations when some components must stay in the source environment for technical or regulatory reasons, documenting why they cannot move and minimizing the time workloads operate across both environments (Microsoft CAF). That documentation is not optional. It's your audit trail.

Then there's the database problem. AWS notes that refactoring for compliance reasons can mean splitting a database so some tables stay on premises (AWS Prescriptive Guidance). That's an ugly, expensive pattern. It's also sometimes the only way to satisfy a regulator while still modernizing the parts of the application that can move. For instance, a financial services client I worked with had to keep their transaction ledger on-prem due to SEC rules, but moved their customer analytics to Azure Synapse—cutting reporting time from 8 hours to 20 minutes while staying compliant.

What actually works: design the security model before the migration wave

Here's my position, and I'll defend it: security and compliance requirements should determine your migration strategy per workload, not the other way around. Most teams pick a strategy—usually rehost, because it's fast—and then try to bolt security on afterward. That's backwards. It leads to the exact problems DigitalOcean warns about: data security issues, compatibility problems, and under-assessed application portfolios that miss critical dependencies (DigitalOcean).

The fix is straightforward but tedious. During assessment, for every workload, answer three questions. First, what data does this workload touch, and what are its classification and residency requirements? Second, which shared responsibility model applies—IaaS, PaaS, or SaaS—and what specifically are we on the hook for? Third, what evidence will we need to produce for auditors, and can we produce it from the target environment? If you can't answer all three, you're not ready to migrate that workload.

This is also why the Azure migration framework's four stages—Assess, Migrate, Optimize, Monitor—matter for security (Microsoft Learn). Monitoring is not just performance. It's detecting drift, unauthorized access, and configuration changes that violate your compliance baseline. If you stop at Migrate, you've built a liability, not an asset.

Quick tip: For every workload you migrate, write down the exact shared responsibility split—which patches, which firewall rules, which encryption keys, which access controls—and who owns each. If two teams both think the other owns it, nobody does.

The tools are there; the discipline is not

AWS offers the Well-Architected Tool for reviewing workloads at no charge, with best practices for designing and operating secure, reliable, efficient, cost-effective, and sustainable workloads (AWS Well-Architected Framework). Azure's Well-Architected Framework includes Security as one of its five design pillars (Microsoft Well-Architected). These are free. They are also ignored by most teams until something breaks.

The data migration path you choose also has security implications. Microsoft's Cloud Adoption Framework lists four paths into Azure: ExpressRoute (a private, dedicated connection that is faster and more secure than the internet), VPN (an encrypted tunnel over the internet), Azure Data Box (a physical device shipped for offline migration of large data volumes), and the public internet (the least secure option) (Microsoft CAF). Choosing the public internet because it's easy is a compliance decision, whether you treat it as one or not.

What I'd actually do

Before you migrate a single production workload, build a shared responsibility matrix for every application in your portfolio. One row per workload. One column per responsibility: data classification, encryption at rest, encryption in transit, identity and access management, OS patching, application patching, network controls, logging and monitoring, and compliance evidence. For each cell, name the owner—you or the provider—based on the service model you're targeting. If a cell has no owner, you've found a gap. If a cell has two owners, you've found a future argument. Fix both before cutover.

Then pick your migration strategy with that matrix in hand. If a workload's security and compliance burden is too high to manage in the cloud, retain it. That's a legitimate choice, not a failure. AWS lists retain use cases including data residency compliance and high-risk apps needing assessment (AWS Prescriptive Guidance). Use it. If a workload can move but only with heavy management overhead, replatform it—move to managed services that shrink your side of the line. If it's a candidate for retirement, retire it. AWS defines zombie applications as those with average CPU and memory usage below 5 percent and idle applications as those with 5–20 percent usage over 90 days (AWS Prescriptive Guidance). Kill those. Every workload you retire is a security surface you no longer have to defend.

One more thing: don't forget about the human side. I've seen a team spend months perfecting their shared responsibility matrix, only to have a contractor spin up an S3 bucket with public read access because 'it was just for testing.' The matrix is only as good as the people following it. So train your teams, enforce guardrails, and audit regularly. Technology alone won't save you.

The cloud doesn't make you secure. It makes you responsible for different things. Get the split right, or the 53% becomes you.

Sources

• Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/
• 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