What Is Cloud Migration? A Secure Migration Guide

The breach you investigate after a cloud migration usually traces back to the migration itself. An S3 bucket that was a locked-down file share on-prem, copied into the cloud with public read still attached. A service account that held local admin in the data center, rehosted with the same standing credentials and now reachable from the internet. A logging pipeline that worked in the old SIEM and silently stopped collecting the moment the workload moved. None of these are clever attacks. They are configuration and visibility that did not survive the move, and an attacker who found the gap before the security team did.

Cloud migration is the process of moving applications, data, and workloads from on-premises infrastructure (or one cloud) into a cloud provider's environment. Done well, it is a planned change with an inventory, a strategy per workload, and a security baseline that travels with the workload. Done as a deadline-driven lift-and-shift, it copies every insecure default into a larger, more exposed environment and removes the network perimeter that was quietly compensating for them. This guide covers what cloud migration is, the seven strategies practitioners use to move a workload (the 7 Rs), the security risks the move introduces, and a secure migration approach built for the people who have to defend the result.

What is cloud migration?

Cloud migration is moving compute, storage, applications, and data off infrastructure you run yourself and onto infrastructure a provider runs for you: AWS, Azure, Google Cloud, or another platform. The unit that moves is a workload, an application plus its data, dependencies, and the identities and access it needs to run. A migration is rarely one workload. It is a portfolio, dozens to thousands of applications, each of which has to be assessed, assigned a strategy, moved, validated, and cut over.

The reason migration is a security event, not just an infrastructure project, is that the move changes three things at once. It changes where the workload runs, so the controls that protected it (network segmentation, physical access, an on-prem firewall) no longer apply. It changes how the workload is administered, from console-and-cable to an API any holder of a credential can call. And it changes who is responsible for what, because the provider now owns part of the stack and you own the rest. Each of those shifts opens a class of failure that did not exist before the move, which is why a migration plan that does not include a security plan is incomplete.

A migration also rarely happens all at once. For weeks or months a workload runs in both places, the old environment and the new one, while data syncs and traffic shifts. That dual-running window is its own risk surface, and it is one the migration plan has to account for rather than discover.

The migration strategies: the 7 Rs

Practitioners classify each workload by the strategy used to move it. The framing began as Gartner's "5 Rs" in 2011 and became widely known as the AWS "6 Rs" after Stephen Orban's 2016 post. AWS now documents seven, adding "relocate." The current list, per AWS Prescriptive Guidance, is the 7 Rs: rehost, replatform, refactor (or re-architect), repurchase, relocate, retain, and retire. They are not a ranking. Each workload gets the simplest strategy that meets its goals, and the strategy you pick drives the security work the move requires.

Rehost (lift and shift) moves the application to the cloud with no changes. It is the fastest path and the one most migrations lean on at scale, but it is also the one that carries every existing weakness across intact: the same OS version, the same open ports, the same local accounts, the same misconfigurations, now in an environment with a far larger attack surface. Rehost without a hardening pass is how on-prem debt becomes cloud exposure.

Replatform (lift, tinker, and shift) moves the application with some optimization, for example pointing it at a managed database (Amazon RDS) instead of a self-managed one, or upgrading the OS during the move. It is the chance to shed some of the debt rehost would carry, and AWS explicitly notes you can use it to improve your security posture by upgrading to a supported OS version.

Refactor (or re-architect) rewrites the application to use cloud-native services. It is the most expensive and complex strategy, and AWS does not recommend it during a large migration because of that complexity. Done deliberately, it lets you build security in (managed identity, encryption by default, fine-grained IAM) rather than bolt it on.

Repurchase (drop and shop) replaces the application with a different product, usually moving from a self-hosted license to a SaaS equivalent. AWS notes you should assess the new product against your security and compliance requirements before buying, and plan the identity integration (for example, federating it into your directory) as part of the move.

Relocate moves a set of servers or instances to a cloud version of the same platform (for example VMware workloads, or moving an RDS instance to another VPC or account) without changing the architecture or rewriting anything. It is the quickest option when a like-for-like target exists.

