How it works
The link creates a distributed availability group between an AG on your SQL Server and the managed instance. Changes stream continuously. The MI copy is read-only until you fail over. This gives the lowest downtime path to MI: the cutover is a planned failover of a few seconds plus the app switch.
| Version | Notes |
|---|---|
| SQL Server 2016 SP3 / 2019 | One-way migration to MI (no failback) |
| SQL Server 2022 | Bi-directional: failover to MI and back; also usable for DR |
1. Prerequisites
- Supported version and CU on the source; Enterprise or Developer/Standard per the docs for your version.
- Always On availability groups enabled on the instance (no cluster needed for a single-node AG on SQL Server 2016 SP3+ in this scenario; follow the docs for your setup).
- Database in
FULLrecovery with a full backup taken. - Network: SQL Server → MI on port 5022 (and MI → SQL Server 5022, plus MI subnet range 11000–11999 from SQL Server for redirect) over VPN or ExpressRoute; NSG rules on the MI subnet.
- Certificates exchanged to secure the database mirroring endpoints (SSMS wizard does it).
- Trace flags on older versions as documented (for example 1800 and 9567 on 2016/2019 to improve performance).
2. Create the link (SSMS wizard)
SSMS → right-click the database → Azure SQL Managed Instance link → Replicate database → sign in to Azure → choose the MI → let the wizard create the AG, endpoints and certificates → seeding starts.
Monitor in SSMS (Always On dashboard) or with:
SELECT ag.name, drs.synchronization_state_desc, drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;
PowerShell (Az.Sql) can automate this for many databases (New-AzSqlInstanceLink).
3. Prepare the target while it syncs
- Logins (Entra ID or SQL), server-level permissions, Agent jobs, linked servers, DB Mail on MI.
- Test read-only queries and reports against the MI copy to catch performance or compatibility issues early.
4. Cutover
- Stop the app; confirm no write sessions.
- Check sync is current.
- SSMS → Failover between SQL Server and Managed Instance → planned failover (no data loss).
- On 2016/2019: the link is removed and the MI database is read-write. On 2022: you can keep the link with MI as primary and SQL Server as the secondary for failback.
- Point connection strings to the MI host name (
<mi>.<dns-zone>.database.windows.net). - Smoke tests.
5. Failback (SQL Server 2022)
Fail over back to SQL Server through the same wizard if a serious issue appears. Decide in advance how long you keep the link before removing it.
6. Tips
- One link per database; plan seeding of very large databases (seeding speed depends on network bandwidth).
- Keep the MI update policy compatible: the SQL Server 2022 update policy is needed for failback to SQL Server 2022; the "Always-up-to-date" policy prevents restoring back.
Tip
Use the link for a few weeks as a read replica before cutover. Running real reports against MI is the best compatibility and performance test you can get.