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 Cloud SQL 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 Cloud SQL for PostgreSQL migrations:
Supported source and destination lists all SQL Server versions supported by Database Migration Service.
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 | Cloud SQL for PostgreSQL 12, 13, 14, 15. |
|
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.
To learn more, see Conversion workspaces.
Continuous migrations data flow
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.
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 instance.
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 Cloud SQL 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 Cloud SQL for PostgreSQL destination instance.
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 instance.
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 Cloud SQL for PostgreSQL destination instance as the production database. For a detailed, step-by-step migration guide, see SQL Server to Cloud SQL for PostgreSQL migration guide.
Monitoring
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 Cloud SQL for PostgreSQL destination instance health and migration job state.
For more details, see Migration job metrics.
Migration security
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.
To get a complete, step-by-step migration walkthrough, see SQL Server to Cloud SQL for PostgreSQL migration guide.