Database Migration Service, often shortened to DMS, is a managed Google Cloud service for moving databases into Google Cloud’s managed database offerings.

Databases are the hardest part of any cloud move. Application servers are mostly replaceable, because you can start new copies from the same code. A database is different: it holds the accumulated memory of the business, it changes constantly, and it must never lose or corrupt a single record. Moving it with traditional tools usually means stopping the application, exporting everything, copying it, importing it, and starting again. For a large database, that downtime can last hours or days, which many businesses cannot accept.

DMS exists to shrink that downtime. It performs an initial copy of your data while the source database stays online, then continuously streams new changes to the destination until you are ready to switch. When you decide to cut over, the remaining gap is tiny. It also takes care of many chores that migrations normally require, such as setting up replication, monitoring progress, and, for some paths, converting the database’s structure and code from one engine to another.

What it is not

DMS is not a general-purpose data integration tool, and it is not a way to keep two databases synchronized forever. It is built for migration: a project with a beginning, a cutover moment, and an end. It targets Google Cloud’s managed relational databases, mainly Cloud SQL and AlloyDB. If you need ongoing replication into an analytics system, a different Google Cloud service is the right fit, and that comparison is covered later in this guide.

A small vocabulary explains every screen, message and decision in a migration project.

Each term below is defined by what it is, why it exists and where you meet it. Migration conversations move fast, and a shared vocabulary avoids expensive misunderstandings.

Replication lag

Replication lag is the delay between a change happening on the source and appearing on the destination. During continuous migration, lag should hover near zero. It is the single most useful number for deciding when it is safe to cut over, because a cutover with high lag means recent changes would be missing.

Whether you keep the same database engine or change it shapes the entire project.

A homogeneous migration keeps the same database engine, for example moving a MySQL database to Cloud SQL for MySQL, or a PostgreSQL database to Cloud SQL for PostgreSQL or AlloyDB. The data model, the query language and the stored code all stay the same. These migrations are comparatively simple because the main work is copying and keeping data in sync.

A heterogeneous migration changes the engine, for example moving an Oracle database to PostgreSQL on Cloud SQL or AlloyDB. Here the tables, data types, indexes, stored procedures and application queries all speak a different dialect, so the project needs conversion in addition to copying. These migrations are larger, riskier and more valuable, because they let organizations leave expensive commercial licenses.

Commonly supported examples

flowchart TD
  S["Start: existing database"] --> Q{"Same engine on destination?"}
  Q -- Yes --> H["Homogeneous path"]
  H --> H1["Prepare source and connectivity"]
  H1 --> H2["Create and run migration job"]
  Q -- No --> X["Heterogeneous path"]
  X --> X1["Create conversion workspace"]
  X1 --> X2["Convert and review schema and code"]
  X2 --> X3["Apply converted schema to destination"]
  X3 --> H2
        

DMS sits between your source and destination as a managed orchestrator and data mover.

You never install DMS on your servers. It is a Google-managed service that reaches out to your source database, reads data and change records, and writes them into the destination instance you prepared in Google Cloud. The service coordinates the stages, tracks progress, reports errors, and exposes controls such as start, stop and promote.

flowchart LR
  SRC["Source Database: on-premises or other cloud"] --> NET["Secure network path"]
  NET --> DMS["Database Migration Service"]
  DMS --> DST["Destination: Cloud SQL or AlloyDB"]
  CP1["Source connection profile"] -.configures.-> DMS
  CP2["Destination connection profile"] -.configures.-> DMS
  CW["Conversion workspace for heterogeneous jobs"] -.feeds schema.-> DST
  MON["Cloud Monitoring and Logging"] -.observes.-> DMS
        

The building blocks

Native tools under the hood

For homogeneous migrations, DMS generally builds on the database engines’ own proven replication and backup mechanisms instead of inventing a new one. This is a strength: it uses well understood technology and avoids exotic behavior. It is also why source prerequisites matter so much, because those mechanisms must be enabled and permitted on the source before DMS can use them.

A continuous migration has three main phases, and understanding each one removes most of the mystery.

DMS supports one-time jobs and continuous jobs. A one-time job copies a snapshot of the data and then finishes, so the application must stop writing during the project to avoid losing changes. A continuous job copies the snapshot and then keeps applying changes until you promote, which is how you achieve minimal downtime. Most production migrations use continuous jobs.

