Migrating On-Prem SQL Server to Managed Cloud Databases
For most estates, the database is the workload where replatforming pays off most — and the one people are most nervous about. Move it to a managed service and you hand off patching, backups, and high availability for good. Here is how to pick the target, de-risk the cutover, and design it as code.
Why the database is the highest-value replatform
A self-managed SQL Server is a full-time job: OS and SQL patching, backup jobs, HA/DR configuration, capacity planning, and the 2 a.m. call when a disk fills. A managed database absorbs nearly all of that. Of every "replatform" decision in a migration, the database usually returns the most operational time for the least application change — which is why it’s the first one to look at.
Pick the target that matches your compatibility needs
Each cloud offers a spectrum from "closest to your on-prem instance" to "fully cloud-native":
- Azure: SQL Managed Instance for near-full instance compatibility (SQL Agent, cross-database queries, CLR); Azure SQL Database for a single modern database when you can adapt.
- AWS: Amazon RDS for SQL Server for a managed instance; Aurora if you’re willing to move engines for scale and cost.
- GCP: Cloud SQL for SQL Server for a managed instance experience.
The deciding question is how much instance-level surface area your app relies on. Heavy use of SQL Agent jobs, linked servers, or CLR pushes you toward Managed Instance / RDS; a clean single-database app can go further.
Assess compatibility before you commit
Run the free assessment tools first — the Data Migration Assistant (Azure), the AWS Schema Conversion Tool, or the database migration assessment in your target — to surface blockers: unsupported features, deprecated syntax, collation mismatches, and cross-database dependencies. Finding these during assessment is cheap; finding them during cutover is not.
Choose your cutover style by downtime tolerance
- Backup/restore or BACPAC — simplest, but the downtime equals the restore time. Fine for smaller databases and generous windows.
- Managed migration services (Azure DMS, AWS DMS) — continuous replication so you cut over with minimal downtime.
- Log shipping / distributed AG — for the largest databases and the tightest windows.
Match the mechanism to the business’s real downtime tolerance, not the easiest option to set up.
Design the target — including everything around the database
A managed database doesn’t live alone. It needs a private subnet, a security group / NSG, a secrets store for the connection string, network routes from the app tier, and a backup/retention policy. Draw the whole thing. In CloudForge you can place the managed database on the canvas alongside the app tier, networking, and secrets — or ask Vani to propose the target for a described SQL Server workload — then generate the Terraform for the database and its surrounding infrastructure, so nothing is configured by hand in a console and forgotten.
Validate, then retire the old instance
After cutover, verify connection strings, run the app’s integration tests, confirm backups are running and restorable, and check that HA failover behaves. Keep the on-prem instance in read-only standby until you’re confident, then decommission it. This database replatform is one workload in a larger program — see the 6 R’s and the full migration playbook for the wider plan.