Rehosting First Is a Security Mistake: Why Refactor Must Lead Your Cloud Migration

You’re about to move hundreds of applications to the cloud, and your CISO just asked: “Which migration strategy keeps us most secure?” If your answer is “lift and shift,” you’re making a critical error. I’ve seen too many teams treat rehosting as the default because it’s fast and doesn’t touch code. But speed is the enemy of security in a cloud migration. The only strategy that genuinely protects your organization is refactoring—re-architecting applications to use cloud-native security controls from day one.

Why Lift-and-Shift Is a Security Time Bomb

Rehost, or “lift and shift,” moves applications as-is without code changes. It’s the fastest path to the cloud, and AWS notes it can migrate machines from physical, virtual, or other clouds without long cutover windows. But that speed comes at a cost: you’re carrying every legacy vulnerability, misconfiguration, and compliance gap into a new environment. The shared responsibility model makes this painfully clear. Under AWS’s model, the customer is responsible for the guest OS, security patches, and application software even on IaaS like EC2. If you lift a Windows Server 2008 VM with unpatched IIS, that’s your problem—not AWS’s. Red Hat warns that rehosting without modification can lead to higher long-term costs because you’re not leveraging cloud-native capabilities. I’d argue those costs include security incidents.

The Shared Responsibility Trap

Here’s the counter-argument: “We’ll rehost now and refactor later. We’ll fix security in the cloud.” That sounds pragmatic, but it’s a trap. Under the shared responsibility model, you always own your data, endpoints, accounts, and access management. Azure’s model explicitly states customers retain responsibility for data classification, protection, and encryption decisions. So, when you rehost, you’re not offloading security—you’re just changing where the servers live. You still have to patch, monitor, and manage access. And you’ve lost the familiar on-premises tooling. The cloud provider gives you a secure infrastructure, but it doesn’t secure your application. That’s on you. Rehosting doesn’t reduce your security burden; it relocates it.

Refactor: The Security-First Migration

Refactoring—re-architecting for cloud-native capabilities like microservices, serverless, and containers—is the only strategy that lets you bake security in. AWS calls it the most complex and costly strategy, but also the one that delivers the most benefit. When you refactor, you can break a monolithic app into microservices, each with its own security controls. You can move to managed services where the provider handles patching. You can implement infrastructure as code (IaC), which IBM defines as automating provisioning with configuration files. That means security policies become code, versioned and tested. You can enforce compliance by design, not by accident. Red Hat notes that microservices are easier to build, test, and update—and that agility extends to security updates. You can patch one service without taking down the whole app.

The Real Cost of Refactoring (and Why It’s Worth It)

Let’s get specific. Refactoring is expensive upfront. AWS says it’s the most complex and costly strategy. But consider the alternative: Flexera’s 2025 report found that 84% of organizations struggle to manage cloud spend, and wasted spend on IaaS and PaaS rose to 29% in 2026. That waste often comes from rehosting oversized VMs that you can’t right-size because you didn’t refactor. Now, add the cost of a security breach. The fact base doesn’t give me a dollar figure, but any CISO knows a breach costs millions. Refactoring might double your migration budget, but it can halve your security risk. And it’s not just about cost—it’s about compliance. For regulated industries, refactoring lets you split databases so some tables stay on-premises for compliance reasons, as AWS suggests. That’s impossible with a pure lift-and-shift.

When Rehosting Is Acceptable (and When It’s Not)

I’m not a purist. There are cases where rehosting is the right call. For example, if you have a legacy application that’s end-of-life and slated for retirement, rehosting it for a short period might be fine. AWS defines “zombie applications” as those with CPU and memory usage below 5%—those should be retired, not migrated. For a few applications, rehosting to meet a tight deadline is defensible. But for your critical, revenue-generating workloads, rehosting is a security mistake. You’re carrying forward every known vulnerability without the ability to easily patch. And you’re missing the chance to adopt cloud-native security tools like AWS Config or Azure Policy. If you must rehost, plan to refactor soon after. Do not make lift-and-shift your long-term strategy.

My Recommendation: Refactor or Retire

For every application in your portfolio, ask: “Does this need to exist in the cloud?” If not, retire it. AWS notes that retire applies to applications with no inbound connections in the last 90 days. If yes, ask: “Can we refactor it?” If you can’t refactor because of time or budget, rehost as a temporary measure—but put a refactoring roadmap in place. In their survey, Red Hat found that 38% of organizations plan to rehost, then replatform, then refactor, while 47% plan to skip rehosting and go straight to replatforming. That 47% has the right idea. Replatforming—making minor optimizations like moving to a managed database—is a middle ground. But replatforming doesn’t fix application-level vulnerabilities. Only refactoring does. So, my advice: lead with refactoring for your high-value applications, use replatforming for moderate-risk ones, and rehost only the low-risk, short-lived ones. Your security posture will thank you.

Sources

• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• 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
• Red Hat - https://www.redhat.com/en/blog/how-should-you-modernize-your-applications
• Flexera 2025 - https://www.flexera.com/about-us/press-center/new-flexera-report-finds-84-percent-of-organizations-struggle-to-manage-cloud-spend
• Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/
• IBM - https://www.ibm.com/think/topics/cloud-migration