Azure SQL Database Migration Module
Move up to five production SQL Server databases into Azure SQL Managed Instance or Hyperscale, behind private endpoints. Changes replicate continuously, the cutover is rehearsed in a dry run, and row counts and checksums are compared before sign-off.
- Fixed fee
- $25,000
- Delivery
- 1–2 weeks, including a dry run
- Scope
- Up to 5 production databases
- Before we start
- Setup review or a tier
How the migration runs
Transaction logs replay continuously over a private connection, so the final cutover only has to flush the last pending changes.
(log reader)"] SourceDB --> DMSAgent end subgraph Transit["Encrypted transit"] VPN["ExpressRoute or site-to-site VPN"] DMSAgent -->|"IPsec tunnel"| VPN end subgraph AzureEnv["Azure spoke network"] DMS["Azure Database Migration Service
(online log replay)"] VPN --> DMS subgraph DataTier["Database subnet (private only)"] SQLMI["Azure SQL Managed Instance
or Hyperscale"] PE["Private endpoint"] AKV["Azure Key Vault
(customer-managed keys)"] DMS -->|"Continuous catch-up sync"| PE PE --> SQLMI AKV -.->|"TDE key"| SQLMI end subgraph AppTier["Application subnet"] App["App Service or AKS workloads"] App -->|"Private DNS resolution"| PE end end
Why database cutovers go wrong
Moving a production SQL Server to Azure tends to stall on three things: schema features the target does not support, fear of corrupting data at cutover, and maintenance windows the business will not grant.
Ad hoc migration scripts rarely replay changes continuously. That leaves room for sync drift, collation failures, and slower queries after cutover. This module replaces the scripts with a tested pipeline, a rehearsed cutover, and a measured validation step.
What it covers
Assessment, a dry-run synchronization, and the production cutover, for up to five databases.
-
Schema assessment
A scan of stored procedures, triggers, CLR modules, linked servers, and collations to find and fix migration blockers before anything moves.
- Compatibility level review, SQL Server 2008 through 2022
- Mapping of orphaned users and SQL logins
- Deprecated features found, with remediation steps
-
Continuous sync pipeline
Transaction log shipping or change data capture into the target, keeping the final cutover window short.
- Azure Database Migration Service with a private runtime
- Continuous log restore with lag alerts
- Scripted cutover procedure and rollback runbook
-
Private networking
Database listeners reachable only from approved private subnets in your Azure network.
- No public IP on the Managed Instance or logical server
- Private DNS zone integration for privatelink.database.windows.net
- Network security groups that admit only approved application subnets
-
Encryption and access
Transparent Data Encryption with customer-managed keys held in Azure Key Vault, configured to support the encryption requirements of PCI-DSS 4.0 and HIPAA.
- TDE with key rotation
- Microsoft Entra ID authentication and role-based access
- Microsoft Defender for SQL vulnerability assessment and threat detection
-
Parity validation
Checks that row counts, checksums, primary keys, and index constraints match between source and target before sign-off.
- Table-by-table checksum and row count reports
- Query performance baseline captured with Query Store
- A validation sign-off record for your change approval
-
Sizing and cost settings
CPU, memory, and IOPS sized from your workload history, so the target is not over-provisioned.
- Azure Hybrid Benefit where your existing licenses qualify
- Serverless auto-pause or reserved capacity planning
- Storage auto-grow thresholds and log retention limits
What you provide
Source access
Read-level credentials and IPsec connectivity to the source databases.
A database subnet
A dedicated private subnet in Azure for the Managed Instance or the private endpoint.
A database lead
One DBA or application lead for schema review and cutover validation.
Questions
How is data protected during cutover?
Log synchronization runs alongside your production database. At cutover the source is switched to read-only while the last pending logs replay into Azure, then checksum and row count checks run before sign-off. The read-only window depends on your write volume and is measured during the dry run.
Do you support SQL Server 2008 and 2012?
Yes. The schema assessment covers compatibility levels from SQL Server 2008 onward, and the runbooks move legacy schemas to Azure SQL Managed Instance with compatibility settings preserved where the target supports them.
Does this need firewall ports open to the internet?
No. Replication traffic runs over your site-to-site VPN or ExpressRoute connection, and the Azure database is reachable only through private endpoints.
What if we need to roll back during the maintenance window?
The runbook has go and no-go checkpoints. The source database is not decommissioned during cutover, so rolling back means pointing connection strings back at the on-premises listener.
Do we need one of the tiers first?
Not necessarily. We start by reviewing your current Azure setup. If it already has the foundation the target needs, we build the migration on it. If it does not, we build that foundation with you through one of our tiers first; Tier 3: Platform Transit Hub is the usual fit when you want the hub network, firewall, and logging in place for the target.
Related
- Tier 3: Platform Transit Hub
The hub network, firewall, Bastion, and central logging that migrated workloads connect into.
- Why enterprise Azure migrations stall
Governance sprawl, unmanaged networking, and compliance blockers, and how a foundation removes them before workloads move.
- Azure AI Lakehouse Module
A private Databricks workspace with Unity Catalog for the data you have moved.
Move your SQL Server estate with a rehearsed cutover.
$25,000 fixed fee, 1 to 2 weeks including a dry run. Not sure which foundation it should land on? Answer three questions.