Database Migration Service, usually shortened to DMS, is Google Cloud’s managed tool for moving databases into Google Cloud.

A database is an organized collection of information, such as customer names, orders, bank balances or student marks. Applications read from it and write to it all day long. When a company decides to run that database on Google Cloud instead of in its own server room, someone has to copy every table, every row and every rule across safely. Doing that by hand is slow, risky and stressful.

DMS does the heavy lifting for you. It is a fully managed service, which means Google runs and watches the machinery that performs the copy. You do not create migration servers, you do not size them, and you do not patch them. You describe where your data lives today, where you want it to live tomorrow, and DMS takes care of the transfer, including the schema, the metadata and the data itself.

Where DMS fits in the Google Cloud family

DMS does not store your data for the long term. It is a bridge, not a destination. The destinations are Google Cloud databases, mainly Cloud SQL (Google’s managed MySQL, PostgreSQL and SQL Server) and AlloyDB for PostgreSQL (a high-performance PostgreSQL-compatible database). Once the migration is finished, DMS steps away and your applications talk directly to the new database.

Understanding the motivation makes every later design choice easier to follow.

Nobody migrates a database for fun. A database is usually the most sensitive part of any system, because losing or corrupting data is far worse than a slow web page. Teams migrate only when the benefits clearly outweigh the risks. Knowing the common reasons helps you choose the right strategy.

What makes migration hard?

The first difficulty is size. Databases can hold terabytes, and copying that much data takes hours or days. The second difficulty is change. While you copy, customers keep creating new records, so the copy is out of date the moment it finishes. The third difficulty is difference. If the old and new database engines speak slightly different dialects, the structure itself must be translated.

Before going deeper, let us define every word you will meet in the console and the documentation.

The single most important classification in DMS is whether the database engine changes during the move.

A homogeneous migration keeps the same database engine. For example, you move a MySQL database into Cloud SQL for MySQL. The language the database speaks stays the same, so the structure and code carry over directly.

A heterogeneous migration changes the engine. A classic example is moving an Oracle database into PostgreSQL. Oracle and PostgreSQL use different data types, different built-in functions and different procedural languages, so the structure and code must be converted before data can flow.

Your second big choice is how long the source and destination stay in sync.

A one-time migration performs a full dump and load only. It copies everything that exists at that moment and then stops. It does not follow later changes, so you need to stop writes on the source during the process to avoid losing data. This is a good fit for small databases, test environments, or systems that can tolerate a maintenance window.

A continuous migration starts with the same full dump, but then it keeps listening to the source’s change log and applying every change to the destination. The two databases stay almost identical until you decide to switch. Because the final switch only needs to wait for a tiny backlog, downtime can shrink from hours to minutes.

DMS supports a defined list of engines, versions and hosting locations, and the list changes over time.

The destination side is deliberately narrow. DMS moves data into Google Cloud, specifically into Cloud SQL and AlloyDB for PostgreSQL. It is not a general-purpose tool for moving data out of Google Cloud or between two other clouds.

Let us look at the building blocks that appear when a migration runs.

At the highest level, there are four players. The source database holds the original data. DMS acts as the coordinator and data mover. A network path connects the source to the destination. The destination database receives the data. Everything you configure in the console is really about describing these four players and the road between them.

flowchart LR
  A["Source database on-premises or other cloud"] --> N["Secure network path"]
  N --> D["Database Migration Service"]
  D --> T["Destination Cloud SQL or AlloyDB"]
  D --> M["Monitoring and logs"]
  C["Conversion workspace for cross-engine moves"] --> T
        

In the diagram, notice that the conversion workspace connects to the destination, not to the data stream. The workspace prepares the structure of the new database, while the migration job fills it with data. These are two related but separate activities.

The components in plain words

Every continuous migration follows the same story: copy, catch up, switch.

When you start a continuous migration job, DMS first records a consistent starting point in the source’s change log. It then performs the full dump, copying the existing data to the destination. While the dump runs, the source keeps accepting writes, and those writes are safely recorded in the log.

After the dump finishes, DMS switches into change data capture mode. It reads the recorded changes from the log in order and applies them to the destination. At first there may be a backlog, but the destination quickly catches up, and from then on the gap between the two systems is measured in seconds or less.

