AWS Database Migration Service EU Alternative 2026: CLOUD Act Migration Window, Art.17 CDC Delete Gap, and the DMS Data Exposure During Database Migration

Post #799 in the sota.io EU Compliance Series

AWS Database Migration Service (DMS) is a managed service that migrates databases to AWS with minimal downtime. It supports homogeneous migrations — MySQL to MySQL, PostgreSQL to PostgreSQL, Oracle to Oracle — and heterogeneous migrations between different database engines, with the AWS Schema Conversion Tool (SCT) handling the schema translation. DMS uses a replication instance (an EC2-based managed VM) to read data from the source database, transform it, and write it to the target. For live migrations with ongoing replication, DMS uses Change Data Capture (CDC) to continuously stream inserts, updates, and deletes from source to target until the cutover window.

The operational value proposition is genuine: zero-downtime migration with a managed replication infrastructure, support for 20+ database engines including commercial databases (Oracle, SQL Server) and open-source ones (PostgreSQL, MySQL, MariaDB), and tight integration with AWS target services (RDS, Aurora, Redshift, DynamoDB, S3). The AWS Schema Conversion Tool automates the conversion of stored procedures, triggers, and database-specific syntax, reducing the most labor-intensive part of heterogeneous database migrations.

It is not in the AWS European Sovereign Cloud service catalog.

For European organizations migrating databases that contain personal data about EU residents — which describes virtually every production database in customer-facing applications — DMS creates a GDPR compliance architecture that most migration projects do not adequately assess before go-live. The service's design as a hosted replication layer means that during migration, your entire database contents pass through AWS-managed infrastructure under US jurisdiction. The compliance problems are not edge cases: they arise from the fundamental architecture of how managed database migration works.

What AWS Database Migration Service Does

AWS DMS provides managed database replication for migrations and ongoing data synchronization.

Core components:

• Replication Instance: An EC2-based managed VM that AWS provisions and operates in your chosen AWS region. The replication instance connects to both the source and target databases, reads data from the source, applies any configured transformations, and writes to the target. The replication instance stores data in transit locally — it buffers change data between source reads and target writes. For large databases, this buffer is substantial. You control the replication instance's compute size and storage, but AWS manages the underlying operating system and network configuration.
• Source and Target Endpoints: Connection configurations for the databases DMS reads from and writes to. Sources can be on-premises databases (connected via VPN or Direct Connect), databases in other cloud providers, or AWS-hosted databases. Targets are typically AWS services (RDS, Aurora, DynamoDB, S3, Kinesis, Redshift, OpenSearch). DMS supports 20+ database engines across both source and target roles.
• Replication Tasks: The configured migration jobs defining which tables to migrate, in which order, with what transformation rules, and in which mode (full load, CDC only, or full load + CDC). Transformation rules in DMS use a JSON-based mapping syntax to rename, filter, add, and remove columns during replication — enabling data transformations at the migration layer.
• AWS Schema Conversion Tool (SCT): A separate downloadable application that analyzes the source database schema — tables, indexes, stored procedures, triggers, functions, views — and automatically converts the schema to the target database engine's syntax. SCT generates a migration assessment report rating conversion complexity and identifying objects that require manual conversion. SCT connects to your source database to perform this analysis.
• DMS Fleet Advisor: A managed discovery tool that scans on-premises database infrastructure to build an inventory of database servers, their configurations, and their schema complexity. Fleet Advisor is used to plan large-scale migrations by providing a comprehensive view of the database estate. It requires an agent installed on on-premises servers that sends discovery data to AWS.

Scale context: A European healthcare SaaS provider with 2.1 million patient records across PostgreSQL databases in their on-premises datacenter uses DMS to migrate to RDS Aurora PostgreSQL in eu-west-1 (Dublin). The replication instance processes approximately 340 GB of database content during the initial full load, including patient demographics, diagnosis codes (ICD-10), prescription histories, and clinical notes. During the 72-hour CDC phase before cutover, DMS continuously streams all database changes — new patient records, updated diagnoses, prescription updates — through the replication instance. At cutover, the organization decommissions the replication instance and the source database goes read-only briefly for final sync.

ESC status: AWS Database Migration Service is not in the AWS European Sovereign Cloud service catalog. The replication instances, task configuration, and the DMS control plane operate under standard AWS's US-governed access policies.

