Your Cloud Migration Security Plan Is Backwards: Start with Compliance, Not the Lift

Why Your Cloud Migration Security Plan Is Backwards

Everyone talks about lift-and-shift first. Fastest, simplest, no code changes—that's the pitch. But if you're moving anything with sensitive data, that's the wrong starting point. The real first step isn't choosing a migration strategy; it's deciding what you're allowed to move and where it can live. That's a compliance decision, not a technical one. And it will shape every other choice you make, from rehost to refactor. So stop asking 'how do I move this?' and start asking 'what does the law and my own risk tolerance say about moving this at all?'

1. Map Your Data's Compliance Requirements Before You Touch a Server

You might be itching to migrate, but before you do anything, you need a full inventory and dependency map—that's non-negotiable. Microsoft's Azure migration framework calls this the Assess stage, and it involves creating a complete inventory of servers, services, and apps, plus estimating cost savings. But here's the kicker: you need to layer compliance on top of that inventory. For every workload, ask: where can this data physically reside? Are there data residency rules? Do we have contractual obligations with customers or partners? AWS explicitly lists data residency compliance as a reason to retain an application on-premises. So if you've got data that must stay in a specific country, you might not be able to lift-and-shift it to just any cloud region. That's a compliance constraint that dictates your migration strategy.

And don't forget the zombie apps. 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. If you have apps like that, the most compliant thing to do might be to retire them—why migrate data you don't need? That's a security win too: less attack surface.

2. Choose Your Strategy Based on Compliance, Not Just Speed

Once you know what you can move, you can pick a strategy. The 6 Rs—Rehost, Replatform, Refactor, Repurchase, Retire, Retain—are your toolbox. But here's the blunt truth: rehosting is fast but it doesn't buy you much in terms of security. You're moving the same vulnerabilities you had on-premises, just into a cloud data center. Replatforming, like moving SQL Server to Amazon RDS, might get you some managed security features. Refactoring, breaking a monolith into microservices, is the most effort but can give you the most control. AWS even notes that for compliance reasons, refactoring might mean splitting a database so some tables stay on-premises. That's a compliance-driven architecture decision right there.

Now, if you're doing a large migration, AWS recommends rehost, replatform, relocate, and retire—not refactor. Why? Because refactoring during a large migration is the most complex strategy to manage across many applications. That's a practical reason, but it might conflict with compliance. If you have a workload that can't be rehosted due to data residency, you might be forced to refactor or retain it. So don't let the strategy tail wag the compliance dog.

3. Use the Shared Responsibility Model to Your Advantage

Here's a security principle that should be tattooed on your brain: the cloud provider is responsible for security of the cloud, but you're responsible for security in the cloud. Microsoft's shared responsibility model is crystal clear: you always retain responsibility for your data—classification, protection, encryption decisions, and compliance—plus your endpoints, accounts, and access management. That means when you migrate, you can't just assume the cloud provider has your back on compliance. You have to configure things like role-based access control, multifactor authentication, and conditional access. If you skip that, you're exposed.

And here's a concrete example: Let's say you're migrating a customer database that includes personal data subject to GDPR. You decide to rehost it to an AWS EC2 instance. Under the shared responsibility model, AWS secures the physical host, but you're responsible for patching the OS, setting up firewalls, and encrypting the data at rest and in transit. If you fail to encrypt, that's on you. So when you're planning your migration, budget time and resources for these security configurations—they're not optional extras.

4. Plan for Security Gaps in Your Migration Path

Even with a solid plan, things go wrong. The most common pitfall? Under-assessing the application portfolio, which leads to missed dependencies. DigitalOcean lists this as a top challenge, along with data security and compatibility issues. You might think you're migrating a standalone app, but it secretly depends on an old database that's still on-premises. Now you've got a hybrid mess, and your security posture is fragmented. That's a recipe for a breach.

Here's what can go wrong: You've done your rehosting, and you think you're done. But you've left a backdoor open—maybe an unpatched server, or a misconfigured storage bucket. In Flexera's 2026 report, security and compliance was the top scaling challenge for 53% of organizations running AI workloads. That's not just about AI; it shows that as you scale, security gets harder. So during your migration, you need to have a clear security checklist: encryption keys managed, access controls tightened, monitoring enabled. Don't wait until after the cutover to think about this.

5. Test, Validate, and Monitor with Compliance in Mind

After you migrate, you're not done. IBM lists test and validate as a distinct step in their six-step workflow. And DigitalOcean's five-phase process includes operate and optimize, where you monitor performance and cost. But you also need to monitor for compliance. Set up alerts for any configuration changes that might violate your compliance requirements. Run regular audits. And if you're using a hybrid cloud—which 73% of organizations do, according to Flexera 2026—you need to ensure that data flowing between on-premises and cloud is encrypted and that the same security policies apply everywhere.

One more thing: cost and security aren't separate. Flexera 2025 found that 84% of organizations struggle to manage cloud spend. If you're overspending, you might be tempted to cut corners on security—like turning off logging to save money. That's a huge mistake. Instead, use FinOps practices to optimize cost, but never at the expense of security. Flexera 2026 notes that wasted cloud spend on IaaS and PaaS rose to 29%, the first increase in five years. That's money you could be spending on better security tools, so get your FinOps in order.

What I'd actually do

Here's my blunt recommendation: Start with a compliance-first assessment. Before you even think about rehost vs. refactor, produce a compliance map of every workload: what data it holds, where it's allowed to live, what encryption is required, and who's accountable. Then, for each workload, choose the simplest migration strategy that meets those compliance requirements. Often, that'll be rehost or replatform, because they're fast and you can bolt on security controls. But if you have a truly sensitive workload, consider refactoring it to use cloud-native security features, even if it takes longer. And for anything that doesn't meet compliance, retain it on-premises. Don't force a migration.

Also, don't forget the power of retiring. That zombie app you've been paying to host? Retire it. It's less data to expose, less to secure, and less to migrate. AWS says you can even identify these by looking at CPU/memory usage below 5% over 90 days. That's a low-hanging fruit for both security and cost.

Finally, build security into every phase. Use the Azure Migrate tool to get a detailed assessment—it's free, and it can do dependency analysis to avoid missing critical connections. And remember: you own the security, not the provider. So set up your access controls, encryption, and monitoring before you flip the switch. That's not just good practice; it's your compliance duty.

Sources

• DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-strategy
• Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework
• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• AWS Prescriptive Guidance (phases) - https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/introduction.html
• Microsoft Learn (security) - https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/