sequenceDiagram
  participant App as Application
  participant Src as Source database
  participant DMS as Migration job
  participant Dst as Destination database
  App->>Src: Normal reads and writes
  DMS->>Src: Mark starting point in change log
  DMS->>Src: Read existing data
  DMS->>Dst: Load full dump
  App->>Src: More writes continue
  DMS->>Src: Read new changes
  DMS->>Dst: Apply changes in order
  App->>Dst: After promotion, app points here
        

A migration job moves through recognizable phases, and knowing them helps you read the console correctly.

A job begins as a configuration that has not yet started. Once you start it, it enters the full dump phase. When the dump completes, continuous jobs move into change data capture and stay there for as long as you wish. One-time jobs behave differently: after the dump, they reach a state described in the documentation as ready for promote, because there are no changes left to follow.

Promotion is the last meaningful action. It tells DMS to stop replication and convert the destination into a standalone database that your applications can write to. After promotion, the link between old and new is cut, and the old source no longer receives updates.

flowchart TD
  A["Job created"] --> B["Full dump running"]
  B --> C{"Migration type"}
  C -->|"Continuous"| D["Change data capture running"]
  C -->|"One-time"| E["Ready for promote"]
  D --> F["Lag near zero and checks passed"]
  F --> G["Promote"]
  E --> G
  G --> H["Destination is independent and writable"]
        

Why replication lag is the number to watch

Replication lag is the delay between something happening on the source and the same thing appearing on the destination. A small, steady lag means the destination is healthy. A growing lag means the destination cannot keep up, often because it is under-sized or the source is receiving unusually heavy writes.

Choosing the right network method is often the longest conversation in a migration project.

DMS offers several ways for the destination to reach your source. The right choice depends on where the source lives, how sensitive the data is, how big the migration is and how much network setup your organization permits. Understanding the trade-offs early prevents painful rework later.

flowchart LR
  S["On-premises source"] --- V["VPN or Interconnect"]
  V --- P["Your Google Cloud VPC"]
  P --- X["Peering or Private Service Connect"]
  X --- D["Destination database"]
        

When the engine changes, the structure and code must be translated before data can move.

An Oracle database often contains thousands of objects: tables, indexes, views, sequences, packages, functions and stored procedures. Each has Oracle-specific syntax. A conversion workspace is an interactive area in DMS where these objects are converted into PostgreSQL syntax, reviewed, fixed and then applied to the destination.

Conversion happens in rounds, not all at once. You add a group of objects, run the conversion, read the issues, fix them and test in the destination. Then you add the next group. This staged approach keeps a huge conversion manageable, and it lets different people work on different areas.

Conversion is usually the largest chunk of effort in a heterogeneous project, not the data copy. Experienced teams start conversion early, run it repeatedly and treat remaining issues as a backlog to be tracked sprint by sprint.

Most failed migrations fail during preparation, not during the migration itself.

Preparation has two halves. On the source, you prepare for access and for change tracking. On the destination, you prepare capacity and connectivity. Doing both carefully before pressing start saves days of troubleshooting.

Source preparation

The source must allow the destination to connect, and for continuous migrations it must expose a change log in the format DMS understands. This usually means changing database configuration settings, which may require a restart in some engines. A dedicated migration user with only the permissions needed is better than reusing an administrator account.

Destination preparation

The destination should have enough compute and memory to handle the full dump and the live changes at the same time. Many teams scale the destination up during migration and scale it back down afterwards. Storage should have headroom, because the migrated data plus indexes and logs can be larger than expected.

You are moving your most valuable asset, so security must be designed in from the start.

Security in a migration has four layers: who may operate the migration, how the data travels, how the data is protected at rest, and how credentials are handled. Each layer has its own tools.

Credentials and cleanup

The migration user on the source holds powerful read access, so treat its password like a key to the vault. Use a unique password, limit its network access, and remove or disable the account when the migration is complete. Delete connection profiles and jobs you no longer need, because they hold connection details.

Data residency and compliance

Because DMS is regional, you choose exactly where the destination data will live. This matters for regulations that restrict where personal data may be stored. Confirm the region choice with your compliance team before building anything.

A migration you cannot observe is a migration you cannot trust.