GDPR Issue 1 — CLOUD Act: The Migration Window Jurisdiction Problem

CLOUD Act (18 U.S.C. § 2713) requires US cloud providers to produce stored data in response to lawful US legal process regardless of where the data is physically stored. AWS DMS replication instances are AWS-managed compute in your chosen AWS region — but they are operated by AWS, a US corporation. During a DMS migration, the replication instance temporarily holds a copy of your database contents in its local buffer storage as it reads from source and writes to target. This creates a CLOUD Act jurisdiction exposure over data that may not otherwise be in AWS infrastructure.

The migration window as a jurisdictional event: Before DMS, your production PostgreSQL database runs on-premises or on a EU-sovereign cloud provider. The data is under your organization's direct control, not in AWS infrastructure, and not subject to CLOUD Act demands. The moment you start a DMS full load task, a copy of every row in every migrated table begins flowing through an AWS-managed replication instance. During the full load phase — which can take hours or days for large databases — your entire database contents are being processed by AWS infrastructure subject to CLOUD Act.

What the replication instance stores: DMS replication instances do not simply pipe data from source to target in a stateless stream. The replication instance buffers data to manage the write throughput to the target and to handle source-target speed differences. For large tables, the replication instance stages data in its local storage before committing to the target. During CDC, the replication instance stores the Change Data Capture log position data and recent change events. A CLOUD Act demand served during an active DMS migration could compel AWS to produce the contents of the replication instance's buffer — which may contain recently read source data including personal data that has not yet been written to the target.

Industry-specific severity:

Healthcare databases migrated via DMS involve Art. 9 special-category personal data — patient diagnoses, prescription records, clinical notes, genetic data. The CLOUD Act migration window for a healthcare database migration creates a window during which US law enforcement could demand access to patient health information that EU data protection law designates as requiring the highest level of protection. The EU-US Data Privacy Framework does not restrict CLOUD Act demands for health data stored in US cloud infrastructure.

Financial services databases migrated via DMS may include customer financial data protected under DORA (Digital Operational Resilience Act) and sector-specific data residency requirements. The ECB and EU banking supervisors have noted that US law enforcement access to customer financial data held in US-cloud infrastructure requires careful legal analysis under DORA Art. 30's concentration risk and subcontracting restrictions.

Multi-tenant SaaS databases where a single database contains personal data belonging to hundreds of EU organizations create a compound CLOUD Act exposure. A CLOUD Act demand that produces a DMS replication instance's buffer during a multi-tenant migration potentially exposes personal data for all tenants whose data was being migrated at the time of the demand — regardless of which specific organization was the demand's target.

DMS Fleet Advisor: The Fleet Advisor agent installed on on-premises servers sends database inventory data — server configurations, database engine versions, table counts, schema complexity metrics — to AWS. This metadata, while not containing row-level personal data, constitutes business intelligence about the organization's database infrastructure. Under CLOUD Act, this infrastructure intelligence held by AWS is accessible to US law enforcement.

GDPR Issue 2 — Art. 17: CDC Delete Replication Gap

GDPR Art. 17 grants data subjects the right to erasure — the right to have their personal data deleted. For an organization operating a live DMS CDC replication task, Art. 17 erasure requests create an operational complexity: deletes on the source database may not reliably propagate to the target.

How CDC handles deletes: Change Data Capture works by reading the database's transaction log (binary log for MySQL, WAL for PostgreSQL, redo log for Oracle) and extracting insert, update, and delete events. DMS reads these log events and applies them to the target. For deletes, DMS reads the delete event from the source log and executes a corresponding DELETE statement on the target. In principle, a delete on the source propagates to the target within the replication lag period (typically seconds to minutes).

Where CDC delete replication fails:

LOB (Large Object) columns: DMS's handling of Large Object data types — BLOB, CLOB, NCLOB, BYTEA in PostgreSQL, LONGTEXT and LONGBLOB in MySQL — uses two modes: Limited LOB mode (truncates LOB data to a configured size) and Full LOB mode (migrates complete LOB contents but at reduced performance). In Full LOB mode, DMS does not apply CDC delete events to LOB columns inline — it requires the full row to be re-fetched from the source to get the complete LOB value. If the source row has already been deleted by the time DMS processes the CDC event, the re-fetch fails and the delete operation on the target may not complete. Medical images stored as BLOB, clinical notes stored as CLOB, and document attachments stored as BYTEA are common LOB patterns in healthcare databases — and these are precisely the data types where Art. 17 erasure requests are most likely to arise.

