To migrate to the cloud safely, pick a migration strategy for each application, write down which security controls you own and which the provider owns, move in small phases, and monitor configuration from the first day. Most migration incidents come from unclear ownership and unmonitored settings, not from the cloud itself.
What are the migration strategies?
The CISA Cloud Security Technical Reference Architecture (version 2) lists five strategies:
- Rehost: recreate the application on cloud servers, the "lift and shift" model.
- Refactor or rearchitect: restructure the application to use cloud-native services.
- Revise or re-platform: move and adapt part of it, for example by using a managed database.
- Rebuild: discard the application and recreate it on cloud infrastructure.
- Replace: retire it and move the use cases to a software-as-a-service product.
The document notes the debate between rehosting and refactoring. Sometimes you must move fast because a legacy system is being retired, and a refactor at the same time is not realistic. Then it can be right to rehost first and refactor afterward. The security point is that a lifted application keeps its old weaknesses, and now they sit on a network that is easier to reach.
Who is responsible for what?
The same architecture explains the three service models. In SaaS, the provider carries most of the responsibility and the customer places more trust in the provider. In infrastructure as a service (IaaS), much of the responsibility falls on the customer, some on the provider, and some is shared. It adds that providers may define the shared relationship differently from one to the next, and recommends that customers clearly identify the split and set service level agreements that spell out expectations.
A constructed example: a company moves its file server to IaaS and assumes the provider handles backups. The provider's documentation says the customer configures snapshots. Six months later a ransomware event hits the file server and the newest snapshot is eight months old. Nothing was breached on the provider side. The gap was in the assumed split.
What does the phase plan look like?
CISA's guidance gives phases that begin with a plan: choose the strategy, the provider and service type, and a road map for the application. Use the following sequence, adapted for a mid-sized organization.
- Inventory and classify. List applications and data, and note which ones hold regulated or sensitive information. FIPS 199 describes categorizing information by the potential impact of a loss of confidentiality, integrity or availability, and the same approach works for private companies.
- Choose a strategy per application, not for the whole estate.
- Build a landing zone: accounts, networks, identity, logging and baseline policies set up before any workload arrives.
- Move a low-risk application first and use it to test the process.
- Move the rest in waves, with a rollback plan for each.
- Decommission the old environment and confirm that data is deleted.
How do you keep watch afterward?
The CISA architecture defines cloud security posture management (CSPM) as a continuous process of monitoring a cloud environment by identifying, alerting on, and mitigating cloud vulnerabilities, reducing risk and improving cloud security. It notes that moving to the cloud does not by itself create a zero trust architecture. The distributed nature of cloud needs additional configuration and management to get the visibility over assets, users and data that zero trust needs.
How to check or apply this
- Write a one-page table: application, data sensitivity, strategy, owner, target date.
- For each service model you will use, list who owns patching, identity, encryption, backup and logging. Get the provider's side confirmed in writing or in their documentation.
- Build the landing zone first: multi-factor authentication for all admin accounts, central logging, and a baseline network design.
- Decide a naming and tagging scheme so every resource has an owner.
- Turn on configuration monitoring before moving production data.
- After each wave, run an access review and compare actual settings with the plan.
- Delete or lock down the old copies of data and keys.
Quick check
Is lift and shift a bad strategy?
Not always. It can be the right first step when time is short, as CISA's architecture notes. The risk is leaving it there, because old weaknesses move with the application.
Does moving to the cloud make us compliant?
No. Compliance depends on how you configure and operate your own part of the shared responsibility split. A provider's attestations cover the provider's part.
Sources
- CISA, Cloud Security Technical Reference Architecture
- NIST FIPS 199, Standards for Security Categorization
Last reviewed: 18 October 2026.
