Known limitations

This page describes the known limitations for migrating from SQL Server to Cloud SQL for SQL Server with Database Migration Service.

General limitations

Database Migration Service can migrate up to a maximum of 20 databases per migration job.
You can run only one migration job for a single destination Cloud SQL for SQL Server instance.
Database Migration Service doesn't migrate the SQL Server master database, user information (such as user logins), or jobs that aren't a part of a specific database.
Point-in-time recovery (PITR) can't be enabled on your destination Cloud SQL instance during migration. You can enable this feature after the migration is complete.

For Cloud SQL for SQL Server sources, you can only create the source connection profile and migration job with Google Cloud CLI. You can use the Google Cloud console to monitor migration progress and metrics.
For Cloud SQL for SQL Server sources, Database Migration Service automatically handles all necessary backup file creation and uploads them to a Cloud Storage bucket. Database Migration Service first performs the full dump backup with stripe count set to 13, and then continuously creates and exports transaction log backup files.
Database Migration Service doesn't remove any automatically exported backup files from your Cloud Storage bucket. We recommend that you configure a data retention period between 14 and 30 days for your backup files.
Database Migration Service doesn't encrypt the backup files that are automatically created for this migration flow. If you need to use encrypted backup files from your Cloud SQL for SQL Server instance, we recommend that you use the standard migration flow dedicated for self-managed or Amazon RDS sources.
Your source Cloud SQL for SQL Server must have point-in-time recovery (PITR) enabled so that Database Migration Service can create transaction log backup files.

Database Migration Service migrates all data from the backup files you upload to the Cloud Storage bucket, but not all features present in your source database might be available in Cloud SQL for SQL Server. Database Migration Service migration jobs don't restore data that falls under an unsupported feature, but your destination Cloud SQL for SQL Server instance might produce warnings or errors in the logs.

Before you choose to migrate your SQL Server databases to Cloud SQL for SQL Server, make sure you consider SQL Server features unavailable for Cloud SQL in Cloud SQL for SQL Server documentation. You can also use Google Cloud Migration Center to discover possible limitations or gaps in feature support for your specific scenario. See Discover and import databases in the Migration Center documentation.
Your backup files can have a maximum size of 5 TB.
You can stripe your full backup file into smaller files if your database size exceeds 5 TB. Each stripe can have a maximum size of 5 TB.
You can use encrypted backup and transaction log files for your migration. If you want to use encrypted backup files, you must encrypt every backup file (full, differential, transaction log) you use for a specific database included in your migration. See Use encrypted backups.
Your source SQL Server instance can't use the simple recovery model. For more information on recovery models, see See Recovery Models (SQL Server) in Microsoft documentation.