Cloud Migration Security: Protect Workloads Before, During and After the Move

Most cloud migration security failures happen during the move itself, when two environments run side by side, temporary access is granted in a hurry and nobody owns the old estate any more. Landing zone and cloud security guides describe the target state; this guide covers the journey: discovery, choosing a migration strategy per workload, getting the landing zone ready before the first server moves, designing identity and network paths for the hybrid period, protecting data in transit, running a safe cutover and decommissioning the on-premises source properly. It is written for infrastructure and security leads running a migration programme, and for the executives who sign off its risk. For the target-state controls themselves, see the Cloud Security Guide and the Cloud Landing Zone Security Guide.

Key takeaways

• Treat the migration as a temporary environment with its own risks. Migration appliances, replication agents, hybrid identity sync and data transfer channels are new attack surface that exists for months, not days.
• The landing zone comes first. Identity, logging, network boundaries and guardrail policies must be live before the first workload lands, or every early workload becomes an exception that never gets fixed.
• Lift and shift moves the weaknesses too. A rehosted server keeps its old patch level, local accounts, hardcoded secrets and over-broad service accounts, and gains cloud reach through any role you attach to it.
• Migration tooling is privileged. Discovery appliances and replication services hold credentials to vCenter, Hyper-V hosts and servers; protect, monitor and remove them like any other privileged identity.
• Decommissioning is a security control. Old servers, firewall rules, sync accounts, DNS records and backups left behind after cutover are where forgotten access lives.

The migration lifecycle and where security sits

Every major framework describes migration as a sequence of phases. Microsoft's Cloud Adoption Framework lists five steps: plan migration, prepare workloads, execute migration, optimise in cloud and decommission source. AWS Prescriptive Guidance organises large migrations around assessing, mobilising and migrating waves of workloads. The names differ; the security work at each stage is the same.

Discovery: inventory what you are really moving

Discovery is usually done for cost and sizing. Extend it to answer security questions, because every unknown dependency becomes either an outage or an emergency firewall rule during cutover.

• Dependencies and trust: map which systems talk to each other, on which ports, and with which credentials. Microsoft's planning guidance asks teams to find dependencies and plan for split-environment operations, the period when some components are in the cloud and others are not.
• Data classification: record the most sensitive data each workload stores or processes. It decides the transfer method, the target region and the encryption keys. See the Data Classification Guide.
• Non-human identities: list every service account, scheduled task identity, API key, certificate and connection string the application uses. These are the credentials most often copied into the cloud unchanged. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.
• Regulatory constraints: data residency, sector rules and contractual clauses that limit which regions and services you may use.
• The discovery tool itself: discovery appliances need broad read access. The Azure Migrate appliance, for example, connects to vCenter over TCP 443, to Hyper-V hosts and Windows servers over WinRM on 5986 (HTTPS), and to Linux servers over SSH on port 22. It falls back to WinRM over HTTP on 5985 if HTTPS is not configured on a target, unless the HTTPS-only option is enabled in the appliance configuration manager. Enable that option, and give the appliance read-only discovery credentials scoped to the estate being assessed.

Choosing a strategy per workload: the 7 Rs through a security lens

AWS Prescriptive Guidance defines seven migration strategies. Each one carries different security debt into the cloud, so the strategy decision is also a risk decision.

Decision guidance: for most estates, rehost or replatform first, then modernise. Accept that some weaknesses will travel, but write them down per workload with an owner and a date, and fix the dangerous ones before the move: hardcoded credentials, unsupported operating systems exposed to the internet and service accounts with domain-wide rights. Small organisations moving a handful of servers can often go straight to replatforming onto managed services, which removes patching and credential handling from their hands; large programmes need the register of accepted weaknesses because nobody will remember them after wave twenty.

Landing zone readiness before the first workload

A landing zone is the pre-built target: account or subscription structure, identity, logging, networking and guardrails. Its design is covered in the Cloud Landing Zone Security Guide and, for Azure, the Azure Landing Zones Security Guide. For a migration, the question is simpler: is it ready to receive workloads? Use this gate.

