Before diving in, we need a clear picture of the problem this service solves and what it actually delivers.

Why database migration is hard

Moving files is simple compared with moving a database. A database is alive. It is constantly being read and written by applications, and every write changes the data you are trying to copy. If you copy a large database the simple way, by taking a full backup and restoring it elsewhere, the copy is already out of date by the time it finishes, and the only safe way to catch up is to stop the application for the whole time. For a small database that might mean minutes. For a large one it can mean many hours or days of downtime, which most businesses cannot accept.

There are other difficulties too. The source and destination may use different database software, with different data types, different procedural languages, and different behaviors. Networks between the old and new locations must be secured. Permissions and settings must be right. And someone must verify that nothing was lost. Doing all of this by hand with custom scripts is slow, risky, and hard to repeat.

What the service gives you

Database Migration Service is a managed, serverless service that moves databases into Google Cloud’s managed database offerings. Today it focuses on migrating into Cloud SQL and into AlloyDB for PostgreSQL. It takes care of networking setup, the initial snapshot, ongoing replication of changes, progress reporting, and the final switch of the destination to become a standalone primary database. Because it is serverless, you do not provision or manage any migration servers. You describe the source and destination, start a migration job, and watch it work.

Every service has its own words. These are the ones you will meet in almost every migration conversation.

How the words fit together

You begin by describing your source in a connection profile and by creating or choosing a destination. A migration job ties them together. The service takes an initial snapshot, loads it, and then uses change data capture to keep the destination in step. When you are ready, you promote the destination so it becomes the primary, and you point your applications at it. If the engines differ, a conversion workspace first translates the schema and code so the destination can understand them.

The first design choice is whether the copy is a single moment in time or a living stream that stays current.

One-time migration

A one-time migration takes a single point-in-time snapshot of the source database and applies it to the destination. It is a dump and load: the data is read out, written in, and the destination is ready when the load finishes. Any changes made to the source after the snapshot are not carried over. This approach is simple and suits databases that can be frozen, meaning the application can stop writing during the migration, or datasets that do not change, such as archives or test copies. The downtime is the whole duration of the copy, so it is best for smaller databases or planned maintenance windows.

Continuous migration

A continuous migration, sometimes called ongoing or online migration, starts with a full snapshot and then keeps copying every change as it happens. This is based on change data capture, which finds the inserts, updates, and deletes that occur after the snapshot and replays them on the destination. The application keeps running on the source the whole time. When source and destination are caught up, you switch over, and downtime shrinks from hours to a short moment.

flowchart TD
    A["Start migration job"] --> B["Initial snapshot of source"]
    B --> C["Load snapshot into destination"]
    C --> D["Continuous replication of changes"]
    D --> E{"Destination caught up?"}
    E -->|"Not yet"| D
    E -->|"Yes"| F["Plan cutover window"]
    F --> G["Stop writes to source"]
    G --> H["Promote destination"]
    H --> I["Point applications to destination"]
        

Choosing between them

The second big choice is whether you are keeping the same database engine or changing it.

Homogeneous migrations

A homogeneous migration moves data between the same database technology, for example from MySQL to Cloud SQL for MySQL, or from PostgreSQL to Cloud SQL for PostgreSQL or AlloyDB for PostgreSQL. Because the engines match, the data types, the code, and the behavior all line up. The job is mostly about copying data safely and keeping it in sync. This is the easier kind of migration and the one most teams start with.

Heterogeneous migrations

A heterogeneous migration changes the engine, for example from Oracle to Cloud SQL for PostgreSQL or AlloyDB for PostgreSQL, or from SQL Server to Cloud SQL for PostgreSQL. Here the source and destination speak different dialects. Data types differ, stored code such as procedures, functions, and triggers is written in different languages, and features do not map one to one. Before data can flow, the schema and code must be converted into a form the destination understands.

What changes in a heterogeneous project

Understanding where your data is going helps you choose the right target and size it properly.

Cloud SQL

Cloud SQL is Google Cloud’s fully managed relational database service for engines such as MySQL, PostgreSQL, and SQL Server. Google handles provisioning, patching, backups, replication, and failover, while you manage your schema, data, and queries. It is a natural landing place for typical business applications that previously ran on self-managed database servers.

