Database migration typically involves moving databases from on-premises to cloud or between cloud providers. Google Cloud's Database Migration Service (DMS) supports Cloud SQL for SQL Server as a source, enabling continuous, low-downtime replication between Cloud SQL instances. This allows for operational patterns like storage management, specifically disk shrinking, with minimal application downtime. Disk shrinking is necessary because database storage often only increases, and while data deletion frees space within database files, the underlying disk retains peak allocated capacity.Features like Cloud SQL automatic storage increase prevent outages, but manual shrinking is needed to reclaim unused space. Shrinking the physical disk reduces ongoing storage costs, especially after major data archiving, recovery from storage spikes, or post-refactoring. Cloud SQL provides a built-in storage shrink feature, but it requires downtime proportional to the disk size, which can be hours for multi-terabyte drives.DMS offers a minimal-downtime alternative by continuously replicating databases to a newly provisioned Cloud SQL instance with a smaller disk. This approach keeps the cutover window short. DMS replicates data by taking an initial full backup and then continuously applying transaction log backups, similar to native SQL Server log shipping.This synchronization happens at the user database level, so server-level objects like logins, linked servers, and SQL Server Agent jobs are not automatically replicated and must be manually migrated. The DMS disk shrink workflow involves provisioning a new target instance with a smaller disk, starting a continuous DMS job, allowing replication to catch up, and then performing a brief cutover.Pre-cutover preparation is crucial, including scripting and recreating server-level objects like logins, SQL Server Agent jobs, linked servers, extended events, and instance configurations on the target. For TDE-enabled instances, the TDE certificate must be exported and imported. Post-cutover, orphaned database users must be resolved because logins created on the destination will have new Security Identifiers (SIDs) that don't match the source SIDs in the migrated databases.These orphaned users need to be detected and re-mapped using ALTER USER statements. DMS is a versatile tool for day-two operations, allowing engineers to right-size storage and reduce infrastructure costs with minimal downtime when strict production SLAs prevent lengthy maintenance windows.