A cloud migration rarely moves one clean copy of data from point A to point B. During the migration window, the source system, snapshots, replication storage, staging or test environments, and the target can all contain valid copies at the same time.
Transfer-level integrity checks do not settle the whole problem either. A technically successful transfer can still leave sensitive data in an unapproved location, the wrong environment authoritative, or temporary access active after cutover.
This guide breaks cloud migration data security into four control phases:
- Establish the source baseline and handling requirements
- Protect transfer and replication
- Control the hybrid cutover state
- Validate the target and retire the source
TL;DR
- Baseline the source before anything moves: Inventory in-scope resources and data, classify sensitive datasets, map owners and dependencies, and define the security state expected in the target
- Protect transfer and replication as several separate control problems: Limit migration identities, encrypt data in transit and at rest, remember that private connectivity does not automatically provide encryption, and verify integrity with checksums or equivalent controls
- Treat cutover as a data-state transition: Define which system is authoritative, monitor replication lag, stop or control writes before promotion, test rollback, and make sure target logging and identity controls are already operational
- Match controls to the migration pattern: Bulk online transfer, continuous database replication, and offline appliance transfer create different requirements for credentials, encryption, integrity, custody, and validation evidence; connectivity is a separate control dimension
- Do not close the migration on a successful transfer alone: Reconcile source and target scope, verify security and ownership context, remove migration-only privileges and resources, and retire residual source copies according to service-specific retention, deletion, and sanitization requirements only after all security gates pass
What is cloud migration data security?
Cloud migration data security is the set of controls used to protect the confidentiality, integrity, availability, and permitted location of data while it moves from a source environment to a cloud target. It covers the source baseline, transfer or replication, cutover period, target validation, and controlled retirement of obsolete copies.
That scope is broader than normal cloud data security best practices. In a steady-state environment, the intended data location, identity model, network paths, and monitoring controls should already be established. A migration temporarily adds transfer services, staging locations, privileged migration identities, duplicate datasets, and new trust boundaries.
The AWS Migration Lens reflects this difference by treating migration security as a combination of data protection, credential management, logging, networking, and application or database authentication rather than only transfer encryption. Migration adds temporary security states to the broader controls used for data security and privacy in cloud computing, including encryption, access, ownership, retention, and evidence.
How to secure data across four cloud migration phases
A useful cloud migration data security model has four states:
- Establish the source baseline and handling requirements
- Protect transfer and replication
- Control the hybrid cutover state
- Validate the target and retire the source
Each phase should end with explicit exit evidence. A completed migration task is not enough if the security state required for the next phase has not been established.
Phase 1. Establish the security baseline before data moves
The migration team needs to know what exists, what data it contains, who owns it, and what protection must follow it to the target. SP 1800-39 emphasizes discovering, identifying, and labeling sensitive data across the places where it resides. That matters during migration because the named production database may be only part of the security scope.
Classification should result in a decision:
- Migrate as-is
- Retain in the source environment
- Archive outside the active migration scope
- Delete according to retention policy
- Migrate after masking or transformation
The gap is material. The 2026 Thales Data Threat Report found that organizations classified an average of 51% of their cloud data as sensitive, while only 47% of that sensitive data was encrypted.
“Classification is useful only if it changes the migration decision. Sensitive data should not automatically follow an application into the target just because it happens to live in the same database or storage location.” — Katerina L., Cloud Security Expert at Cloudaware
Record at minimum:
- Resource or dataset
- Owner
- Application
- Classification
- Source
- Target
- Encryption / key requirement
- Retention / residency requirement
- Migration decision
Also timestamp the baseline. A baseline without a capture time becomes unreliable as soon as the source changes. New resources, permissions, backups, and application dependencies introduced after discovery must be tracked as migration deltas.
Example CMDB relationship view in Cloudaware, connecting an AWS compute resource to its application, database, network, security tooling, environment, owner, and operational state before migration.
Phase 2. Protect data during transfer and replication
Transfer security requires four separate checks: transport, migration identities, storage encryption, and integrity.
Start with migration identities. Depending on the platform, that identity may be an IAM role, service principal, managed identity, service account, federated workload identity, or temporary human administrator. For example, Microsoft documents different SQL Server permissions depending on whether the target is Azure SQL Database, Azure SQL Managed Instance, or SQL Server on Azure VMs.
A dedicated migration identity should have:
- Required operations
- Defined resource scope
- Named owner
- Lifecycle, activation window, or deprovisioning point
- Activity logging
- Explicit revocation condition
Broad access may occasionally be necessary, but “the migration provider finds it easier” is not sufficient justification for permanent administrative privilege. Where the workflow exposes temporary secrets, certificates, SAS tokens, API keys, or shared database credentials, rotate them after cutover rather than only disabling the migration identity.
Separate connectivity from encryption
Private is not the same as encrypted. Microsoft's hybrid connectivity guidance states explicitly that ExpressRoute provides a private path but does not encrypt traffic at the network layer by default. Google documents the same distinction for Cloud Interconnect and provides separate encryption options where the risk profile requires them.
The same principle applies inside migration tooling. Microsoft documents that Azure Database Migration Service protects its data in transit with TLS 1.2 by default, but that transport control does not replace decisions about target storage encryption or identity scope.
Transfer encryption also does not prove integrity. AWS recommends cryptographic hashes or checksums during migration. Google Storage Transfer Service data-integrity documentation shows the distinction concretely: when source checksum metadata exists, the service performs end-to-end checksum validation and fails transfers when source and destination data do not match.
Example data protection and key management posture view in Cloudaware, surfacing encryption findings, unmanaged keys, rotation gaps, affected resources, owners, and remediation context across AWS, Azure, and Google Cloud.
The same distinction applies to broader public cloud data security controls: private connectivity, encryption in transit, key ownership, and storage encryption need to be evaluated separately.
Phase 3. Control the hybrid cutover window
The hybrid cutover state deserves the most scrutiny because the source and target can both be technically healthy while containing different data or accepting different identities.
For a continuous database migration, the key security question is: Which system is authoritative right now? For example, Google Database Migration Service recommends stopping source writes and waiting until replication delay reaches zero before promotion.
Other migration platforms expose different replication checkpoints, so the cutover gate should use the service-specific measure that proves the target has consumed the required source changes. Depending on the database and migration service, that checkpoint may be expressed as replication lag, a CDC watermark, PostgreSQL LSN, Oracle SCN, or MySQL GTID/binlog position.
Cutover record example:
dataset: orders-prod
authoritative_system: source-postgres
source_write_state: read_only
source_connections_drained: true
replication_method: CDC
checkpoint_type: replication_watermark
target_caught_up_to_checkpoint: true
target_state: ready_for_promotion
target_logging: active
migration_identity: migration-orders-prod
rollback_owner: platform-oncall
rollback_window: 2h
rollback_write_handling: reconcile_target_writes
Do not leave write authority implicit. During replication, the source normally remains authoritative while the target catches up. Before promotion, quiesce source writes and confirm the final replication checkpoint. After promotion, keep the source read-only or offline unless rollback is invoked. A multi-writer state should exist only when conflict handling, ordering, replay behavior, and rollback semantics are explicitly designed.
A production workload should not enter service while its authentication, administrative, network, or application events remain outside the normal investigation path.
Before promotion, verify cloud audit logging, database audit logging where required, delivery of target logs into the SIEM, and consistent event timestamps or time-zone normalization.
Example SIEM enrichment view in Cloudaware, adding cloud account, application, environment, and region context to security events so migrated workloads remain investigable during cutover.
Phase 4. Validate the target before retiring the source
A migration service can report success without proving that the target inherited the source's owner, application relationship, logging coverage, backup policy, security baseline, or complete data scope.
“Teams usually validate whether the data arrived. They should also validate whether the context arrived. If the target resource loses its owner, application relationship, environment, or operational controls, the migration may be technically complete and still not be ready for production.” — Igor K., DevOps Engineer at Cloudaware
Treat validation as three separate jobs:
| Validation | Question |
|---|---|
| Transfer validation | Did the expected files, objects, or records arrive intact? |
| Scope reconciliation | Did everything intended to migrate arrive, and did anything unexpected appear? |
| Security validation | Does the target meet required IAM, encryption, logging, backup, ownership, and policy conditions? |
Google Storage Transfer Service documentation explicitly separates transfer integrity from broader migration completeness. Reconciliation should also check security metadata that may not travel with the payload, including database grants, object ACLs or authorization policies, retention or legal-hold settings, object versioning, encryption-key associations, and schema permissions.
NIST SP 800-88 Rev. 2 covers media-sanitization methods, including cryptographic erase, but cryptographic erase is a specific sanitization mechanism rather than a universal synonym for deletion. In managed cloud services, customers typically control logical deletion, backup retention, snapshot lifecycle, and key lifecycle rather than physical media sanitization, so the exact retirement mechanism depends on the provider and service.
Residual backups, staging storage, transfer appliances, old database replicas, and credentials should therefore be included in the retirement plan.
Example target-state policy evaluation view in Cloudaware, showing scoped resources, encryption violations, exceptions, accountable owners, remediation tickets, and retest status before source retirement.
Match security controls to the migration path
Cloud migration data security measures change with the migration pattern. The main question is which trust boundary the pattern introduces and which connectivity option carries the data.
| Migration pattern | Example mechanisms | Connectivity options | Primary security concern |
|---|---|---|---|
| Bulk online transfer | AWS DataSync, Google Storage Transfer Service | Internet/TLS, VPN, dedicated private connectivity | Scope, transfer identity, staging, integrity |
| Continuous database replication | AWS Database Migration Service (AWS DMS), Azure Database Migration Service, Google Cloud Database Migration Service | Internet/TLS, VPN, dedicated private connectivity | Replication privilege, CDC lag, authoritative state |
| Offline appliance | Azure Data Box, Google Transfer Appliance | Physical custody + provider upload | Chain of custody, key handling, sanitization |
Microsoft's Azure Data Box security specifies AES-256 encryption for data at rest, encrypted protocols for loading data, and secure erasure after upload. Google's Transfer Appliance security adds an attestation process used before credentials are issued and another validation when Google receives the appliance back, helping detect tampering during physical transit.
This is also where stale migration advice becomes dangerous. Physical-transfer services change over time, so validate provider support before building a migration plan around an older service recommendation.
The selected transfer pattern also affects cloud migration costs, especially where dedicated connectivity, replication duration, staging storage, or offline appliances are required.
Use security gates before declaring the migration complete
Application smoke testing answers whether the workload runs. It does not answer whether the migration is secure.
Use six independent gates before closure:
| Gate | Question | Evidence |
|---|---|---|
| Scope | Did every intended dataset, resource, and required version reach the target? | Migration manifest, inventories, object or row counts |
| Integrity | Did transferred data arrive without unintended alteration, and is replication caught up to the agreed checkpoint? | Checksums, validation errors, CDC or replication checkpoint |
| Identity | Are temporary migration privileges removed or reduced to steady-state access? | IAM review, disabled roles or accounts, credential rotation |
| Protection | Are target encryption, logging, backup, and security controls operational? | Configuration evidence, policy results, restore and logging checks |
| Ownership | Is each target resource tied to the correct service and accountable owner? | CMDB relationships and owner metadata |
| Retirement | Are residual source copies handled according to retention and deletion requirements? | Decommission record, backup lifecycle, deletion or key evidence |
The framework is intentionally stricter than “migration job completed.” It forces security, operations, and the migration team to produce evidence for different failure modes instead of allowing one successful functional test to close the project.
Keep migration security context current from source to target
Migration tools can show whether data transfer or replication has completed, but they do not necessarily show whether the target infrastructure still has the expected owner, application relationship, configuration, or policy state.
Cloudaware can support this control layer by connecting multi-cloud inventory, CMDB relationships, ownership, change history, and compliance findings around the same cloud resource or CI.
Core capabilities:
- Anchor migration scope in live infrastructure data: Maintain a CMDB-backed inventory across AWS, Azure, Google Cloud, VMware, and hybrid environments so migration scope reflects resources Cloudaware currently discovers rather than a static planning export
- Re-establish target context: Connect discovered target resources to applications, services, owners, parent accounts or projects, and related CIs before source retirement
- Trace infrastructure changes through migration: Review Change Events and history for newly created, modified, deleted, or re-related CIs, including configuration, tags, ownership, and relationship changes that occur between baseline and cutover
- Validate the target against defined security policy: Scope Compliance Engine evaluations by resource type, environment, account, region, tags, or other CMDB attributes, then check migrated infrastructure against the configuration controls that apply to that target state
- Move failed checks into remediation: Keep policy findings tied to the affected CI, evidence, severity, and owner, then route remediation through Jira or ServiceNow while preserving the resource context