DMS shows job status and progress in the console, and it integrates with Google Cloud’s logging and monitoring tools. During the full dump phase, you mainly watch progress and errors. During change data capture, you mainly watch replication lag, because lag tells you how far behind the destination is.

What to alert on

Set alerts for jobs that fail, for lag that grows beyond a threshold you define, and for destination resource pressure such as high CPU or low disk space. Alerts let you react at night or on weekends without staring at a screen.

Verifying completeness

Monitoring tells you the process is healthy, but it does not prove the data is correct. Validation is a separate step. Compare row counts between source and destination, compare checksums or sampled records for critical tables, and run business-level checks such as totals of orders or balances.

Cutover is the short, careful moment when production traffic changes address.

Cutover is where all the preparation pays off. Because continuous migration keeps the destination almost current, the cutover itself can be a quick, scripted event. The key is to treat it like a rehearsed procedure rather than an improvisation.

flowchart LR
  A["Application writes to source"] --> B["Pause writes"]
  B --> C["Drain remaining changes"]
  C --> D["Promote destination"]
  D --> E["Application writes to destination"]
        

Plan the way back

Before promotion, decide what happens if the new database misbehaves. After promotion, the old source no longer receives new writes, so a rollback means either returning to a stale source or building a reverse path. Many teams keep the source untouched and read-only for a defined period, and decide in advance how long that period lasts.

Every tool has edges, and knowing them in advance turns surprises into planned work.

DMS publishes known limitations for each migration path. They cover data types, object types, database sizes and behaviors during replication. The exact list differs between MySQL, PostgreSQL, SQL Server and Oracle paths, so you must read the one matching your scenario. Several patterns appear again and again.

The pricing model is simple in principle, but the total bill includes more than the DMS line.

For homogeneous migrations into Cloud SQL or AlloyDB for PostgreSQL, Google offers DMS at no additional charge. You still pay for the destination database itself and for related resources such as storage or network. For heterogeneous migrations, pricing is based on gigabytes processed, split into two parts: the backfill of existing data and the change data capture of ongoing changes.

Google’s pricing documentation describes a monthly free allowance for backfill and then a per-gigabyte rate above it, and rates vary by region and volume tier. Because prices are updated over time, always confirm current numbers on the official pricing page and use the pricing calculator for your region.

Teams that succeed repeat a few habits, and teams that struggle repeat a few mistakes.

Helpful patterns

Anti-patterns to avoid

A short checklist of habits that experienced migration teams share.

Ownership and communication

Migrations touch many teams: database administrators, application developers, network engineers, security staff and business owners. Name one person who owns the overall plan and keep a shared checklist. Announce the cutover window early, and tell support teams what to watch for afterward.

These typical situations show how the ideas fit together in practice.

The common thread in all of these is preparation. Success depends less on clever tooling and more on clear scoping, honest testing and a calm, practiced cutover.

Every major cloud has its own migration service, and each is built around its own destination.

Amazon Web Services and Microsoft Azure also offer database migration services, and all three promise low-downtime replication into their own platforms. They differ in supported engines, pricing models and tooling. A simple way to choose is to look at where you want to land: the best migration service is usually the one native to your destination.

The tool is only one piece; a good project plan decides whether the migration feels calm or chaotic.

Many beginners open the console and start creating profiles on day one. Experienced teams do the opposite. They spend the first weeks understanding what they own, what depends on what, and what could go wrong. DMS makes the technical copy easier, but it cannot tell you which databases matter most, who must approve the cutover, or which application quietly reads a table nobody remembers.

Start with an inventory

List every database you intend to move. For each one, record the engine and version, the approximate size, the daily growth, the peak write rate, the applications that use it and the people who own it. This list is your map. Without it, surprises appear late, such as a reporting tool that connects directly to the old server and breaks the moment the address changes.

Group databases into waves

If you have many databases, do not move them all at once. Group them into waves. Put small, low-risk systems in the first wave so the team learns the process cheaply. Put the most critical and complex systems in later waves, after the runbook has been tested several times. Each wave teaches you something that makes the next wave safer.

Define who does what

Agree on go or no-go criteria