AlloyDB for PostgreSQL

AlloyDB is a PostgreSQL-compatible managed database designed for demanding workloads that need high performance and high availability, with a separation of compute and storage and features aimed at transactional and analytical needs. It is often chosen when a PostgreSQL workload outgrows a standard managed instance or when stronger performance and availability characteristics are desired.

Managed services change your responsibilities

Moving from a self-managed database to a managed service shifts work. You no longer patch operating systems, schedule backups by hand, or build replication yourself. In exchange, you give up some low-level control, such as access to the underlying machine and certain server settings. Review the features and settings your applications depend on, and confirm they are supported in the managed destination before you start.

What actually happens behind the scenes between creating a job and having a synchronized destination?

The main components

flowchart LR
    SRC["Source database on premises or other cloud"] -->|"Secure connectivity"| DMS["Database Migration Service workers"]
    DMS -->|"Snapshot and change stream"| DST["Destination in Google Cloud"]
    DMS --> MON["Job status and charts"]
    APP["Applications"] --> SRC
    DST -.->|"After promotion"| APP
        

The phases of a continuous job

A continuous job passes through recognizable states. After you create and start it, the service begins a full dump, which is the initial snapshot of the source. Once the dump is loaded, the job enters a change data capture phase where it continuously applies new changes. While in this phase, the job reports how far behind the destination is, a number known as replication delay. When the delay is near zero and you have prepared your cutover, the job is ready to be promoted. During promotion, the service finalizes replication and detaches the destination so it can accept writes independently.

stateDiagram-v2
    [*] --> Created
    Created --> Running: Start job
    Running --> FullDump: Snapshot loading
    FullDump --> CDC: Snapshot complete
    CDC --> ReadyForPromote: Delay near zero
    ReadyForPromote --> Promoting: You promote
    Promoting --> Completed: Destination detached
    Running --> Failed: Unrecoverable error
    CDC --> Paused: You pause
    Paused --> CDC: You resume
        

How changes are captured

Every database keeps an internal record of changes it makes, used for its own recovery and replication. The service reads from that record to learn which rows were inserted, updated, or deleted after the snapshot. This is why the source database must be configured to keep that record in a suitable form, and to keep it long enough for the migration to read it. If the record is discarded too soon, the service loses its place and the job may have to start over.

Networking is often the trickiest part of a migration. The service offers several ways to connect, each with its own trade-offs.

The connectivity options

Choosing a method

Encryption on the wire

The service encrypts connections using SSL and TLS certificates, so data moving between the source and Google Cloud cannot be read in transit. Where your source database supports it, you should require encrypted connections and use certificates for verification. For continuous migrations, customer-managed encryption keys can also be used to protect migration data, which suits organizations with strict key control policies.

Network planning checklist

When the engine changes, the hard part is translating the structure and the logic of the database, not moving the rows.

What needs converting

A database is more than tables of data. It holds data types, constraints, indexes, views, and, importantly, programmable objects such as stored procedures, functions, packages, and triggers. Each engine has its own language and its own special features. A procedure written for one engine often cannot run on another without rewriting. Conversion is the process of mapping all of these objects to equivalents in the destination engine.

Conversion workspaces

The service provides conversion workspaces to make this manageable. When you create a workspace, an initial automatic conversion runs, translating as much of the schema and code as it can. You then work in an interactive SQL editor to review the results, fix objects that could not be translated automatically, and adjust the converted schema to better suit the destination. Customization directives let you override automated rules, for example to map a data type differently or rename objects consistently.

Help from generative assistance

The service also offers Gemini-powered conversion features that suggest translations for harder pieces of code, helping accelerate the work. These suggestions should always be treated as drafts to be reviewed and tested, never as final answers, because subtle behavior differences between engines can change results in ways that look correct but are not.

flowchart TD
    A["Connect to source and read schema"] --> B["Create conversion workspace"]
    B --> C["Automatic initial conversion"]
    C --> D{"All objects converted?"}
    D -->|"Yes"| F["Review and test"]
    D -->|"No"| E["Fix in SQL editor with assistance"]
    E --> F
    F --> G["Apply schema to destination"]
    G --> H["Run data migration job"]
        