sequenceDiagram
  participant App as Application
  participant Src as Source Database
  participant DMS as Database Migration Service
  participant Dst as Destination Database
  App->>Src: Normal reads and writes continue
  DMS->>Src: Start full dump
  Src-->>DMS: Existing data
  DMS->>Dst: Load existing data
  Note over DMS,Dst: Phase 1: Full dump
  Src-->>DMS: Stream of new changes
  DMS->>Dst: Apply changes continuously
  Note over DMS,Dst: Phase 2: Change data capture
  App->>Src: Writes stopped for cutover
  DMS->>Dst: Apply final changes, lag reaches zero
  DMS->>Dst: Promote destination to primary
  App->>Dst: Applications now use destination
        

Why the order matters

The service must capture changes from the moment the dump begins, otherwise changes made during the dump would be lost. It does this by recording a starting position in the source’s change log, copying the data as it existed at that position, and then replaying everything that happened afterward. This is why the source must retain its change logs long enough, and why running out of retained log space during a long dump can break a migration.

Before any data moves, DMS must be able to reach your source safely.

Connectivity is where many migration projects stall. Your source database may sit behind firewalls, in a private data center, or in another cloud, and DMS must connect to it without exposing it unnecessarily. Several approaches exist, each with a different balance of simplicity, security and effort. The set of options and their names evolve, so verify the current list in the documentation.

flowchart LR
  OP["On-premises or other cloud database"] --> FW["Firewall"]
  FW --> VPN["VPN or Interconnect"]
  VPN --> VPC["Your Google Cloud VPC"]
  VPC --> DMS["Database Migration Service"]
  DMS --> DST["Cloud SQL or AlloyDB private address"]
        

Bandwidth is a project constraint

Moving data takes time proportional to size and network speed. A one terabyte database over a modest link may take many hours, while tens of terabytes can take days or weeks. Calculate this early, using realistic sustained throughput rather than the advertised link speed. If the initial copy would take too long, consider a faster link, a temporary bandwidth upgrade, or an offline seeding approach where available.

Encryption in transit

Whatever method you use, enable encrypted connections between DMS and the source, because migration traffic carries every row of your data. Use certificates where supported and keep credentials in a controlled location.

Most migration failures begin with a source that was not configured for replication.

Because DMS relies on the source’s own change records, the source must be configured to produce and keep them, and must grant a migration user the rights to read them. The exact settings depend on the engine and version, so follow the engine-specific checklist in the official documentation. The themes below describe what those checklists generally cover.

The restart problem

Some source settings, such as enabling change logs, require a database restart. A restart means a maintenance window on a production system, which needs scheduling, approvals and rehearsal. Discover this early in the planning phase, not on the day you intended to start the migration.

When the engine changes, the database’s structure and its code must be translated, not just copied.

Different database engines have different data types, different ways to express logic, and different built-in functions. An Oracle table column of one type may need a different type in PostgreSQL. A stored procedure written in Oracle’s procedural language must be rewritten in the destination’s language. DMS helps with this through conversion workspaces, which analyze the source, propose converted objects, and let you review and refine them before applying them to the destination.

flowchart TD
  A["Connect to source and read its schema"] --> B["Create conversion workspace"]
  B --> C["Automatic conversion of objects"]
  C --> D{"Everything converted cleanly?"}
  D -- Yes --> E["Review and apply to destination"]
  D -- No --> F["Fix unconverted items by hand or with assisted suggestions"]
  F --> G["Re-convert and re-check"]
  G --> D
  E --> H["Run data migration job"]
        

What gets converted

AI-assisted conversion

Google has added AI assistance to conversion workflows, which can suggest translations for code that rule-based conversion could not handle. Such suggestions speed up the work, but they are suggestions, not guarantees. Every converted routine must be reviewed by a person who understands the business logic and tested against realistic data. Treat the tool as a fast first draft, not a final answer.

Behavioral differences are the real risk

Even when code converts syntactically, engines can behave differently. They may treat empty strings and nulls differently, round numbers differently, order results differently without an explicit sort, handle dates and time zones differently, or lock rows differently under concurrent load. These differences produce bugs that tests with tiny data sets miss. Plan broad regression testing, including performance testing with production-sized data.

The quality of a migration is decided long before the first byte moves.

