A managed way to move databases into Google Cloud while the old one keeps working.

The problem with moving a database

A database holds the memory of a business: customers, orders, payments, messages. Moving it is harder than moving files, because the data changes all the time. If you copy it on Monday and switch on Tuesday, everything that happened in between is missing. The simple fix is to stop the application, copy everything and restart on the new database. For a small database this takes minutes. For a large one it can take many hours or days, and a shop that is closed for days loses money and customers.

What the service does about it

Database Migration Service, often called DMS, is a serverless service that migrates databases into Cloud SQL and AlloyDB for PostgreSQL on Google Cloud. It takes a first full copy of your data, then keeps copying every change that happens afterwards, so the new database stays almost identical to the old one. When you are ready, you switch your application to the new database after only a short pause. DMS also streamlines networking, tracks progress and reports the state of the migration throughout.

Ten words that appear in every migration discussion.

Do not worry about memorizing these. Each is explained again with examples in the chapters ahead.

The first big question: are you keeping the same database technology or changing it?

Homogeneous: same technology

A homogeneous migration moves data between the same kind of database. For example, from MySQL running in your data center to Cloud SQL for MySQL, or from PostgreSQL to Cloud SQL for PostgreSQL. The structure of tables, the data types and the code stored in the database all carry over without translation, so these migrations are simpler, faster and less risky.

Heterogeneous: different technology

A heterogeneous migration moves data between different database technologies. The classic example is Oracle to PostgreSQL. The two systems describe tables and data types differently, and the code stored inside the database, such as procedures and functions, is written in different languages. DMS handles this with conversion workspaces that translate the structure and objects into a form the destination understands. Current supported heterogeneous paths include Oracle to Cloud SQL for PostgreSQL and AlloyDB for PostgreSQL, and SQL Server to Cloud SQL for PostgreSQL and AlloyDB for PostgreSQL.

The second big question: can you afford to stop writing to the database while it is copied?

One-time migration

A one-time migration takes a single snapshot of the source and loads it into the destination. This is a classic dump and load. The destination is ready as soon as the load finishes. The catch is that any changes made to the source after the snapshot are not copied, so the application must not write to the source during the migration. This is acceptable for small databases, development systems, or workloads that can tolerate a maintenance window.

Continuous migration

A continuous migration, sometimes called ongoing or online migration, starts with an initial full snapshot and then keeps streaming changes using Change Data Capture. The source stays fully in use while data flows to the destination. When both are in sync, you promote the destination and switch. This approach minimizes downtime because it replicates only modifications instead of repeatedly copying everything, the data migrates while the source remains operational, and the serverless design performs well at scale.

flowchart LR
SRC["Source Database"] -->|"1. Initial snapshot"| DST["Destination Database"]
SRC -->|"2. Ongoing changes via CDC"| DST
APP["Application keeps working"] --> SRC
DST --> PR["3. Promote and switch application"]
        

The small set of objects that you create and the work Google does behind the scenes.

DMS has very few moving parts from your point of view. You describe the source, you describe the destination, and you create a job that connects them. Google runs the machinery that reads, transfers and applies the data. Because the service is serverless, you do not install or size any migration servers.

flowchart TD
CPS["Source Connection Profile"] --> MJ["Migration Job"]
CPD["Destination Connection Profile"] --> MJ
CW["Conversion Workspace (heterogeneous only)"] --> MJ
NET["Connectivity Method"] --> MJ
MJ --> SNAP["Snapshot and Load"]
MJ --> CDC["Continuous Replication"]
SNAP --> DEST["Cloud SQL or AlloyDB"]
CDC --> DEST
MJ --> OBS["Status and Metrics"]
        

A fully regional service

DMS is regional. All entities in one migration, including both connection profiles, the migration job, the destination database and any conversion workspace, must live in the same region. Choose that region early, because it affects speed, network design and where your data will sit after the move.

What you can move from, and what you can move to.

Sources include MySQL, PostgreSQL, SQL Server and Oracle databases, whether they run in your data center, on virtual machines, or on other cloud providers’ managed database services. Destinations are Cloud SQL for MySQL, PostgreSQL and SQL Server, and AlloyDB for PostgreSQL. Which exact pairs are allowed depends on the migration style and on versions, so always check the current compatibility tables before planning.

What actually happens between pressing Start and reaching the finish line.

sequenceDiagram
participant S as Source Database
participant D as DMS Service
participant T as Destination Database
D->>S: Connect with migration user
D->>S: Take initial snapshot
S-->>D: Existing data
D->>T: Load snapshot
S-->>D: Stream of changes from change log
D->>T: Apply changes in order
Note over S,T: Lag shrinks toward zero
D->>T: Promote on request
        

Why the change log is the hero