Common conversion trouble spots

Most migration surprises come from skipping preparation. A short list of prerequisites prevents a long list of problems.

Preparing the source

The exact steps depend on the engine, but the themes are consistent. The source must allow replication-style access, which means a dedicated user with the right privileges to read data and change records. It must keep its change log in the form and for the duration the migration needs. Certain settings, such as how changes are recorded, may need adjusting. Some settings require a restart of the source, which should be planned for a maintenance window. Tables without primary keys can be a problem for change replication, since there may be no reliable way to identify which row changed, so identify and fix them early.

Preparing the destination

Create a destination of adequate size and with the right version, and decide on its location, high availability, and backup settings. Consider performing the heavy initial load on a destination with generous resources and scaling down afterward, since loading is more demanding than steady-state use. Make sure required extensions and configuration flags are available, and plan storage with room for growth, because the destination often stores more than the source due to indexes and different storage layouts.

Preparing the people and the plan

Cutover is the moment of truth. With preparation, it is a calm, short, rehearsed sequence.

The cutover sequence

sequenceDiagram
    participant O as Operator
    participant A as Application
    participant S as Source database
    participant J as Migration job
    participant D as Destination database
    O->>J: Check replication delay
    O->>A: Stop writes
    A-xS: No new writes
    J->>D: Apply final changes
    O->>D: Validate data
    O->>J: Promote
    J->>D: Detach and make primary
    O->>A: Point to destination
    A->>D: Read and write
        

No dual writes

An important rule is that the service does not support writing to and reading from both source and destination at once. During migration the source is the system of record, and the destination follows it. After promotion, the destination becomes the system of record. There is no stage where both accept writes and stay merged. Planning for a clean, one-direction switch avoids data conflicts that are extremely hard to untangle.

Having a way back

Before cutover, decide how you would return to the source if something goes badly wrong. Keep the source intact and unchanged for an agreed period after promotion, and think through what would happen to any new writes that reached the destination if you must roll back. For some scenarios, reverse replication back to the original engine is possible, which can provide a safety net, but you should check whether your scenario supports it. Never decommission the source until the new environment has proven itself.

Migrating a database means handling your most valuable data. Security needs deliberate attention at every step.

Identity and access

Access to create and manage migration jobs is governed by Google Cloud identity and access management. Grant the migration roles only to the people who run migrations, and separate those who can start and promote jobs from those who can only view them. On the database side, use a dedicated migration account with the narrowest privileges that work, and remove or disable it when the project is over.

Handling credentials

Connection profiles hold credentials for reaching the source. Treat those credentials as secrets. Do not paste passwords into tickets, chat, or shared documents. Use a strong unique password for the migration account, restrict where it can connect from, and rotate or disable it as soon as the migration is finished.

Data residency and regulation

The location you choose for the destination determines where your data will physically reside, which matters for data residency laws and internal policy. During migration data also passes through the service’s processing, so confirm the service’s location handling meets your requirements. For regulated data such as financial or health records, involve your compliance team early and keep records of what was migrated, when, and by whom.

A migration you cannot see is a migration you cannot trust. The service offers status and charts, and you should add your own validation.

What the service shows

The console shows the state of each migration job, with charts for things like replication delay and storage usage, and many scenarios let you filter by individual database inside the job. Replication delay is the key number: it tells you how far the destination trails the source. A steady low value means healthy replication. A growing value means the destination is falling behind and you should investigate.

Validating the data yourself

Do not rely only on the job’s status. Run independent checks that matter to your business.

Common problems and what they usually mean

flowchart TD
    A["Job unhealthy"] --> B{"Which symptom?"}
    B -->|"Cannot connect"| C["Check network, firewall, certificates"]
    B -->|"Permission error"| D["Compare user grants to prerequisites"]
    B -->|"Delay growing"| E["Check write rate, bandwidth, destination size"]
    B -->|"Table errors"| F["Check types, keys, conversion results"]
    C --> G["Retest and resume"]
    D --> G
    E --> G
    F --> G
        

Understanding what you pay for, and what the service cannot do, keeps expectations realistic.

