Migrating SQL Server Logins and Users to Google Cloud SQL After DMS Replication

The Challenge of Database Migration

When migrating SQL Server databases to Google Cloud SQL using the Database Migration Service (DMS), applications may fail to connect to the new Cloud SQL instance even after data replication is complete. This issue arises because DMS specifically excludes instance-level objects, such as server logins and permissions, from its migration process.

Why DMS Excludes Security Objects

The exclusion of server logins and permissions by DMS is a deliberate security measure. It prevents potential privilege escalation, as source environments and Cloud SQL operate under different security models. Directly replicating master system databases could grant unauthorized sysadmin access in the managed cloud environment.

This approach also supports compliance and audit governance by requiring explicit administrator oversight for migrating encrypted password hashes and server-level credentials. This ensures that only approved identities are provisioned in the cloud, adhering to frameworks like PCI-DSS or SOC 2. Additionally, it provides an opportunity for organizations to modernize and prune stale credentials during the cloud migration process.

Bridging the Migration Gap

To address the missing logins and users, administrators must manually migrate these security objects. This process involves using standard, time-tested SQL Server tools to transfer the necessary logins and user permissions to the new Cloud SQL for SQL Server instance. This ensures that applications can successfully authenticate and connect to the migrated databases.