Every serious database already writes each change to a log so it can recover after a crash. CDC reads that same log. This is why continuous migration needs the source to keep its change log turned on in the right format, and why it causes little extra load on the source compared with repeatedly querying all the tables.

The bridge between your source and Google Cloud has to be safe and fast enough.

DMS must be able to reach the source database, and the destination must be reachable too. Several connectivity methods exist, and the right one depends on where the source lives and what your security rules allow. Source and destination can use different methods.

flowchart LR
OP["On-premises or Other Cloud Source"] -->|"VPN or Interconnect"| VPC["Google Cloud VPC"]
VPC --> DMS["Database Migration Service"]
DMS --> DEST["Cloud SQL or AlloyDB"]
OP -.->|"Allowlist over public internet"| DMS
        

Bandwidth and distance

The speed of the initial copy is limited by the network between source and destination. A database of several terabytes over a slow link can take a very long time. Estimate the transfer time by dividing data size by realistic sustained speed, not by the advertised line speed, and leave room for other traffic sharing the link.

Most migration problems are solved, or caused, before the job ever starts.

Preparing the source

Continuous migration needs the source to record changes in a way DMS can read. Each engine has its own settings, such as turning on binary logging for MySQL or enabling logical decoding for PostgreSQL. You also create a dedicated migration user with only the permissions DMS requires, rather than reusing an administrator account. Check that the source has enough free disk space to keep change logs while the snapshot is being copied, because logs are held until DMS has read them.

Preparing the destination

The destination Cloud SQL or AlloyDB instance must be created or provisioned with enough size for the data, the expected growth and the extra load during the initial load. Choose the engine version, region, storage and networking carefully. For production systems, plan high availability, backup settings and maintenance windows early, even if you turn some of them on only after cutover.

Preparing the people

Decide who owns the migration, who approves the cutover, who tests the application and who talks to the business. A clear owner for each step prevents the silence that causes late night confusion.

Teaching one database to speak the language of another.

When the source and destination technologies differ, the structure of the database, called the schema, and the code inside it must be translated. DMS provides conversion workspaces for this. When you create a workspace, an initial conversion happens automatically. Then an interactive SQL editor helps you review the result, fix issues and adjust the design to suit the destination. Gemini assisted conversion can help translate code objects such as stored procedures, functions and triggers, but its output must always be reviewed by people who understand the application.

Application changes

Besides the database code, the application’s own queries and connection settings may need changes. Plan developer time for this and include it in the schedule. It is often the largest part of a heterogeneous project.

Watch lag, status and errors so you know when it is safe to switch.

While a migration job runs, DMS shows its status and observability charts for items such as replication delay and storage usage, and many scenarios let you filter them per database. The most important signal is replication lag. If lag stays small and steady, the destination is keeping up. If it keeps growing, the destination, the network or the source is struggling.

Common causes of growing lag

A destination instance that is too small, a slow or congested network, very large transactions on the source, bursts of heavy writes, or a lack of indexes on destination tables can all cause lag to build. Address the cause rather than only waiting, because lag directly lengthens your downtime at cutover.

The moment of truth: proving the copy is right, then switching.

Validate before you switch

Check that the destination matches the source. Compare row counts for key tables, compare totals or checksums for important numbers such as account balances, and run sample queries on both sides. Run the application’s automated tests against the destination, and let a few real users or testers try typical tasks. Review the performance of the heaviest queries, because the destination may behave differently even when the data is identical.

The cutover steps

Cutover is the controlled switch of the application from the source to the destination. A typical sequence starts with a announcement and a quiet moment. The application is placed in read-only mode or stopped, so no new writes reach the source. You wait for replication lag to reach zero, confirming the destination has every change. Then you promote the migration job, which stops replication and makes the destination a standalone database. Finally you point the application to the destination and bring it back online.

flowchart TD
A["Announce window and freeze changes"] --> B["Stop or pause application writes"]
B --> C["Wait until lag reaches zero"]
C --> D["Validate counts and key data"]
D --> E["Promote the migration job"]
E --> F["Point application to destination"]
F --> G["Run smoke tests"]
G --> H{"All good?"}
H -->|Yes| I["Reopen to users and monitor"]
H -->|No| J["Execute rollback plan"]
        

Plan the way back

Before cutover, decide what you will do if something goes wrong. DMS does not support dual writing, which means writing to and reading from both the source and the destination at the same time. Once the application writes to the destination, the source falls behind. A rollback after real writes therefore needs a plan, for example keeping the source unchanged for a period, or replicating changes back with another tool. Decide this in advance, not in the middle of the incident.

Your data is most exposed while it travels, so protect the journey.

Encryption in transit

DMS migrates data securely using SSL and TLS certificates to encrypt network connections. Always enable encryption between source and DMS, particularly when the traffic crosses the public internet. Private paths such as VPN or Interconnect add another layer.