What drives the cost

For many supported migration scenarios, the service itself has been offered at no additional charge for the migration into Cloud SQL or AlloyDB, while you pay for the resources you use around it. However, pricing and eligibility can differ by scenario and change over time, so always confirm on the official pricing page. The real costs of a migration are usually the destination database during and after the move, any network charges for transferring data, the machines and links you use to connect, the storage for snapshots and logs, and the people-time for planning, rehearsal, and testing.

Advantages and trade-offs

Comparing approaches to database migration

The same replication machinery supports several scenarios beyond one-off migrations into the cloud.

What these have in common

In each case, the pattern is the same: snapshot the source, replay changes continuously, and decide deliberately when to switch or stop. Understanding that pattern lets you adapt the service to new needs while keeping the safety rules in mind, especially the rule that only one side accepts writes at any given time.

Teams that migrate well tend to repeat a few sound patterns. Teams that struggle tend to repeat a few avoidable mistakes.

Patterns worth adopting

Anti-patterns to avoid

A checklist of habits that experienced teams build into every database migration, and the traps that catch newcomers.

Best practices

Common mistakes

A short pre-cutover review

These illustrative scenarios, drawn from common industry patterns, show how the ideas combine in practice.

What these scenarios share

Each team confirmed support first, designed the network early, rehearsed the full process, and defined clear criteria for the cutover. Each validated data independently, kept the source as a safety net, and treated promotion as a one-way decision. None of them relied on luck.

Short, direct answers to questions that come up again and again.

The service supports migrations into Cloud SQL and AlloyDB for PostgreSQL. Supported sources, versions, and engines vary by scenario, so confirm your exact pairing in the official documentation.

Homogeneous keeps the same engine, such as MySQL to Cloud SQL for MySQL. Heterogeneous changes engines, such as Oracle to PostgreSQL, and requires schema and code conversion.

With continuous migration, downtime is limited to the cutover window, often minutes. With a one-time migration, downtime lasts for the whole copy. Rehearsal gives you a realistic number.

Yes, for continuous migrations. Applications keep reading and writing the source while the service copies the snapshot and replays changes.

It finalizes replication and detaches the destination so it becomes an independent primary that accepts writes. It is a one-way step.

No. The service does not support a dual-write scenario. The source is the system of record until promotion, and then the destination takes over.

Use a reverse SSH tunnel so the connection is initiated from your side, or private connectivity through VPN, interconnect, and VPC peering if available.

Yes. Connections use SSL and TLS, and customer-managed keys can be used for continuous migrations where you need control over keys.

Conversion workspaces perform an automatic initial conversion, offer an interactive editor and customization directives, and provide Gemini-powered suggestions. Humans must still review and test the results.

Check source write volume, destination size, bandwidth, and very large transactions. Ensure change log retention on the source is long enough so the service does not lose its place.

Do not rely on job status alone. Compare row counts and checksums, sample records, object inventories, and run application and performance tests against the destination.

Only after the new environment has been stable and verified for an agreed safety period. Keep the source unchanged until then in case you need to investigate or fall back.

No. It is built for databases. Files and objects have their own dedicated transfer services.

Database Migration Service is Google Cloud’s serverless answer to moving live databases with very little downtime. It copies a database into Cloud SQL or AlloyDB using an initial snapshot, then keeps the destination in step through change data capture until you are ready to switch. Migrations are either one-time, which suit databases that can be frozen, or continuous, which suit production systems that cannot stop. They are either homogeneous, keeping the same engine, or heterogeneous, changing engines with the help of conversion workspaces, an interactive editor, and generative assistance for schema and code. Connectivity can be an allowlist, a reverse tunnel, or private peering, always protected by encryption. Success depends on preparation: supported versions confirmed, a least-privilege migration user, adequate change log retention, keys on every table, a right-sized destination, a rehearsed runbook, and clear go or no-go criteria. At cutover, you stop writes, drain the delay to zero, validate, promote, and repoint applications, remembering that promotion is one-way and that dual writes are not supported. Keep the source as a safety net, validate independently, and clean up afterward. Done this way, cutover night is quiet, and that is the best sign of a well-run migration.