Database & Workload Migration

Database migration fails when it is treated as a file copy. Character sets, collations, linked servers, scheduled jobs, SSIS or cron ETL, and the applications that cache schema all have to move together. We inventory engines, versions, HA topology, backup tools, and the jobs that write to the database after hours. That inventory drives the method: dump and restore, logical replication, native vendor tools, or a rebuild onto a managed service.

We rehearse on a production-sized copy. Schema conversion, stored procedures, and extension compatibility are proven before the freeze. Replication lag, cutover time, and rollback (replay the old primary) are measured, not estimated. Applications get a connection-string and secret rotation plan so they do not keep writing to the source after DNS flips.

Workloads around the database — reporting replicas, search indexers, overnight batches — are sequenced in the same runbook. Moving the primary and forgetting the replica is how you discover corruption on Monday. We also set backup and PITR on the destination before go-live so the first restore test is not an incident.

Managed database services are used when they fit license, feature, and residency constraints. When they do not, we land on IaaS with the same HA and backup bar you had on-prem. Either way you get evidence: row counts, checksums, and a signed cutover record.