---
cuppy_hub: gcp
cuppy_path: reference/migration/database-migration-service.md
cuppy_section: docs
cuppy_doc: KS71-6KKH
cuppy_doc_uuid: 4f75b297-4ff8-46df-8fd2-7b34e7a30714
cuppy_permalink: https://cuppy.io/gcp/d/KS71-6KKH
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/migration/database-migration-service
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 76ea07b8f0ef9d1f90623a91a75611fa53a7937a74aedf99cf54901648aa1ac2
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Database Migration Service

## 1. The documented paths

### Homogeneous — same engine

| From | To |
|---|---|
| MySQL | Cloud SQL for MySQL |
| PostgreSQL | Cloud SQL for PostgreSQL |
| PostgreSQL | **AlloyDB for PostgreSQL** |
| SQL Server | Cloud SQL for SQL Server |

### Heterogeneous — different engine

| From | To |
|---|---|
| **Oracle** | Cloud SQL for PostgreSQL |
| **Oracle** | **AlloyDB for PostgreSQL** |
| **SQL Server** | Cloud SQL for PostgreSQL |
| **SQL Server** | **AlloyDB for PostgreSQL** |

**The heterogeneous column is the one that changes a programme.** Oracle and SQL Server both have documented,
first-party paths onto PostgreSQL. So "migrate" and "get off the commercial licence" can be the same project
rather than two — and the licence saving is often what funds the migration.

It is also the harder half: a cross-engine migration moves the data and leaves the **SQL, the stored
procedures and the application's assumptions** to be dealt with. The service does not claim otherwise.

## 2. Two objects

| Object | What it is |
|---|---|
| **connection profile** | how to reach a source or a destination |
| **migration job** | one migration, using those profiles |

Connection profiles are reusable, which matters at scale: an estate of thirty databases is thirty jobs against
rather fewer profiles.

## 3. What the service does for you

> "streamlines networking workflows, manages the initial snapshot and ongoing replication"

and supports **"minimal downtime migrations"**.

Read that as three things, because each is work you would otherwise do:

1. **networking** — reaching a source that is not on Google Cloud, which is usually the first week of a
   hand-rolled migration;
2. **the initial snapshot**;
3. **ongoing replication** — which is what makes the downtime small: the target keeps up with the source until
   you cut over.

*Recorded as an absence:* the page **mentions "ongoing replication" without detailing continuous
change-data-capture specifications.** So nothing is claimed here about replication lag, DDL handling, or which
changes are captured. **Those are exactly the questions a cut-over plan depends on** — read the engine-specific
pages before committing to a downtime window.

The **full list of supported engines and versions lives in a separate document** that was not read for this
release. Check your source's specific version there; "SQL Server is supported" is not a statement about your
SQL Server.

## 4. For an estimate

| Line | Where the work is |
|---|---|
| moving the data | **this service** — and it is the small part |
| schema conversion, for a heterogeneous move | the assessment. Per schema, and the largest unknown |
| SQL, stored procedures, and application data-access code | **the application team**, per codebase |
| the cut-over window | depends on replication behaviour this release did not read |
| source-side **egress** | the source cloud's bill, not Google Cloud's |

**The honest framing for a heterogeneous migration estimate:** the data movement is a solved, first-party
problem; everything above the data is not, and it is where the entire schedule lives. Any estimate that sizes
an Oracle-to-PostgreSQL move from database size alone is wrong by the size of the application.

See `guides/migration/assess-before-you-move.md` and `guides/parity/databases.md` §6.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->