A good plan starts with a clear inventory and a clear definition of success. Without them, teams drift into surprises such as an unsupported feature discovered a week before cutover. A thorough assessment answers a handful of questions about the source, the destination and the business constraints.

Compatibility checks that often surprise teams

The destination must be ready to receive the data and handle production load afterward.

DMS can create the destination instance as part of the job or use one you prepared. Either way, you decide its size, storage, region, network placement, version and settings. These choices affect both the speed of the migration and the experience of the application afterward.

Sizing for two different moments

The destination faces two different demands. During the initial load, it must absorb a huge volume of writes quickly. During normal operation after cutover, it must serve production queries with the right balance of cost and performance. A common approach is to size generously during the migration so the load completes faster and the destination keeps up with change streams, then resize down once the workload is understood. Whether and how resizing is possible depends on the product, so check the options.

Region choice and latency

Place the destination in the region closest to the applications that use it. If applications will run in a different region than the database, every query pays extra latency, which can make an otherwise successful migration feel slower to users. Plan the application move and the database move together.

The cutover is the short, tense moment that the whole project exists to make safe.

Cutover is the act of switching applications from the old database to the new one. With continuous migration, the preparatory work is done and the actual switch is brief, but it demands precision. Everyone involved should know their role, the order of steps, the checks to run and the conditions for aborting.

The rollback question

After promotion, the destination accepts new writes that the source never sees. If you must return to the source, those writes would be lost unless you have a plan. A DMS job does not automatically replicate backward, so teams that need a safe fallback set up their own reverse replication or accept a defined window during which rollback is possible only by losing or manually replaying recent changes. Decide this in advance, and define the point of no return.

A migration that finishes without errors is not necessarily a migration that is correct.

Validation answers three questions: is all the data there, is it identical, and does the application still behave and perform correctly? Each question needs its own checks, and automated checks scale better than manual spot checks.

Tools for comparison

Google provides an open source Data Validation Tool that can compare data between sources and destinations at scale, and many teams write their own scripted checks in addition. The best validation approach compares both counts and values, and runs more than once: during the replication phase for confidence, and again just before cutover and after promotion.

Moving data that changes while you validate

During continuous migration the source keeps changing, so a comparison at one moment can show small differences that vanish seconds later. Design validation to tolerate this, for example by comparing at a quiet moment, comparing data older than the replication lag, or running the final authoritative comparison after writes are stopped at cutover.

Big databases stress every part of a migration: the network, the source, the destination and your patience.

Migration speed is limited by the slowest of several things: how fast the source can read, how fast the network can carry data, and how fast the destination can write and build indexes. Finding and relieving the actual bottleneck is the key to meeting your timeline.

Protecting production during the dump

The initial dump reads a great deal of data from the source, which can slow the live application. Where supported, using a replica of the source as the migration source moves that load away from the primary. Otherwise, schedule the dump for a quiet period, and monitor source health during the process.

Handling write-heavy sources

On very write-heavy databases, change volume can be so high that the destination struggles to keep up, leaving lag that never reaches zero. In such cases, increase destination capacity, look for unusually heavy tables, and rehearse to learn the true steady-state behavior before the real cutover.

Some engines are migrated by restoring backups, which changes how the process feels.

For some engines, notably SQL Server, migration commonly works by restoring database backups on the destination and then applying a series of later backups to bring it up to date. Instead of streaming a live change feed, the source produces full, differential and transaction log backups, which are placed in Cloud Storage and applied in order by DMS. The destination stays in a restoring state until you promote it.

What this means for planning

Backup-based migrations depend on an unbroken chain of backups. A missing or out-of-order backup breaks the chain. The size and frequency of log backups determines how small the final gap is, so frequent log backups shorten downtime. Teams must also manage the storage location, permissions and the discipline of the backup schedule throughout the project.

A migration moves your most sensitive data, so security must be designed in from the start.

Compliance during migration

Regulated data brings extra duties. Confirm that the destination region satisfies data residency requirements, that intermediate storage such as backup buckets is protected, and that the migration process itself, including temporary copies and logs, is included in your compliance scope. Document the controls so auditors can follow the story from start to finish.

Clean-up after the migration

Temporary resources become security debt if forgotten. After cutover and the safety period, remove migration users from the source and destination, delete tunnels and temporary VMs, close firewall openings, delete staging buckets and decommission the old database according to your data retention rules.