1. Identity is integrated: workforce sign-in uses the corporate identity provider with MFA; no local cloud users exist other than documented break-glass accounts. See the Break-Glass Account Guide.
2. Logging is central and protected: control plane audit logs from every account or subscription flow to a log archive the migration team cannot delete. See the Cloud Logging and Audit Trail Guide.
3. Guardrails are enforced: preventive policies block public storage, unapproved regions and unencrypted resources, and require instance metadata hardening such as IMDSv2 on AWS. See the EC2 Instance Metadata Service Hardening Guide.
4. Network boundaries exist: a hub or transit design with inspection, no default internet exposure and documented connectivity back to the data centre.
5. Environments are separated: migration staging, test and production land in different accounts or subscriptions. See the Environment Separation.
6. Backups and keys are ready: backup policies and key management are configured so the first migrated workload is protected from day one.

Identity design for the hybrid period

Identity is where migrations most often create lasting exposure. Three groups of identities need decisions.

• Hybrid directory sync: synchronising an on-premises directory to a cloud identity provider makes the sync server and its accounts Tier 0, because they can write to the cloud directory. The Storm-0501 Hybrid Cloud Attacks 2024 show attackers stealing Entra Connect Sync credentials on premises and using them to move into the cloud. See the Microsoft Entra Connect and Cloud Sync Hardening Guide. Do not sync privileged on-premises accounts into cloud admin roles; use cloud-only admin accounts.
• Migration identities: discovery appliances, replication agents and migration service roles need credentials on both sides. Create dedicated identities per wave or per tool, scope them to the servers being migrated, store their secrets in a vault, and put an expiry date on every one. Accessing the Azure Migrate appliance configuration manager requires an administrator account on the appliance server, so the appliance is itself a privileged host.
• Workload identities after the move: replace connection strings and stored service account passwords with managed identities or IAM roles, and scope each role to the resources the workload needs. The Capital One Breach 2019 is the reference case: a firewall running in AWS had a role that could read far more storage than a firewall needs, and its temporary credentials were taken through the instance metadata service. See the Cloud IAM Review Checklist.

Network design and connectivity

Microsoft's planning guidance compares three data paths: a private dedicated connection (ExpressRoute), described as faster and more secure than internet connections; a VPN, which creates an encrypted tunnel over the internet; and the public internet, described as the least secure option and suitable only for less sensitive data. An offline option, Azure Data Box, avoids using the network at all. AWS offers equivalent options (Direct Connect, Site-to-Site VPN and Snowball devices).

• Temporary rules expire: every firewall rule opened for migration gets a ticket reference and an end date, and a weekly report lists rules past their date.
• Do not flatten the network: extending a flat data centre network into the cloud brings lateral movement paths with it. Route hybrid traffic through inspection points and allow only the flows discovery identified. See the Zero Trust Network Segmentation Playbook for Flat Networks.
• Private endpoints for migration services: Azure Migrate supports Private Link for its management and storage endpoints; use private connectivity where the tool offers it.

Protecting data in transfer

• Know which hop is encrypted: AWS DataSync, for example, encrypts the transfer between its agent and the service with mutual TLS 1.3, but reads from the source and writes to the destination using the storage system's own protocol (SMB, NFS or the S3 API) and its security features. An NFS share read in clear text on the local network is still clear text on that hop.
• Verify the tooling: Microsoft publishes SHA256 hashes for the Azure Migrate appliance OVA, VHD and ZIP files; check them before deployment. Apply the same check to any migration agent.
• Lock down staging storage: replicated disks, database exports and file staging buckets often hold a full copy of production. Encrypt them, block public access, restrict access to the migration identities and delete them after cutover.
• Prove integrity: compare checksums or row counts between source and target before cutover, and keep the results as evidence.
• Database migrations: require TLS on source and target connections, use a dedicated migration login with only the rights the tool needs, and remove it afterwards.

Cutover and rollback

1. Write the runbook with security steps in it: DNS changes, certificate deployment, secret rotation, firewall rule changes and monitoring checks, each with an owner.
2. Test in a rehearsal: run a test migration into an isolated environment and run vulnerability scans and configuration checks on the result before the real cutover.
3. Agree go/no-go security criteria: logging flowing to the central archive, no critical findings in posture checks, backups configured, privileged access reviewed.
4. Rotate credentials at cutover: any secret that existed on premises and was copied into the cloud should be rotated once the workload is live, so a copy left on an old server or backup is worthless.
5. Keep a tested way back: Microsoft's planning guidance asks for a defined rollback plan. Keep the source read-only and intact until the rollback window closes, then decommission it on a schedule.