Encryption at rest and your own keys

Destination databases encrypt stored data. For continuous migrations, DMS supports customer managed encryption keys, so that you control the keys through Cloud KMS when regulations demand it.

Least privilege

The migration user on the source needs only the permissions required for reading data and change logs. People in your Google Cloud project should be given roles that allow them to create and manage migration jobs only if their work requires it. Remove access when the project ends.

The tool is only one piece of the migration budget.

Pricing for DMS has been structured so that homogeneous migrations carry no charge for the migration service itself, while heterogeneous migrations are billed based on the volume of data processed, with a monthly free allowance. Because pricing terms can change, check the current official pricing page before budgeting. Remember that DMS is only one cost. The larger numbers usually come from the destination database, the network and the people.

Where Database Migration Service earns its keep.

These are typical patterns rather than named customer stories, since company details and contracts change over time.

A focused tool with clear strengths and clear limits.

Troubleshooting is easier when you know the usual suspects.

Habits that make migrations boring, and habits that make them dramatic.

Patterns that work

Successful teams migrate in small waves, starting with low-risk databases so they learn the process. They rehearse the entire migration on a copy and measure timings. They automate repeatable steps with scripts and infrastructure as code. They separate the data migration from the application modernization, so there are fewer moving parts at once. They agree on cutover criteria in advance, such as lag below a threshold and all validation checks passed, and they write a rollback plan.

A checklist you can follow from the first meeting to the final shutdown.

Mistakes beginners make most often

The first is skipping the rehearsal. The second is under-sizing the destination. The third is promoting before lag reaches zero. The fourth is underestimating application changes in a heterogeneous migration. The fifth is forgetting that the source needs preparation before continuous replication can start. The sixth is leaving temporary access open when the work is done.

DMS is excellent at one job, and other tools handle neighboring jobs.

DMS is built to move relational databases into Cloud SQL and AlloyDB. For other goals, other Google Cloud services or approaches may suit better.

flowchart TD
Q1{"Is the destination Cloud SQL or AlloyDB?"} -->|No| OT["Use another tool such as Datastream or native tools"]
Q1 -->|Yes| Q2{"Is the source a supported engine?"}
Q2 -->|No| OT
Q2 -->|Yes| Q3{"Can the application stop for the whole copy?"}
Q3 -->|Yes| ON["One-time migration may be enough"]
Q3 -->|No| CO["Use continuous migration"]
        

It is a serverless Google Cloud service that migrates databases into Cloud SQL and AlloyDB for PostgreSQL, using an initial copy plus continuous replication so downtime stays small.

Not during a continuous migration. The source stays in use while data is copied and synchronized. You need a short pause only at the moment of cutover.

Common sources include MySQL, PostgreSQL, SQL Server and Oracle. Destinations are Cloud SQL and AlloyDB for PostgreSQL. Exact supported pairs and versions are listed in the documentation, so verify them first.

Homogeneous keeps the same database technology, such as MySQL to Cloud SQL for MySQL. Heterogeneous changes technology, such as Oracle to PostgreSQL, and needs schema and code conversion.

Yes, when configured correctly. DMS uses SSL and TLS to encrypt network connections, and continuous migrations support customer managed encryption keys.

It depends on data size, network speed, destination size and database activity. Small databases may finish in minutes or hours, while large ones can take days. A rehearsal gives the most reliable estimate.

Promote ends replication and turns the destination into a standalone primary database that your application can read and write. After promotion the source and destination are no longer kept in sync.

No. DMS does not support dual write. Plan your cutover so that writes move from the source to the destination at one clear moment.

It helps convert database schema and database stored code in heterogeneous migrations, with Gemini assisted suggestions. Your application’s own code and queries still need review and testing by your developers.

The job shows an error status. You read the message, fix the cause, such as connectivity or permissions, and restart or resume as the documentation allows. The source is not harmed, because DMS only reads from it.

Pricing has differed by migration style, with same-technology migrations typically carrying no service fee and heterogeneous ones billed by data volume above a free allowance. You still pay for the destination database and network. Check the current pricing page.

Monitor the new database closely, enable backups and high availability if not already on, tune performance, remove temporary access and migration jobs, and keep the source read-only for a safety period before retiring it.

Database Migration Service is Google Cloud’s serverless tool for moving relational databases into Cloud SQL and AlloyDB for PostgreSQL. It takes an initial snapshot, then keeps the destination in step using Change Data Capture, so your application can keep running until a short, controlled cutover. Success depends on choosing the right migration type, preparing the source, securing the network path, rehearsing, watching replication lag, validating carefully, and planning the way back. Treat the tool as the engine of the move and your own planning as the steering wheel.