Referential integrity conflicts: The target database may have foreign key constraints that prevent deleting a parent row until child rows are deleted first. If DMS processes delete events out of order (which can occur during high-throughput replication or when the replication lag spikes), a parent-row delete event may arrive before the child-row delete events. The foreign key constraint blocks the parent delete. DMS's error handling for constraint violations is configurable (log and ignore, stop task, or retry) — but the default behavior may result in the Art. 17 delete failing silently.

Filtered replication tasks: DMS replication tasks can be configured with table-level and column-level filters. If a DMS task is configured to replicate only rows matching certain criteria (e.g., records created after a date, or records in certain geographic zones), delete events for rows outside the filter criteria are not replicated to the target. If an Art. 17 erasure request deletes a row from the source that was originally outside the DMS task's filter criteria, the delete is not replicated — but a copy of the row may still exist in the target from a prior full load that predated the filter configuration.

Replication task pause and replay: If a DMS CDC task is paused and resumed, DMS replays change events from its stored log position. Delete events that occurred during the pause are replayed when the task resumes. But if the CDC lag grows large enough that the source database's transaction log rotates past the DMS log position, DMS loses the ability to replay deletions that occurred during the gap. The target retains rows that were deleted from the source.

Art. 17 compliance gap: Organizations relying on DMS for ongoing database synchronization — not just one-time migrations but continuous replication between systems — should not assume that deleting a record from the source database fulfills their Art. 17 erasure obligation. Each of the failure modes above can result in deleted source records persisting in the target. GDPR Art. 17 compliance in a DMS-replicated environment requires: explicit verification that CDC delete events propagated to the target, monitoring for replication lag and error events that indicate failed deletes, and a direct Art. 17 deletion procedure on the target database that does not rely solely on DMS replication.

GDPR Issue 3 — Art. 5(1)(c): Data Minimization Failure in Full-Table Migration

GDPR Art. 5(1)(c) requires that personal data be "adequate, relevant, and limited to what is necessary in relation to the purposes for which they are processed" (data minimization). A database migration is not just a technical operation — it is a processing activity that requires the migrated dataset to satisfy the same data minimization principles as the source system.

The full-table migration default: DMS migrates entire tables by default. Unless an administrator explicitly configures table selection and column filtering in the DMS replication task, every row in every table — including rows containing personal data that was collected years ago for purposes no longer active, personal data about former customers or employees, and columns containing personal data that is technically stored but never accessed in the application — migrates to the target.

The pre-migration purge failure pattern: In practice, database migrations are under time pressure. The migration project timeline pressures teams to achieve a working migration from A to B as quickly as possible. The "data purge before migration" step — identifying and deleting personal data that should no longer be retained under Art. 5(1)(e) storage limitation — is frequently deferred to "after we're stable on the new system." But after the system is live on AWS RDS or Aurora, the operational pressure to delete data from the production database increases further (downtime risk, replication complexity). The pre-migration purge that was deferred before go-live rarely happens post-go-live.

