Database Migration Service — the four homogeneous paths, the four heterogeneous ones, and what "minimal downtime" rests on
The documented source-to-destination pairs, split into same-engine and cross-engine migrations, the two objects you create, and the fact that Oracle and SQL Server both have documented paths onto PostgreSQL — which is the row that decides a modernisation estimate.
markdownreferencev1KS71-6KKHstage: deploytrust: officialfamily: migrationservice: database-migration-serviceinterface: anydatabase migration serviceDMSconnection profilemigration jobhomogeneous migrationheterogeneous migrationMySQLPostgreSQLSQL ServerOracleAlloyDBCloud SQLongoing replicationminimal downtime
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:
- networking — reaching a source that is not on Google Cloud, which is usually the first week of a
hand-rolled migration;
- the initial snapshot;
- 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.