Before the cutover night, write down exactly what must be true to proceed. For example: replication lag stays under a defined number of seconds, validation reports show no unexplained differences, test teams have signed off, and rollback steps have been reviewed. Written criteria stop emotional decisions at midnight.

Two questions arrive in every planning meeting: how big should the new database be, and how long will the copy take?

Neither question has a single formula, because the answer depends on your own data and your own network. What you can do is understand the factors that matter, measure them in a rehearsal and then decide with evidence instead of guesses.

flowchart LR
  A["Source read speed"] --> B["Network bandwidth and latency"]
  B --> C["Migration service processing"]
  C --> D["Destination write speed"]
  D --> E["Index building and storage"]
        

Factors that influence duration

Sizing the destination

A sensible habit is to size the destination for the busiest moment of the migration, not for the average day. During the full dump the destination is loading data quickly. During change capture it must replay changes at least as fast as they arrive. If either role is starved of resources, lag grows. After cutover, you can compare real production metrics and shrink the instance if it is oversized.

Storage planning

Storage needs include the migrated data, indexes, temporary files and logs. A common beginner surprise is that the destination uses more space than the source reports, especially when the engines store data differently or when many indexes are created. Leave generous headroom, and enable automatic storage growth where it is available so a long migration does not stop on a full disk.

The MySQL to Cloud SQL for MySQL route is the classic homogeneous migration, and its ideas repeat in other paths.

MySQL records every change to data in a special file called the binary log. Think of it as a diary that lists every insert, update and delete in the order it happened. For continuous migration, DMS relies on this diary. After the full dump, it reads the diary from the starting position and replays each entry on the destination.

What the source needs

Managed sources need parameter changes

If the source is Amazon RDS or Aurora, you cannot edit server files directly. Instead you change settings through the provider’s parameter configuration and sometimes reboot the instance. Plan this carefully, because a reboot on a busy production database is itself an outage.

Version and feature considerations

For MySQL, the destination should be the same major version as the source or one version higher. Moving to a much newer version in one jump, or to an earlier version, is not recommended. The newest destination versions can come with extra limitations, for instance around certain backup-file based loading methods, so read the notes for your chosen version.

Character sets, collations and time zone settings deserve a quick check. If the old server used unusual settings, text comparison or sorting could differ on the destination. Compare settings early and test a sample of text-heavy queries.

Initial load choices

DMS supports different ways of performing the initial load for MySQL, including a logical approach that reads data through database connections and, in some scenarios, an approach that works from physical backup files. Each has its own prerequisites and limitations, and the choice influences speed and compatibility. For very large databases, physical approaches can be faster, but they require more preparation.

PostgreSQL uses a different change-tracking idea, and its details explain several of the limitations you saw earlier.

PostgreSQL writes every change first to a write-ahead log, a durable journal that exists mainly for crash recovery. Logical replication takes information from that journal and presents it as row-level changes that another system can consume. DMS uses this approach to follow a PostgreSQL source during continuous migration.

Why primary keys matter so much

To change a row on the destination, the system must say which row. A primary key is the unique name tag of a row. When a table has no primary key, the system cannot reliably point to a single row for an update or delete. That is why the documentation notes that tables without primary keys support the initial snapshot and inserts, while updates and deletes need manual handling.

Whole-server migration

The PostgreSQL path moves the entire server, meaning every database within it. This is a different mindset from picking individual tables. Before you start, review all databases on the source and decide whether any should be cleaned up, archived or excluded through other means.

Things that are not carried automatically

Choosing between Cloud SQL and AlloyDB

Both are PostgreSQL-compatible and both are supported destinations. Cloud SQL is the familiar, general-purpose managed service. AlloyDB is aimed at demanding workloads that need higher performance and scale. Because DMS supports both, you can choose based on workload needs and budget rather than on tool limitations. Networking differs slightly, since AlloyDB uses private services access, so review the connectivity rules for your choice.

This is the most demanding scenario because two things change at once: the engine and the dialect of your code.

An Oracle environment often contains decades of accumulated logic. Tables are only the beginning. Business rules live in packages, triggers and procedures written in Oracle’s own procedural language. Moving to PostgreSQL means translating that logic, not just the data. This is why the conversion workspace is central, and why timelines for this path are longer.