The column-level minimization gap: Many databases contain personal data that was collected for one purpose and persisted in columns that the current application no longer writes to or reads from. Phone number columns in databases that switched to email-only contact, physical address columns in applications that moved to GPS coordinates, social security number columns from legacy identity verification workflows, fax number columns from 1990s-era forms. DMS migrates all columns unless transformation rules explicitly exclude them. Without a column-level audit before migration, the target database inherits the same accumulated PII debt as the source — in a new location under a new compliance scope (AWS under CLOUD Act, if it wasn't before).

The historical record tables: Many enterprise applications maintain historical record tables — *_audit, *_history, *_log — that accumulate every change ever made to the primary data. These tables can be 10x to 100x the size of the primary tables and contain personal data from years or decades of changes. DMS migrates these tables by default. The target Aurora cluster inherits a complete history of every personal data record ever inserted or modified in the source — including data for individuals who have already exercised their Art. 17 erasure rights on the source (erasure on the source may not have been applied to the history tables).

DMS transformation rules as a minimization tool: DMS does support column-level transformations — you can configure rules to remove columns, mask column values, or replace them with pseudonymous identifiers during migration. This capability exists but requires explicit configuration by the migration engineer, knowledge of which columns contain personal data (requiring a pre-migration data inventory), and testing to ensure the transformation does not break the target application. Implementing DMS transformation rules as a GDPR data minimization tool adds project complexity that migration projects under time pressure regularly skip.

GDPR Issue 4 — Art. 28: Sub-Processor Chain During Live Replication

GDPR Art. 28 requires that when a data controller uses a processor to process personal data, the engagement is governed by a Data Processing Agreement (DPA) specifying the subject-matter, duration, nature, and purpose of processing. When DMS is used for ongoing CDC replication — not just a one-time migration but continuous synchronization between databases — DMS becomes a sub-processor of the organization's data controller obligations.

The DPA scope for DMS: AWS's Data Processing Addendum (DPA) covers DMS as a data processor. The DPA specifies AWS as a processor acting on the controller's documented instructions. For DMS, the "instructions" are the replication task configuration: which tables to migrate, what transformations to apply, which target endpoint to write to. The AWS DPA includes sub-processor notification obligations — AWS's list of sub-processors for DMS includes the underlying AWS infrastructure services (EC2 for the replication instance, VPC networking, CloudWatch logging).

The replication instance as a processing location: The DPA obligation requires the controller to know where processing occurs. For DMS, the replication instance is an EC2 instance in the AWS region you specify — the controller can satisfy the Art. 28 requirement that processing occurs in EU regions by choosing eu-west-1 (Dublin), eu-central-1 (Frankfurt), eu-north-1 (Stockholm), or eu-south-1 (Milan). This is a genuine DMS capability: EU-region replication instances keep the data processing within EU geographical boundaries.

What EU-region DMS does NOT solve: Choosing an EU-region replication instance means the data is processed in EU infrastructure — but processed by AWS, a US entity. As noted in Issue 1, CLOUD Act jurisdiction applies to AWS regardless of the region. The Art. 28 DPA with AWS satisfies the formal requirement for a processor agreement — but it does not eliminate CLOUD Act jurisdiction as a transfer risk that the TIA (Transfer Impact Assessment) must address.

DMS for ongoing synchronization: Some organizations use DMS not just for migration but as a permanent replication layer — continuous CDC from an on-premises source to AWS Aurora or Redshift, enabling cloud analytics on operational data. This use case turns DMS from a temporary migration processor into a permanent sub-processor. Art. 28 requirements for permanent sub-processor relationships are more demanding: regular reviews of the processor's security measures, audit rights, and documentation of the processor relationship in the Art. 30 Records of Processing Activities with the duration field set to indefinite.

The multi-source DMS topology: Enterprise migration projects frequently involve DMS replicating from multiple source databases — different on-premises systems, databases in other cloud providers, partner databases accessible via VPN — into a unified AWS target (a data lake in S3, an analytics database in Redshift, or a consolidated Aurora cluster). Each source-to-target path through DMS is a distinct processing activity requiring its own Art. 28 documentation, Transfer Impact Assessment (if the source is outside the EEA), and Art. 30 record entry. The DMS console's centralized view of all replication tasks does not automatically generate GDPR compliance documentation.

GDPR Issue 5 — Schema Conversion Tool: Database Schema as Business Intelligence

The AWS Schema Conversion Tool (SCT) and DMS Fleet Advisor create a distinct GDPR-adjacent concern: the database schema and infrastructure inventory sent to AWS constitutes business intelligence about the organization's data architecture that is accessible under CLOUD Act.

What SCT sends to AWS: The Schema Conversion Tool connects directly to the source database to analyze its schema. SCT transmits to AWS: table names, column names, column data types, primary key and foreign key relationships, index definitions, stored procedure code, trigger definitions, view definitions, and function logic. The migration assessment report generated by SCT — which rates conversion complexity and identifies objects requiring manual conversion — is stored in AWS and accessible via the DMS console.

Schema intelligence as business information: A database schema is a blueprint of the organization's data architecture. Table names like patient_diagnoses, user_payment_methods, employee_salary_history, fraud_detection_scores, or customer_churn_predictions reveal the organization's operational data model, the categories of personal data it collects, and the internal processes its systems support. Column names reveal the granularity of personal data collection — daily_step_count, preferred_political_party, hiv_status, monthly_net_income, relationship_status. Stored procedure logic reveals business rules and data transformation logic that may be proprietary.

CLOUD Act on schema intelligence: Under CLOUD Act, a lawful demand for AWS to produce SCT migration assessment reports and schema analysis data could reveal an organization's complete data architecture to US law enforcement — including the categories and structure of personal data held by the organization. This is not a GDPR violation per se (schema data is not typically personal data itself), but it represents a competitive intelligence and legal strategy exposure that organizations migrating regulated databases should assess.

DMS Fleet Advisor: The Fleet Advisor agent goes further than SCT. Fleet Advisor is designed for large migrations involving hundreds of database servers and scans the entire on-premises database infrastructure — discovering all database instances, their engines, versions, sizes, and connection patterns. The resulting inventory is uploaded to AWS and used to generate a migration plan. A Fleet Advisor scan of a hospital system's database infrastructure reveals the complete data architecture of the clinical information systems: which systems communicate with each other, the size and complexity of the patient data systems, and the technical dependencies between clinical and administrative databases.

EU Alternatives

EU-sovereign migration tools and CDC frameworks perform database migrations without routing database contents through US-cloud infrastructure, eliminating CLOUD Act migration window exposure while providing equivalent functionality.

Debezium

Debezium is an open-source CDC platform developed by Red Hat (a subsidiary of IBM) and released under the Apache License 2.0. It is the most widely deployed open-source CDC solution and provides the closest functional equivalent to DMS for continuous replication use cases.

Architecture: Debezium consists of connector plugins that integrate with Apache Kafka Connect. Each connector reads the transaction log of a specific database engine — PostgreSQL's WAL (write-ahead log), MySQL's binary log, Oracle's redo log, SQL Server's change data capture tables, MongoDB's oplog, and others — and publishes change events (inserts, updates, deletes) as structured messages to Kafka topics. Downstream consumers read from the Kafka topics and apply changes to target databases or data stores.

GDPR-relevant capabilities:

• Delete propagation: Debezium reliably propagates delete events by reading the database transaction log directly. The delete event includes the full row data at the time of deletion (configurable), enabling downstream consumers to identify and process Art. 17 erasure events across the replication chain.
• Column masking and filtering: Debezium supports field exclusion and transformation at the connector level. Personal data columns can be excluded from CDC events before they reach Kafka topics — implementing Art. 5(1)(c) data minimization at the replication layer.
• Outbox pattern: Debezium supports the transactional outbox pattern (atomic writes to an application database table, CDC-captured and published to Kafka) enabling event-driven architectures that maintain GDPR compliance guarantees at the event level.

EU deployment: Debezium deployed on EU-sovereign infrastructure (Hetzner Kubernetes, IONOS Cloud, self-managed VMs in EU datacenters) processes database change events without any US cloud provider involvement. Kafka can be self-managed or deployed via EU-sovereign providers (Aiven for Apache Kafka on EU infrastructure, Confluent Cloud on GCP eu-central1). No CLOUD Act exposure.

pgcopydb

pgcopydb is an open-source tool specifically designed for fast, consistent PostgreSQL-to-PostgreSQL migrations. It uses PostgreSQL's native logical replication and COPY protocol to achieve migration speeds significantly faster than pg_dump/pg_restore for large databases, while supporting the same change-capture approach as DMS for minimal-downtime migrations.

Architecture: pgcopydb creates a snapshot of the source database, copies the snapshot to the target in parallel (using multiple connections and PostgreSQL's COPY streaming protocol), and then applies changes that occurred during the copy using PostgreSQL logical decoding. The cutover window is typically minutes rather than hours, even for large databases.

GDPR-relevant capabilities:

• Column-level exclusion: pgcopydb supports --table-filter and --exclude-schema options. Combined with PostgreSQL's column-level GRANT restrictions, organizations can perform migrations that exclude personal data columns not needed in the target system.
• Transformation via publication: PostgreSQL's logical replication publication mechanism allows specifying which columns are included in the replication stream — providing schema-level data minimization without requiring application changes.
• Self-managed encryption: pgcopydb transfers data over PostgreSQL's native encrypted connection (TLS), with encryption certificates under the organization's control.

EU deployment: pgcopydb is a binary tool deployed on any Linux server — no cloud service dependency. A migration using pgcopydb runs entirely on infrastructure the organization controls, with no data flowing through any third-party-managed replication layer. Hetzner Dedicated Servers or IONOS Cloud VMs provide EU-sovereign staging infrastructure.

Airbyte (Self-Hosted)

Airbyte is an open-source ELT platform that provides database migration and synchronization connectors for 300+ data sources and destinations. Airbyte Self-Hosted is deployed on EU infrastructure under the organization's control; it provides a managed UI equivalent to the DMS console without the CLOUD Act exposure.

Architecture: Airbyte runs as a containerized service (Docker Compose or Kubernetes). Connectors execute as Docker containers that Airbyte orchestrates. The Postgres, MySQL, Oracle, SQL Server, and MongoDB source connectors support CDC via log-based replication (equivalent to DMS's CDC mode). Destination connectors write to the target database, data warehouse, or data lake.

GDPR-relevant capabilities:

• Column-level field selection: Airbyte's stream catalog configuration allows selecting which fields from each source table are included in the sync — implementing Art. 5(1)(c) data minimization at the ELT configuration level.
• Transformation layer: Airbyte supports dbt (data build tool) transformations that execute on the target after data load. dbt transformations can implement pseudonymization, column removal, and data quality checks as part of the migration workflow.
• Audit logging: Airbyte's sync logs are stored locally (or in the organization's chosen observability stack), providing the Art. 30 processing activity records required for ELT-based data processing documentation.

EU deployment: Airbyte Self-Hosted on Hetzner, Scaleway, OVHcloud, or IONOS infrastructure eliminates US cloud provider dependency. Airbyte Cloud (the managed SaaS version) is operated by Airbyte, Inc. (a US company) — the self-hosted deployment is the EU-sovereign option.

Native PostgreSQL Logical Replication

For PostgreSQL-to-PostgreSQL migrations — the most common migration scenario for modern applications — PostgreSQL's native logical replication (pg_logical or the built-in PUBLICATION/SUBSCRIPTION mechanism in PostgreSQL 10+) provides DMS CDC functionality without any third-party tooling.

Architecture: The source database creates a publication specifying which tables and columns to replicate. The target database creates a subscription pointing to the source. PostgreSQL streams change events (inserts, updates, deletes) directly from source to target using the logical replication protocol over a standard PostgreSQL connection.

GDPR-relevant capabilities:

• Column-level publications: PostgreSQL 15+ supports column-level publication filtering (CREATE PUBLICATION my_pub FOR TABLE users (id, email, created_at) — excluding sensitive columns). Art. 5(1)(c) data minimization implemented at the database layer.
• Row-level filtering: PostgreSQL 15+ supports row-level WHERE clauses on publications, allowing partial table replication that excludes personal data records outside the scope of the target system.
• Direct delete propagation: PostgreSQL logical replication propagates DELETE events by default, with REPLICA IDENTITY configuration controlling whether deleted row data is included in the event. Art. 17 erasure propagation is reliable and verifiable.

EU deployment: PostgreSQL logical replication runs entirely on the organization's infrastructure with no external service involvement. Source: on-premises PostgreSQL. Target: Hetzner Managed Database for PostgreSQL, Scaleway Managed Database, IONOS Cloud Managed PostgreSQL, or self-managed PostgreSQL on EU VMs. No data leaves the organization's infrastructure during migration.

pg_dump / pg_restore with EU Staging

For organizations that can tolerate a migration downtime window (scheduled maintenance), the traditional pg_dump/pg_restore approach on EU-sovereign staging infrastructure is the simplest CLOUD Act-safe migration path:

1. pg_dump the source database to a compressed file on EU-sovereign staging (Hetzner, IONOS, or OVH VMs)
2. Transfer the dump file to the target via encrypted SCP/rsync between EU-sovereign servers
3. pg_restore to the target database
4. Verify row counts, run application smoke tests, flip DNS

This approach requires no third-party migration service, no replication instance, and no data flowing through US-cloud infrastructure. The DMS equivalent — AWS SCT for schema conversion — is replaced by pgloader (open source, converts MySQL schemas to PostgreSQL) or manual DDL review for heterogeneous migrations.

AWS European Sovereign Cloud Status

AWS Database Migration Service: NOT in the AWS European Sovereign Cloud service catalog.

The ESC catalog absence means DMS replication instances, replication task configurations, and the DMS control plane operate under standard AWS's US-governed access policies. For organizations in EU regulated industries migrating databases under DORA (financial services), the EHDS (health data), or NIS2 (critical infrastructure) — all of which impose data sovereignty requirements on infrastructure processing critical personal data — DMS is unavailable as a compliant migration service under those frameworks' sovereign cloud requirements.

The ESC gap has particular significance for migration scenarios involving Art. 9 special-category data (health, genetic, biometric) where processing must occur under EU-governed infrastructure controls that the CLOUD Act migration window structurally cannot satisfy.

GDPR Compliance Checklist for Database Migrations

Before starting any DMS migration task:

1. Personal data inventory before migration: Conduct a column-level inventory of every table being migrated. Identify columns containing personal data categories (name, email, address, phone, IP address, health data, financial data, behavioral data). Document the retention policy for each personal data category and delete records that are outside the retention window before starting the migration. Do not defer pre-migration purges to post-go-live.

2. DMS transformation rules for data minimization: For columns containing personal data that is not needed in the target system, configure DMS transformation rules to exclude or mask those columns before migration. Test the transformation rules in a staging migration before production go-live. Document the transformation rules as Art. 5(1)(c) data minimization controls in your Art. 30 Records of Processing Activities.

3. CDC delete verification: If you are using DMS CDC for ongoing replication, implement delete verification: after each Art. 17 erasure request handled on the source database, verify within 24 hours that the delete event was applied to the target by querying the target for the deleted record. Document the verification in the Art. 17 erasure request record. Do not rely on DMS CDC replication as the sole deletion mechanism for Art. 17 compliance.

4. CLOUD Act TIA for migration window: Document a Transfer Impact Assessment addressing CLOUD Act jurisdiction during the migration window. Assess the categories of personal data in the migration, the realistic probability of CLOUD Act demands for your organization type, and the severity of impact on data subjects if database contents were produced in response to a CLOUD Act demand during an active migration. Consider scheduling migrations outside active-threat windows if the CLOUD Act exposure for your database contents is assessed as high.

5. Art. 28 DPA for ongoing replication: If DMS is used for ongoing CDC replication (not just a one-time migration), document DMS as a sub-processor in your Art. 30 Records of Processing Activities with the duration, subject-matter, nature, and purpose of processing. Include the DMS replication task configuration as the specification of processing instructions under Art. 28(3). Review annually.

6. Schema Conversion Tool scope limitation: If using SCT for heterogeneous migration planning, limit SCT connection permissions to the minimum schema objects required for migration planning. Do not run SCT against production databases with customer data present. Use a schema-only export (pg_dump --schema-only for PostgreSQL, mysqldump --no-data for MySQL) as the SCT input rather than a live production connection.

Conclusion

AWS Database Migration Service delivers genuine operational value: managed replication infrastructure, broad database engine support, and tight AWS target integration that makes complex migrations tractable. But the DMS architecture — managed replication instances processing your entire database contents, CDC that can silently fail to propagate deletes, full-table migrations that move obsolete PII by default, and Schema Conversion Tool intelligence sent to AWS — creates a GDPR compliance exposure profile that most migration projects do not adequately assess.

The CLOUD Act migration window is the most acute risk: during DMS full load and CDC phases, your entire database contents — including Art. 9 health data, financial data, and behavioral profiles — are in AWS-managed infrastructure subject to US law enforcement demands. The Art. 17 CDC delete gap is the most persistent risk: organizations relying on DMS CDC for ongoing synchronization cannot assume that source deletes reliably propagate to targets, creating Art. 17 compliance gaps that persist long after the migration project closes. The data minimization failure is the most common risk: migrations under time pressure migrate everything by default, bringing the source database's accumulated PII debt into the new AWS environment.

EU-sovereign alternatives — Debezium on self-managed Kafka for continuous CDC, pgcopydb for fast PostgreSQL-to-PostgreSQL migrations, Airbyte Self-Hosted for ELT workflows, and PostgreSQL native logical replication for the most common migration scenario — provide equivalent migration capabilities on EU-sovereign infrastructure. These tools eliminate the CLOUD Act migration window because there is no US cloud service in the replication chain. Delete propagation is reliable and verifiable. Data minimization is configurable at the migration layer. Art. 28 sub-processor documentation is straightforward because the processing occurs on infrastructure the organization directly controls.

Database migrations are infrequent but high-exposure events: the entire database contents flow through the migration infrastructure during a time-limited window. Getting the GDPR compliance architecture right before the migration starts — not after go-live — is the only practical approach. With EU-sovereign migration tooling, that architecture does not require US cloud infrastructure.