Retain keeps a workload where it is, on purpose, because of data-residency requirements, unresolved dependencies, specialized hardware, or a recent upgrade not worth disturbing. Retained workloads still need a plan for how they connect to the migrated ones, often the riskiest seam in a hybrid estate.

Retire decommissions a workload instead of moving it. AWS calls out a specific security benefit: retiring an application running an unsupported OS or unmaintained components removes that risk entirely. The fastest way to secure a workload is sometimes to not migrate it at all.

Migration strategies and their security implications

The strategy is a security decision before it is a cost decision. The table maps each of the 7 Rs to what it does and the security work it demands.

The pattern across the table: the less you change, the more inherited risk you carry, and the more the post-move hardening matters. Rehost and relocate move the workload and its problems together. Replatform, refactor, and repurchase trade effort for the chance to fix things on the way. Retire is the only strategy that reduces the estate.

The security risks a migration introduces

A migration introduces risk in two phases: during the move, while two environments run at once and configuration is in flux, and after it, once the workload lives in an environment with different defaults and a different blast radius. The recurring failures cluster into a handful of patterns.

Misconfiguration in the new environment. The most common cause of cloud incidents is not a provider flaw, it is a customer configuration mistake: a storage bucket left public, a security group open to 0.0.0.0/0, logging never enabled, default encryption skipped. A migration creates a flood of new resources fast, and each one is a chance to get the configuration wrong. Cloud vulnerabilities introduced this way are the single largest category of post-migration exposure.

A larger attack surface. On-prem, a workload often sat behind a network perimeter that hid its weaknesses. In the cloud the management plane is an API reachable from anywhere, every public endpoint is internet-facing by default, and the attack surface is wider than the team is used to reasoning about. Controls that relied on "you have to be inside the network" stop working the moment the network boundary is gone.

Lift-and-shift carrying over insecure configuration. Rehost is fast precisely because it changes nothing, which means it preserves the unpatched OS, the hardcoded credential, the over-permissioned service account, and the disabled host firewall, then exposes them in a more reachable place. The migration did not create the weakness, but it removed the compensating control that was hiding it.

IAM mistakes. Cloud access is identity, not network location. A migration is where over-broad roles, wildcard permissions, long-lived access keys, and human accounts doing machine work get created in bulk under deadline pressure. An over-permissioned identity in the cloud is the equivalent of the over-provisioned account on-prem, except it is reachable through a public API.

Data exposure in transit and at rest. Data moves in bulk during a migration, often over links that were not designed for it, and lands in storage whose encryption defaults differ from the source. Unencrypted replication traffic, snapshots copied to a less protected account, and buckets created without default encryption all expose data the on-prem system kept inside its walls.

Temporary dual-environment gaps. While a workload runs in both places, you have two attack surfaces, two sets of credentials, and sync links between them that are themselves a target. Controls and monitoring are often applied to the destination but not the transitional plumbing, so the migration window is frequently the least-monitored period in a workload's life.

Lost visibility. Detection that worked on-prem does not automatically follow the workload. Agents are not reinstalled, cloud-native logs (CloudTrail, flow logs, control-plane audit logs) are not enabled, and the SIEM is not pointed at the new sources. The workload moves and the security team goes partially blind, which is how a misconfiguration becomes a data breach that nobody saw coming.

The shared responsibility shift

The single most consequential change a migration makes is to who is responsible for security. On-prem, you owned everything: the building, the hardware, the hypervisor, the OS, the application, the data. In the cloud, the provider takes part of that stack and hands you the rest. AWS frames it as security "of" the cloud versus security "in" the cloud: AWS secures the hardware, software, networking, and facilities that run its services; the customer secures what they put on top.

What stays the customer's job is exactly the part migrations get wrong. AWS's model puts the customer in charge of configuring the provided firewall (security groups), applying IAM permissions, choosing and managing encryption, and classifying and protecting their own data. The line also moves with the service: a rehosted EC2 instance leaves you responsible for the guest OS, patching, and everything above it, while a managed service like S3 or a serverless function shifts more of the stack to the provider. A migration usually mixes both, so the responsibility boundary is different for different workloads in the same estate.

