Database Migration Service for heterogeneous SQL Server to AlloyDB for PostgreSQL
Stay organized with collections
Save and categorize content based on your preferences.
With Database Migration Service, you can convert your SQL Server database schema,
tables, and code objects to PostgreSQL syntax, and then migrate
data from your SQL Server databases to AlloyDB for PostgreSQL.
Database Migration Service offers support for multiple different SQL Server
sources, including Amazon RDS, Microsoft Azure SQL Managed Instance, and self-managed SQL Server
instances.
This page provides an overview of the key Database Migration Service features
for heterogeneous SQL Server to AlloyDB for PostgreSQL migrations:
Code and schema conversion describes how Database Migration Service
can help you convert your schemas, tables, and other objects from
SQL Server syntax to PostgreSQL syntax.
Continuous migrations data flow provides an end-to-end overview
of how your data moves in Google Cloud during the migration process.
Monitoring
gives an introduction for logs and metrics that can
help you observe the progress and health of your migration job.
Migration security looks at encryption features offered by
Database Migration Service.
Supported source and destination databases
The following table lists all supported SQL Server source and destination databases:
Source databases
Destination databases
Amazon RDS for SQL Server
AlloyDB for PostgreSQL 14, 15, 16
Microsoft Azure SQL Managed Instance
Microsoft Azure SQL Database tier S3 and above
Cloud SQL for SQL Server
Self-managed SQL Server versions:
Enterprise 2008 and later, Standard 2016 SP1 and later, Developer 2008 and later
(on premises or on any cloud VM that you fully control)
Unsupported source databases
Database Migration Service doesn't support migrating from the following SQL Server versions:
SQL Server Standard edition versions from 2008 to 2014
SQL Server Express
SQL Server Web
Code and schema conversion
Database Migration Service conversion workspaces provide an interactive editor experience
where you can convert your schemas, tables, and other objects from
SQL Server syntax to PostgreSQL syntax.
Interactive conversion workspaces also provide support for Gemini
assisted workflows with code explainability and conversion issue fixing.
For heterogeneous SQL Server migrations to PostgreSQL,
Database Migration Service supports the continuous migration flow. In this approach,
your data is first loaded from a full dump, and then continuously updated based on
data change information surfaced from change tables.
Figure 2. Data movement during Database Migration Service for
SQL Server heterogeneous migrations. (click to enlarge)
At a high level, your data moves through the migration phases as follows:
You use Database Migration Service conversion workspace to convert your schemas,
tables, and other objects from SQL Server syntax to PostgreSQL syntax.
SQL Server databases can often have several thousand objects
whose schema you need to convert. With Database Migration Service, you can divide your
work into multiple phases. Database Migration Service can connect to your source
databases and pull the required schema information when needed.
When you finish translating all your entities to PostgreSQL syntax,
you apply the schema to the databases in the destination cluster.
The goal of this stage is to prepare your destination databases so that
Database Migration Service can later replicate the data from source tables to their
correct equivalents in AlloyDB for PostgreSQL.
Once your schema is applied, you can begin the data migration.
The full dump phase is the first part of the migration process. During
full dump, Database Migration Service connects to your source instance, reads the contents
of the tables you selected for migration, and then loads the data to the
AlloyDB for PostgreSQL destination cluster.
In this phase, Database Migration Service captures actual contents of your database.
When the full dump phase is over, Database Migration Service switches to the
change data capture (CDC) phase. During CDC, Database Migration Service keeps monitoring
your source databases for changes, and then continuously replicates them on the
destination cluster.
In this phase, Database Migration Service doesn't copy actual data from your source
tables: instead, it reads information extracted from dedicated change tables
to replicate changes in the destination. For more information about this
mechanism, see
Change Data Capture.
You can stop the ongoing replication and promote the migration job when you want
to switch your application so that it uses the AlloyDB for PostgreSQL
destination cluster as the production database. For a detailed, step-by-step
migration guide, see
SQL Server to AlloyDB for PostgreSQL migration guide.
Monitoring
Figure 2. Sample observability diagram in Database Migration Service.
(click to enlarge)
Database Migration Service provides extensive logging and observability capabilities
to help you monitor the migration progress. These features include real-time
diagnostics for replication delay and CDC progress,
as well as detailed logs for AlloyDB for PostgreSQL destination cluster health
and migration job state.
Database Migration Service provides multiple encryption mechanisms you can use
for additional security during the migration process. These mechanisms include:
SSL/TLS certificates for encrypting the network connections between
Database Migration Service and source databases. For more details, see
Encryption overview.
Encryption certificates for securing data movement during full dump and CDC
phases. For more details, see
CMEK for migration jobs.
What's next
To learn more about SQL Server data type and feature support in
Database Migration Service, see
Known limitations.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[[["\u003cp\u003eDatabase Migration Service facilitates the conversion of SQL Server databases, including schemas, tables, and code objects, to PostgreSQL syntax for migration to AlloyDB for PostgreSQL.\u003c/p\u003e\n"],["\u003cp\u003eThis service supports multiple SQL Server sources like Amazon RDS, Microsoft Azure SQL Managed Instance, and self-managed instances, allowing continuous migration data flow.\u003c/p\u003e\n"],["\u003cp\u003eIt provides an interactive conversion workspace for converting SQL Server elements to PostgreSQL and includes features like Gemini-assisted workflows for code explainability and issue fixing.\u003c/p\u003e\n"],["\u003cp\u003eThe migration process involves a full dump phase followed by a change data capture (CDC) phase, ensuring continuous data replication from the source to the destination.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service offers robust monitoring and security features, including logging, observability capabilities, SSL/TLS certificates, and encryption certificates for secure data transfer.\u003c/p\u003e\n"]]],[],null,["# Database Migration Service for heterogeneous SQL Server to AlloyDB for PostgreSQL\n\nWith Database Migration Service, you can convert your SQL Server database schema,\ntables, and code objects to PostgreSQL syntax, and then migrate\ndata from your SQL Server databases to AlloyDB for PostgreSQL.\nDatabase Migration Service offers support for multiple different SQL Server\nsources, including Amazon RDS, Microsoft Azure SQL Managed Instance, and self-managed SQL Server\ninstances.\n\nThis page provides an overview of the key Database Migration Service features\nfor heterogeneous SQL Server to AlloyDB for PostgreSQL migrations:\n\n- [Supported sources and destinations](#supported-src-and-dest) lists all SQL Server\n versions supported by Database Migration Service.\n\n- [Code and schema conversion](#conversion) describes how Database Migration Service\n can help you convert your schemas, tables, and other objects from\n SQL Server syntax to PostgreSQL syntax.\n\n- [Continuous migrations data flow](#data-flow-migration-types) provides an end-to-end overview\n of how your data moves in Google Cloud during the migration process.\n\n- [Monitoring](#monitoring)\n gives an introduction for logs and metrics that can\n help you observe the progress and health of your migration job.\n\n- [Migration security](#securing-migration-jobs) looks at encryption features offered by\n Database Migration Service.\n\nSupported source and destination databases\n------------------------------------------\n\nThe following table lists all supported SQL Server source and destination databases:\n\nUnsupported source databases\n----------------------------\n\nDatabase Migration Service doesn't support migrating from the following SQL Server versions:\n\n- SQL Server Standard edition versions from 2008 to 2014\n- SQL Server Express\n- SQL Server Web\n\nCode and schema conversion\n--------------------------\n\nDatabase Migration Service conversion workspaces provide an interactive editor experience\nwhere you can convert your schemas, tables, and other objects from\nSQL Server syntax to PostgreSQL syntax.\nInteractive conversion workspaces also provide support for Gemini\nassisted workflows with code explainability and conversion issue fixing.\n\nTo learn more, see\n[Conversion workspaces](/database-migration/docs/sqlserver-to-alloydb/about-conversion-workspaces).\n\nContinuous migrations data flow\n-------------------------------\n\nFor heterogeneous SQL Server migrations to PostgreSQL,\nDatabase Migration Service supports the continuous migration flow. In this approach,\nyour data is first loaded from a full dump, and then continuously updated based on\ndata change information surfaced from change tables.\n[](#lightbox-trigger) **Figure 2.** Data movement during Database Migration Service for SQL Server heterogeneous migrations. (click to enlarge)\n\nAt a high level, your data moves through the migration phases as follows:\n\n1. You use Database Migration Service conversion workspace to convert your schemas,\n tables, and other objects from SQL Server syntax to PostgreSQL syntax.\n\n SQL Server databases can often have several thousand objects\n whose schema you need to convert. With Database Migration Service, you can divide your\n work into multiple phases. Database Migration Service can connect to your source\n databases and pull the required schema information when needed.\n2. When you finish translating all your entities to PostgreSQL syntax,\n you apply the schema to the databases in the destination cluster.\n\n The goal of this stage is to prepare your destination databases so that\n Database Migration Service can later replicate the data from source tables to their\n correct equivalents in AlloyDB for PostgreSQL.\n\n Once your schema is applied, you can begin the data migration.\n3. The **full dump phase** is the first part of the migration process. During\n full dump, Database Migration Service connects to your source instance, reads the contents\n of the tables you selected for migration, and then loads the data to the\n AlloyDB for PostgreSQL destination cluster.\n\n In this phase, Database Migration Service captures actual contents of your database.\n4. When the full dump phase is over, Database Migration Service switches to the\n **change data capture (CDC) phase**. During CDC, Database Migration Service keeps monitoring\n your source databases for changes, and then continuously replicates them on the\n destination cluster.\n\n In this phase, Database Migration Service doesn't copy actual data from your source\n tables: instead, it reads information extracted from dedicated change tables\n to replicate changes in the destination. For more information about this\n mechanism, see [Change Data Capture](/database-migration/docs/sqlserver-to-alloydb/migration-types-and-phases#cdc).\n\nYou can stop the ongoing replication and promote the migration job when you want\nto switch your application so that it uses the AlloyDB for PostgreSQL\ndestination cluster as the production database. For a detailed, step-by-step\nmigration guide, see\n[SQL Server to AlloyDB for PostgreSQL migration guide](/database-migration/docs/sqlserver-to-alloydb/guide).\n\nMonitoring\n----------\n\n[](#lightbox-trigger) **Figure 2.** Sample observability diagram in Database Migration Service. (click to enlarge)\n\nDatabase Migration Service provides extensive logging and observability capabilities\nto help you monitor the migration progress. These features include real-time\ndiagnostics for replication delay and CDC progress,\nas well as detailed logs for AlloyDB for PostgreSQL destination cluster health\nand migration job state.\n\nFor more details, see\n[Migration job metrics](/database-migration/docs/sqlserver-to-alloydb/migration-job-metrics).\n\nMigration security\n------------------\n\nDatabase Migration Service provides multiple encryption mechanisms you can use\nfor additional security during the migration process. These mechanisms include:\n\n- SSL/TLS certificates for encrypting the network connections between\n Database Migration Service and source databases. For more details, see\n [Encryption overview](/database-migration/docs/sqlserver-to-alloydb/encrypt-connections-with-certificates).\n\n- Encryption certificates for securing data movement during full dump and CDC\n phases. For more details, see\n [CMEK for migration jobs](/database-migration/docs/sqlserver-to-alloydb/cmek-for-migration-jobs).\n\nWhat's next\n-----------\n\n- To learn more about SQL Server data type and feature support in\n Database Migration Service, see\n [Known limitations](/database-migration/docs/sqlserver-to-alloydb/known-limitations).\n\n- To get a complete, step-by-step migration walkthrough, see\n [SQL Server to AlloyDB for PostgreSQL migration guide](/database-migration/docs/sqlserver-to-alloydb/guide)."]]