How change tracking works here

Oracle tracks changes using a system change number, a counter that increases with every committed transaction. DMS uses information from Oracle’s log files to follow changes after the initial load. For this to work, the source must be configured to keep the needed logging information. If you perform the full load yourself outside DMS, you can supply a starting change number so replication begins at the correct point.

Typical translation challenges

Using Gemini assistance wisely

DMS conversion workspaces include Gemini-assisted workflows that can explain what a piece of code does and suggest fixes for conversion problems. This can save time on unfamiliar legacy code. However, treat suggestions as drafts from a helpful colleague, not as verified answers. Every converted object still needs review and testing by someone who understands the business rule behind it.

flowchart TD
  A["Oracle source objects"] --> B["Conversion workspace"]
  B --> C["Automatic conversion"]
  C --> D{"Issues found"}
  D -->|"Yes"| E["Review and fix, optionally with Gemini help"]
  E --> B
  D -->|"No"| F["Apply schema to destination"]
  F --> G["Migration job loads data and follows changes"]
        

Testing is how you turn hope into confidence.

A successful migration job proves only that data moved. It does not prove that the data is right, that your application works, or that performance is acceptable. A complete strategy tests several different things, and each answers a different question.

Reconciliation in practice

Start with simple counts per table. Then compare aggregated business values such as total order amount per day or customer count per region. For critical tables, compare checksums or sample specific records in full. Remember that a continuous migration is a moving target, so run comparisons when lag is minimal, or compare data older than a safe cutoff time.

Parallel run for critical systems

For high-stakes systems, some teams run a parallel period. The application continues to use the source, while a copy of its traffic or its reports are run against the destination and the results are compared. Differences point to conversion bugs or compatibility problems without any customer impact.

flowchart LR
  A["Rehearsal migration"] --> B["Structure and data checks"]
  B --> C["Functional and performance tests"]
  C --> D{"All criteria met"}
  D -->|"No"| E["Fix and repeat"]
  E --> A
  D -->|"Yes"| F["Approve production cutover"]
        

Problems are normal, and most of them fall into a few families.

When a job misbehaves, resist the urge to change many things at once. Work from the outside in: first the network, then permissions, then source configuration, then destination health, and finally data-specific issues. Each check is cheap and rules out a whole category.

Escalating effectively

If you contact support, gather the migration job name, region, project, timestamps, the exact error text and a description of what changed recently. Good evidence shortens the conversation dramatically.

Promotion is not the end; the first weeks on the new database decide whether the project feels like a success.

Once the application runs on the destination, a new phase begins. You are no longer a migration team; you are the operators of a new production system. This phase includes tuning, protection and cleaning up everything that was only needed temporarily.

Capture lessons learned

Hold a short review soon after the project. Record what went well, what surprised you, how long each phase really took and which checks caught real problems. Store the runbook and these notes where the next team can find them. If you have more waves of databases to migrate, this knowledge makes them cheaper and safer.

Take advantage of the new platform

Moving the database is a doorway, not the destination. Once stable, explore capabilities that were hard on the old platform: easier read replicas, integrated monitoring, stronger identity controls, automated backups across regions and tighter links to analytics services. Introduce these gradually, one change at a time, just as you did with the migration itself.

Moving one database is a project, but moving fifty is a factory, and factories need standard procedures.

Large organizations rarely have a single database. They have dozens or hundreds, owned by different teams, running different engines and serving applications of very different importance. If every migration is handled as a one-off craft project, the program becomes slow, expensive and inconsistent. The better approach is to build a repeatable process once and then run many databases through it.

Build a standard runbook

A runbook is a written, step-by-step procedure that anyone on the team can follow. It lists the preparation checks, the settings to choose, the validation steps, the cutover sequence and the rollback conditions. After each wave, improve the runbook with what you learned. Over time it becomes a trusted document rather than a pile of personal memories.

Use consistent naming and labels

When many connection profiles and migration jobs exist in the same project, names matter. Agree on a naming pattern that shows the application, the environment and the wave, so that anyone can see at a glance what a job belongs to. Labels and tags also help with cost tracking and with finding leftovers during cleanup.