The failure mode is assuming the provider covers more than it does. "It is in the cloud, so it is secure" is the sentence that precedes the misconfigured-bucket incident. The provider secures the floor. Everything you build on it is yours, and a migration is the moment to write down, per workload, exactly where the line falls.

A secure migration approach

Securing a migration is not a final gate before cutover. It runs through every phase, from the inventory you build before you move anything to the validation you run before you trust the result. The steps below are the practitioner's spine.

Assess and inventory first. You cannot secure what you have not enumerated. Build a complete inventory of applications, data, dependencies, and identities before assigning strategies, and classify data by sensitivity so the high-value workloads get the most scrutiny. The retire candidates surface here, and every workload you do not move is one you do not have to secure. A formal cloud security assessment at this stage sets the baseline the rest of the migration is measured against.

Threat-model the target, not the source. The cloud changes the threats. Model the new environment: the public management API, the identity-based access, the multi-tenant platform, the dual-running window. Decide what "secure" means for each workload before you move it, not after the first finding.

Least-privilege IAM from the start. Build roles scoped to the specific actions and resources each workload needs, prefer short-lived credentials and roles over long-lived access keys, and never recreate the on-prem standing-admin pattern in the cloud. Identity is the new perimeter; getting it right at migration time is far cheaper than walking back over-broad grants later.

Encrypt in transit and at rest. Encrypt the migration traffic itself, not just the destination. Turn on default encryption for every storage service, manage the keys deliberately, and confirm snapshots and backups inherit it. Cloud providers make at-rest encryption a default you can enable; the failure is leaving it off, not lacking the capability. The specifics of key management and provider options are their own topic in cloud encryption.

Baseline against a known standard. Do not invent a configuration standard under deadline. Apply the CIS Benchmarks for the platform and the provider's well-architected guidance (the AWS Well-Architected Framework's security pillar, or its equivalent) as the baseline every migrated workload must meet. A documented baseline turns "is this configured correctly" from an opinion into a check.

Stand up CSPM from day one. Cloud Security Posture Management continuously scans the environment for misconfiguration and drift against that baseline. Deploy it as resources are created, not after, so the public bucket and the open security group are caught as they appear rather than in a quarterly audit. The migration is exactly when configuration changes fastest and posture management earns its place.

Wire up logging and monitoring before cutover. Enable the cloud-native audit and flow logs (CloudTrail, VPC flow logs, control-plane logs), reinstall endpoint agents on migrated hosts, and point the SIEM at the new sources before the workload goes live, not after the first incident. The migration is the moment to fix the visibility gap, because it is the moment the gap is created.

Validate before you trust the cutover. Before shifting production traffic and decommissioning the source, verify the security state: scan for exposed resources, confirm encryption and logging are on, test the IAM boundaries, and check that detection fires on the new workload. Cut over once the destination is verifiably as secure as the source, then retire the old environment so it stops being an unmonitored second attack surface.

The bottom line

Cloud migration moves applications, data, and workloads off infrastructure you run and onto infrastructure a provider runs, and the way you move each workload (the 7 Rs: rehost, replatform, refactor, repurchase, relocate, retain, retire) decides how much security work the move demands. The less the workload changes, the more inherited risk it carries, which is why rehost needs a hardening pass and retire is the only strategy that shrinks the estate.

The risk is concentrated in two places: the configuration of the new environment, where misconfigured storage, open security groups, over-broad IAM, and missing encryption are the recurring failures, and the visibility gap, where detection does not follow the workload. The shared responsibility model is the frame that explains both: the provider secures the floor, and everything you build on it is yours. A secure migration treats security as a thread through every phase, inventory, threat model, least-privilege IAM, encryption, a documented baseline, posture management, logging, and a validated cutover, rather than a gate at the end. The migration is the cheapest moment to get the configuration right, and the most expensive one to get it wrong.