Decommissioning the on-premises source

Decommissioning is the step most often skipped when budgets run out. A switched-off server is not a decommissioned one.

• Sanitise media: follow NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization (final, September 2025), for disks, arrays and backup media; cryptographic erase is acceptable where the encryption was managed properly.
• Remove identities: disable and then delete service accounts, migration accounts, appliance accounts and sync accounts that are no longer needed; revoke their certificates and API keys.
• Remove network paths: close the migration firewall rules, delete VPN tunnels and routes that are no longer used, and remove stale DNS records that could be taken over.
• Remove the tooling: uninstall replication agents, delete discovery appliances and their projects, and clear any stored credentials.
• Handle backups and archives: decide retention for old backups under your retention policy, then destroy or migrate them; old backups hold old secrets.
• Update the inventory: mark assets as retired so the CMDB, vulnerability scanner and licence records agree.

Detection and measurement

Monitor the migration period as its own risk: cloud control plane logs for new roles, policy changes and public exposure; sign-ins by migration and sync accounts from anywhere other than their expected hosts; data transfer volumes outside the planned waves; and changes to the guardrail policies themselves. Useful ATT&CK techniques to tune detections for are T1078.004 Cloud Accounts, T1552.005 Cloud Instance Metadata API, T1530 Data from Cloud Storage and T1537 Transfer Data to Cloud Account.

• Workloads landed with zero critical posture findings: percentage per wave.
• Migration identities past expiry: target zero.
• Temporary firewall rules past their end date: target zero.
• Secrets rotated at cutover: percentage of inventoried application secrets rotated after go-live.
• Decommissioning lag: days between cutover and verified decommissioning of the source.
• Logging coverage: percentage of migrated accounts and subscriptions sending audit logs to the central archive.

Framework mapping

In ISO/IEC 27001:2022 Annex A, the most relevant controls are 5.23 Information security for use of cloud services, 8.10 Information deletion and 7.14 Secure disposal or re-use of equipment.

Common failure patterns

• Workloads arrive before the guardrails: early waves land in a half-built landing zone with public endpoints and no central logging, and are never brought back into line.
• Over-permissive roles on rehosted servers: a role attached "to get it working" grants broad storage or admin rights, as in the Capital One Breach 2019.
• Hybrid sync treated as plumbing: the directory sync server sits in a normal server tier with an admin path from ordinary workstations, giving attackers a bridge into the cloud, as in the Storm-0501 Hybrid Cloud Attacks 2024.
• Secrets copied, never rotated: configuration files with database passwords and API keys move with the application and still match copies on old servers and backups.
• Migration staging left behind: replicated disks, exports and staging buckets outlive the project with full copies of production data.
• Decommissioning abandoned: old servers, VPN tunnels and service accounts remain reachable for years because no one owns them after cutover.

Practitioner checklist

• Extend discovery to record data classification, dependencies and every non-human credential per workload.
• Record the migration strategy and accepted security weaknesses per workload, with an owner and fix date.
• Pass a landing zone readiness gate (identity, logging, guardrails, network, environment separation, backups) before wave one.
• Create dedicated, scoped, expiring identities for every migration tool and store their secrets in a vault.
• Treat directory sync servers and accounts as Tier 0 and keep cloud admin accounts cloud-only.
• Choose transfer paths by data sensitivity and confirm which hops are encrypted; verify tool hashes before deployment.
• Put security checks in cutover go/no-go criteria and rotate copied secrets at go-live.
• Give every temporary firewall rule and migration account an end date and report on overdue ones weekly.
• Decommission the source on a schedule: sanitise media, remove accounts, rules, DNS records, agents and staging data.

Standards and references

• Microsoft: Cloud Adoption Framework, Plan your migration
• AWS Prescriptive Guidance: Migration strategies (the 7 Rs)
• NCSC: The cloud security principles
• NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• Microsoft Learn: Azure Migrate appliance
• AWS: DataSync encryption in transit

Related NHI Mgmt Group resources: Cloud Security Guide · Cloud Landing Zone Security Guide · Cloud Misconfiguration Guide · Identity Platform Migration