Migrating databases to the cloud: AWS DMS, Google DMS, and Yandex Data Transfer

Migrating a database to a cloud provider rarely boils down to dumping and loading. If the database is large and downtime must be measured in minutes, you need a service that first copies the data, then catches up the changes accumulated during copying, and keeps the copy up to date until the cutover. Major clouds have their own tools for this: AWS Database Migration Service, Google Cloud Database Migration Service, and Yandex Data Transfer.

How migration without long downtime works

Almost all such services operate using the same pattern:

1. Initial copy — transfer existing data table by table.
2. CDC (Change Data Capture) — read the source change log (WAL in PostgreSQL, binlog in MySQL, redo logs in Oracle) and apply changes to the target while copying is in progress and after it.
3. Cutover — the application is briefly stopped, wait until the target catches up with the source, and point the application to the new database.

Migrations are divided into homogeneous (PostgreSQL → PostgreSQL) and heterogeneous (Oracle → PostgreSQL). In the latter case, besides data, you need to translate schema, procedures and types — and this is where services differ the most.

AWS Database Migration Service

The oldest and most universal of the three. Works in two modes:

• With a replication instance — a virtual machine that reads the source and writes to the target. Billed by the hour depending on the instance class, plus storage beyond the included volume.
• DMS Serverless — capacity is selected automatically and billed in DCU per hour.

For heterogeneous migrations there is DMS Schema Conversion: conversion of schema and code, e.g. from Oracle or SQL Server to PostgreSQL. According to AWS pricing pages this feature is free; you only pay for the S3 storage it uses.

Strengths of DMS — wide choice of sources and targets and mature support for commercial DBMSs. Weaknesses — you need to size the instance yourself, monitor tasks and deal with CDC nuances for each source.

Google Cloud Database Migration Service

The service is designed to move databases into Google Cloud and operates without dedicated virtual machines: Google handles the data snapshot and replication of changes.

Documentation lists support for:

• homogeneous migrations — MySQL to Cloud SQL for MySQL, PostgreSQL to Cloud SQL for PostgreSQL and AlloyDB, SQL Server to Cloud SQL for SQL Server;
• heterogeneous — Oracle and SQL Server to Cloud SQL for PostgreSQL or AlloyDB with schema conversion.

The main limitation is direction: the service moves data into Google-managed databases, not between arbitrary systems. Pricing depends on migration type; current figures are on the service’s pricing page.

Yandex Data Transfer

Yandex Cloud service for data transfer and continuous replication between databases, queues and storages. Supports three transfer types: copy, replication, and copy followed by replication.

Sources according to documentation: PostgreSQL, MySQL, Oracle, MongoDB, ClickHouse, Greenplum, YDB, Apache Kafka, Data Streams, Object Storage, Elasticsearch, OpenSearch and others. Targets: PostgreSQL, MySQL, MongoDB, ClickHouse, Greenplum, YDB, Kafka, Object Storage, Apache Iceberg, OpenSearch and others. Not all source-target combinations are available; some operate in Preview mode.

A distinguishing feature of Data Transfer is orientation not only to migration but also to continuous streams: for example, replicating from PostgreSQL to ClickHouse for analytics or exporting changes to Kafka.

Cost consists of worker compute resources (vCPU and memory billed hourly) and the number of rows transferred; the first 100M rows per month are not charged, and transfers in Preview are free.

Comparison

What is available to a Russian company

• Payment. You cannot pay AWS or Google Cloud with a Russian card: Visa and Mastercard have not worked abroad since March 2022, and Google Cloud does not accept new customers from Russia.
• Personal data. From July 1, 2025 the primary recording of personal data of Russian citizens must be maintained in databases located on the territory of Russia (more about 152-FZ). Moving such a database to a foreign cloud does not comply with this requirement.

Therefore, for a Russian company the realistic choices are Yandex Data Transfer, similar services from other Russian clouds, or a self-managed migration: PostgreSQL logical replication, MySQL replication, pg_dump followed by catching up changes. On the internals of these DBMSs — see the articles about MySQL and PostgreSQL.

How to prepare for migration

1. Check that your source is supported and the required CDC mode: for PostgreSQL you typically need wal_level = logical, for MySQL — binlog in ROW format.
2. Do a trial run on a copy: copying time, replication lag, volume of changes.
3. Reconcile data after copying — row counts and checksums for key tables.
4. Check what services do not transfer: users and privileges, sequences, triggers, extensions.
5. Plan cutover and rollback: when writes are stopped, how long to wait for catch-up, and how to revert to the old database if something goes wrong.

Common mistakes

• No primary keys — CDC cannot correctly apply changes to the table.
• Replication lag not accounted for — cutover is performed while the target has not yet caught up to the source.
• Sequences not synchronized — after cutover new rows receive identifiers that are already taken.
• Exotic types and extensions in heterogeneous migration without a trial run.
• Personal data transferred abroad without assessing legal requirements.