flowchart LR
  A["Inventory and classify"] --> B["Plan waves"]
  B --> C["Run standard process"]
  C --> D["Retrospective"]
  D --> E["Improve runbook"]
  E --> C
        

Governance and compliance

At scale, rules matter. Decide which regions are allowed, which connectivity methods are approved, how encryption keys are managed and how long temporary access can remain open. Organization policies and Identity and Access Management groups help enforce these decisions automatically instead of relying on memory. Keep an audit trail of who started, changed and promoted each job, because regulated industries often must show it.

Watch the money across the program

Costs add up when many databases run through heterogeneous paths or when many destination instances are scaled up at once. Track spending by project or label, set budget alerts and make sure finished migration resources are removed promptly. Reviewing costs after each wave prevents unpleasant surprises at the end of the program.

Not during the copy. With a continuous migration your application keeps running on the source. You only need a short pause for the final cutover, when you stop writes, drain the last changes and promote.

For native homogeneous migrations into Cloud SQL or AlloyDB for PostgreSQL there is no additional DMS charge, although you pay for the destination. Heterogeneous migrations are billed by data volume. Always check the official pricing page for current figures.

No. DMS moves data into Google Cloud destinations. It is not intended for moving data out or between other platforms.

A connection profile describes how to reach one database. A migration job connects a source profile to a destination, chooses the migration type and runs the process.

No. Conversion workspaces are for cross-engine migrations such as Oracle to PostgreSQL. Same-engine migrations carry the structure over directly.

Promotion stops replication and turns the destination into an independent, writable database. After that, the source no longer feeds it.

Check whether the destination is under-sized, whether the source is receiving unusual write volume, and whether network bandwidth is a bottleneck. Scaling the destination up is often the quickest fix.

It is not always required, but it is strongly advised for production and sensitive data. Public IP allowlists are mainly suited to quick proofs of concept.

It depends on the migration path. Some paths let you select what to include, while the PostgreSQL path migrates the whole server. Check the scenario documentation for your path.

Not automatically. After promotion the source stops receiving changes, so plan your rollback approach before cutover and decide how long to keep the source available.

Compare row counts, checksums and business totals, and review the completeness guidance for your path, including any items that need manual migration.

Reading the full dump and following the change log adds load to the source. For most systems the effect is modest, but a very busy or fragile server can feel it. Test during rehearsal, watch source CPU, memory and input and output activity, and schedule the heaviest phase for quieter hours when you can.

There is no fixed rule. Some teams cut over within a day, while others keep replication running for weeks so testers can validate against fresh data. Remember that a running job consumes resources and, for heterogeneous paths, accumulates usage charges, so keep the period purposeful.

Yes, before promotion you can usually discard the destination data and start over, which is exactly why rehearsals are cheap. After promotion the destination holds live business data, so a restart would need careful planning to avoid losing new records.

For homogeneous migrations you usually only change the connection address and credentials, although you should still test drivers and settings. For heterogeneous migrations expect code changes, especially where queries use features specific to the old engine.

Begin with a small test database using a homogeneous path, such as MySQL or PostgreSQL to Cloud SQL, with a simple connectivity method. Run a continuous job, watch lag, promote the destination and then clean everything up. That single exercise teaches nearly every concept in this guide.

It is designed for production-scale migrations, but very large databases need careful planning of network bandwidth, destination size and the initial load method. Rehearse with realistic data volumes and use private, high-bandwidth connectivity for the best results.

Promotion is an important, hard-to-reverse step, so restrict it to a small group of trusted operators through Identity and Access Management, and require the written go or no-go criteria to be met before anyone presses the button.

Trust the official documentation. Supported versions, limitations, pricing and console behavior change over time, and an article can only be correct as of the day it was written. Use guides like this one to understand concepts, and use the official pages to confirm details.

Google runs and manages the migration machinery for you, in the region you choose. You do not see or maintain those servers. What you manage are the source, the destination, the network path and the configuration that connects them.

Google Cloud Database Migration Service turns a risky, manual project into a guided, managed process. It copies your existing data, follows every new change, and lets you switch over in a brief, well-planned moment. The technology is only half of the story; the other half is preparation, testing and communication. If you pick the right migration type, build a safe network path, validate your data and rehearse your cutover, you can move even large, busy databases with confidence.