While a migration runs, a few signals tell you whether it is healthy.

DMS shows the status and phase of each job in the console and publishes metrics and logs to Google Cloud’s monitoring and logging services. Watching these signals, and setting alerts, lets you react quickly rather than discovering a stalled job hours later.

Common failure themes

Alerting

Set alerts on job failure, on replication lag above a threshold for a sustained time, and on destination resource pressure. During a planned cutover window, share a live dashboard with everyone involved so decisions are based on the same facts.

The migration service itself is only one part of the total cost of moving a database.

Pricing for DMS has varied by migration type, and Google has offered native, same-engine migrations at no additional charge for the service itself, while different-engine migrations have had separate pricing. Because this can change, confirm the current pricing page before budgeting. Regardless of the service fee, the migration project carries other real costs that often exceed it.

Cost components to budget

The savings side

Migrations are justified by what happens afterward. Managed databases reduce operational work such as patching and backups, and moving from commercial licensed engines to open source engines can lower license costs significantly. Compare the one-time project cost with the ongoing savings over several years to judge the return, and include avoided hardware refresh costs in on-premises cases.

Experienced teams repeat a handful of habits, and avoid a handful of traps.

Patterns that work well

Anti-patterns to avoid

DMS is one of several ways to move data, and each way fits a different goal.

How to choose

Start from the destination. If you want a managed Cloud SQL or AlloyDB database and your source is supported, DMS is usually the first thing to evaluate. If you want the data in an analytics warehouse, a change capture service is a better match. If you must keep running your own database software, moving the virtual machine may be simpler. If your downtime tolerance is generous and the database is small, a plain dump and restore may be enough and the least complex.

A short checklist separates calm migrations from stressful ones.

Best practices

Common mistakes

Concrete stories show how the ideas fit together in real projects.

Short answers to the questions teams ask most when planning a migration.

With a continuous migration, downtime is usually limited to the cutover window: stopping writes, letting the last changes arrive, promoting, and repointing applications. That is often minutes, but the real figure depends on your size, change rate and rehearsed process. Backup-based and one-time migrations can involve longer windows.

Yes, in continuous migrations the source keeps serving the application during the dump and change capture. The dump does add read load, so plan it for quiet hours or use a replica as the source where supported.

Yes, for supported combinations, such as certain commercial engines to PostgreSQL targets, using conversion workspaces. These projects need schema and code conversion plus thorough testing. Check current support for your exact engines and versions.

Promote ends replication and turns the destination into an independent, writable database. After promotion, new writes go only to the destination, so do it after stopping writes on the source and confirming replication has caught up.

Not automatically. The job does not replicate changes back to the source. Plan a rollback approach in advance, such as setting up reverse replication yourself or limiting the window in which rollback is possible, and decide the point of no return.

Not always. Replication focuses on data and some structure. Database users, privileges, sequence values, scheduled jobs and certain engine-specific objects often need explicit handling. Check the current documentation for your engine and make a checklist.

Validate at several levels: structure, row counts, content comparison, application tests and performance tests. Tools such as Google’s open source Data Validation Tool can help automate comparisons.

Common causes are firewall rules, an incomplete tunnel or private link, wrong credentials, or missing encryption settings. Verify the network path from the Google Cloud side and re-run the test after each change.

No. DMS is built to migrate databases into Cloud SQL and AlloyDB and finishes with a cutover. Datastream provides serverless change data capture for ongoing replication into destinations such as analytics warehouses and storage.

Inventory your databases and check compatibility with your chosen destination, then run a pilot with the job test on a small, low-risk database. Early discoveries are cheap and shape a realistic plan.

Database Migration Service turns one of the riskiest parts of a cloud move into a guided, repeatable process. It copies existing data, follows ongoing changes, and lets you promote the destination with a short pause, while handling the machinery of replication and, for different engines, conversion. It moves databases into Google Cloud’s managed relational services and leaves you free to focus on planning, validation and the application changes around the database.

Success depends less on the tool and more on discipline. Assess compatibility early, prepare the source and connectivity, size the destination for the work, rehearse with real data, validate at multiple levels, and write a cutover runbook with a defined rollback stance. Teams that treat cutover as a rehearsed routine finish quickly and quietly. Teams that improvise on the final day learn expensive lessons.