Migrate your SQL Server databases to Cloud SQL for SQL Server

Preview — Database Migration Service for homogeneous SQL Server migrations

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

This page describes how to migrate your SQL Server databases to Cloud SQL for SQL Server instance with Database Migration Service.

The migration process involves the following tasks:

1. Exporting full database backup and transaction log files from the source SQL Server instance.

2. Uploading your backup files to a Cloud Storage bucket.

3. Creating the destination Cloud SQL for SQL Server instance.

4. Creating and running the migration job in Database Migration Service.

5. Monitoring the migration job progress with Database Migration Service observability features.

6. Promoting the migration job after the data is fully migrated.

Costs

For homogenous migrations to Cloud SQL, Database Migration Service is offered at no additional charge. However, Cloud SQL and Cloud Storage pricing applies for network charges as well as Cloud SQL and Cloud Storage entities created for migration purposes.

In this document, you use the following billable components of Google Cloud:

• Cloud Storage
• Cloud SQL

To generate a cost estimate based on your projected usage, use the pricing calculator. New Google Cloud users might be eligible for a free trial.

Before you begin

1. Verify if this migration path can fully support your scenario. See SQL Server Known limitations.
2. Consider in which region you want to create the destination database. Database Migration Service is a fully-regional product, meaning all entities related to your migration (source and destination connection profiles, migration jobs, destination databases, storage buckets) must be saved in a single region.

3. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

4. Enable the Database Migration Service, Compute Engine, Cloud Storage, and Cloud SQL Admin APIs.

   Enable the APIs

Required roles

To get the permissions that you need to perform homogeneous SQL Server migrations with Database Migration Service, ask your administrator to grant you the following IAM roles on your project:

• User account that performs the migration:
  • Database Migration Admin (roles/datamigration.admin)
  • Storage Admin (roles/storage.admin)
  • Cloud SQL Editor (roles/cloudsql.editor)
• Database Migration Service service account:
  • Database Migration Admin (roles/datamigration.admin)
  • Storage Admin (roles/storage.admin)
  • Cloud SQL Editor (roles/cloudsql.editor)

For more information about granting roles, see Manage access.

These predefined roles contain the permissions required to perform homogeneous SQL Server migrations with Database Migration Service. To see the exact permissions that are required, expand the Required permissions section:

Required permissions

The following permissions are required to perform homogeneous SQL Server migrations with Database Migration Service:

• datamigration.*
• resourcemanager.projects.get
• resourcemanager.projects.list
• cloudsql.instances.create
• cloudsql.instances.get
• cloudsql.instances.list
• compute.machineTypes.list
• compute.machineTypes.get
• compute.projects.get
• storage.buckets.create
• storage.buckets.list

You might also be able to get these permissions with custom roles or other predefined roles.

Prepare your source data

To prepare your source data for migration, follow these steps:

1. Perform a full backup of your source SQL Server database. Make sure you use the correct naming pattern.

2. Prepare a Cloud Storage bucket and upload your backup files to it. Make sure you set up the necessary directory structure.

3. Create a source connection profile for the Cloud Storage bucket.

Prepare your Cloud SQL for SQL Server destination instance

To configure your destination Cloud SQL instance, perform the following steps:

1. Create and configure your Cloud SQL for SQL Server destination instance. Make sure you use enough compute and memory resources to cover your migration needs, and assign the Storage Admin (roles/storage.admin) role to the instance's service account.

2. Create a destination connection profile for your Cloud SQL instance.

Create and run the migration job

To configure and run your migration, perform the following steps:

1. Create and run the migration job.

   When you start the migration job, your destination Cloud SQL for SQL Server databases are put into recovery mode where they are fully managed by Database Migration Service. You can promote your destination instance when your data is fully migrated. After your destination instance is promoted, all the databases in that instance become fully operational. You also gain full write access to those databases.

   Note: You can monitor the migration progress, as well as your destination instance health with Database Migration Service observability features. See Migration job metrics.

2. Keep uploading new transaction log backup files to the Cloud Storage bucket.

   To cover data that appears in your source database after you perform the full backup export, export transaction log backup files and upload them to the storage bucket. Database Migration Service automatically detects new files, reads their contents, and pushes the data to your destination instance. See Automate transaction log exports.

Finalize the migration

When you decide to switch your application to the new Cloud SQL for SQL Server instance, finalize the migration by following these steps:

1. Stop all write operations on your source databases. You can switch them to read-only mode to retain operational functionality.
2. Take the last transaction log backup, upload the file to your storage bucket, and stop the incremental load phase in Database Migration Service. You can achieve this result by performing one of the following actions:
   • Stop your automated backup file uploads, or upload the last transaction log file. Monitor the unprocessed transaction log backups size to determine when Database Migration Service finishes processing that file.
   • Optionally, you can upload a transaction log file whose name ends in .trn.final suffix. Database Migration Service stops continuous loads when it detects a backup file whose name matches the .trn.final suffix convention.

     When Database Migration Service finishes processing that file, migration job status changes to Ready to promote.

3. Promote the migration job.
4. (Optional) Verify migration data for completeness.