SQL managed instance link is a bridge between SQL Server and Azure SQL Managed Instance. It keeps selected databases replicated near real time so a team can migrate, offload read-only work, run analytics in Azure, or support a hybrid recovery plan without an immediate hard cutover. It is especially useful when a business wants cloud movement but cannot tolerate a long outage. The link still needs careful planning: endpoint connectivity, availability group concepts, seeding, failover mode, monitoring, and rollback decisions all matter.
Managed Instance link, SQL MI link, Azure SQL MI link, MI link
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-25
Microsoft Learn
Microsoft Learn describes the Managed Instance link as near real-time data replication between SQL Server and Azure SQL Managed Instance, enabling hybrid flexibility, database mobility, read-only workload offload, analytics in Azure, disaster recovery patterns, and migrations with planned or forced failover.
Technically, SQL managed instance link uses availability group style replication between SQL Server and SQL Managed Instance. It is configured and inspected through the Azure SQL Managed Instance control plane, SQL Server side preparation, endpoints, certificates, network connectivity, database selection, seeding mode, failover mode, and replication mode. Azure CLI exposes link create, list, show, update, failover, and delete operations. The feature sits between migration, hybrid operations, disaster recovery, and read-scale architecture, so database administrators, network teams, and application owners must coordinate closely.
Why it matters
SQL managed instance link matters because it reduces the pressure of “big bang” database migration. Instead of stopping an application for a long export, import, or backup restore, teams can replicate data to SQL Managed Instance, validate the target, run read-only workloads, and choose a planned failover window. It also supports hybrid patterns where SQL Server remains important for a while. The feature does not remove migration discipline; it increases the need for readiness checks. If endpoints, certificates, seeding, compatibility, or failover decisions are sloppy, the link can create confusing split environments. Used well, it makes migration reversible, observable, and less disruptive.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In Azure CLI, az sql mi link show returns link name, managed instance, partner endpoint, selected databases, replication mode, failover mode, and current state. clearly.
Signal 02
In migration runbooks, the link appears as the control point for seeding, validation, planned failover, forced failover risk, and post-cutover cleanup. during cutover planning meetings.
Signal 03
In SQL Server and network preparation, teams see endpoint, certificate, availability group, DNS, firewall, and private connectivity tasks before link creation. during live migration readiness reviews.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Migrate a SQL Server database to SQL Managed Instance with near real-time replication and a planned cutover instead of a long outage.
Run Azure-based read-only reporting or analytics against a replicated database while production writes still occur on SQL Server.
Maintain a hybrid recovery option where SQL Managed Instance can become primary if the source SQL Server environment is impaired.
Rehearse cutover repeatedly by showing link state, validating replicated databases, and measuring failover steps before production migration.
Update replication mode or failover mode as the migration moves from testing to cutover readiness and finally to cleanup.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Museum consortium migrates membership database
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A museum consortium needed to move a membership SQL Server database to Azure without closing ticketing systems during a major exhibit opening.
🎯Business/Technical Objectives
Keep the SQL Server source online during migration validation.
Replicate membership data to SQL Managed Instance near real time.
Run a planned cutover during a short overnight window.
Preserve rollback options until ticketing smoke tests passed.
✅Solution Using SQL managed instance link
The database team used SQL managed instance link to replicate the membership database from SQL Server to a prepared SQL Managed Instance. Network engineers configured the partner endpoint, certificates, DNS, and private connectivity before production seeding. Azure CLI created the link with the approved database list, then operators used link show output during daily readiness meetings. Application owners ran reports and membership lookup tests against the target while writes continued on the source. During cutover, the team froze writes, confirmed replication state, executed a planned failover, updated connection strings, and kept the source read-only until ticketing and donor workflows passed.
📈Results & Business Impact
The production write freeze lasted 22 minutes instead of the four-hour outage originally estimated.
Membership lookup tests passed with 99.8 percent query behavior match before cutover.
No exhibit-day ticketing windows were cancelled or delayed.
The source SQL Server was decommissioned two weeks later after final backup verification.
💡Key Takeaway for Glossary Readers
SQL managed instance link helps migration teams validate a cloud target while the source database continues supporting the business.
Case study 02
Streaming studio offloads analytics before migration
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A streaming media studio wanted Azure-based analytics for viewer entitlement data, but the core billing SQL Server could not migrate until contract renewal finished.
🎯Business/Technical Objectives
Replicate selected billing databases for read-only analytics.
Avoid slowing the source SQL Server during release weekends.
Keep migration infrastructure useful before final cutover.
Measure replication lag against analytics freshness requirements.
✅Solution Using SQL managed instance link
The studio configured SQL managed instance link from the billing SQL Server to SQL Managed Instance and used the Azure target for read-only analytics. Azure CLI listed and showed the link during release reviews, confirming selected databases, replication mode, and partner endpoint. Analysts connected dashboards to the managed instance instead of querying the billing server directly. Operations monitored replication lag, source CPU, and target query performance during new episode releases. The architecture plan preserved the same link for eventual migration, with a separate planned failover runbook once billing contract dependencies were resolved.
📈Results & Business Impact
Billing server CPU during release weekends dropped by 27 percent after dashboard traffic moved to Azure.
Analytics freshness stayed under the agreed six-minute lag target for 94 percent of measured intervals.
The studio avoided a temporary reporting replica purchase for the contract year.
Migration readiness improved because endpoint, seeding, and monitoring tasks were already proven.
💡Key Takeaway for Glossary Readers
A Managed Instance link can create immediate read-only value while also preparing the path for a later migration.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An agricultural cooperative ran grain contract management on SQL Server in a rural data center. Seasonal storms made leadership nervous about extended site outages.
🎯Business/Technical Objectives
Keep a near real-time Azure copy of contract databases.
Test planned and emergency failover paths before harvest season.
Document who could approve data-loss-bearing actions.
Avoid disrupting daily weigh-station operations during rehearsals.
✅Solution Using SQL managed instance link
The cooperative used SQL managed instance link to replicate grain contract databases to SQL Managed Instance. Platform engineers configured secure endpoints over the private WAN, uploaded required certificates, and created the link with Azure CLI. Operators rehearsed planned failover in a test window, then separately documented why forced failover would require executive approval. Application teams tested weigh-station entry, contract lookup, and settlement reports against the managed instance after planned failover. The runbook included monitoring checks, source system freeze steps, and a post-test reset procedure so harvest operations would not inherit a half-failed rehearsal state.
📈Results & Business Impact
The planned failover rehearsal completed in 34 minutes with no lost contract transactions.
Storm recovery decision time was reduced from an estimated three hours to forty minutes.
Executive approval rules for forced failover were added before harvest began.
Weigh-station application tests found two hard-coded source server names before production use.
💡Key Takeaway for Glossary Readers
SQL managed instance link gives hybrid recovery plans credibility only when failover choices, data-loss tolerance, and application validation are rehearsed.
Why use Azure CLI for this?
With ten years of Azure engineering behind me, I use Azure CLI for SQL managed instance link because link state changes are too important to leave undocumented. CLI gives me repeatable create, list, show, update, failover, and delete operations with exact database lists, partner endpoint, seeding mode, replication mode, and failover type. During migration rehearsals, I can compare link status before and after tests, export evidence, and avoid hunting through portal blades. During cutover, the runbook can use explicit planned failover commands, while forced failover remains clearly separated as a higher-risk emergency path. It also reduces confusion during migration bridges.
CLI use cases
Create a Managed Instance link with explicit partner endpoint, availability group names, database list, seeding mode, and failover mode.
List all links on a managed instance to inventory active migrations, reporting offload patterns, and stale hybrid connections.
Show one link before a cutover to confirm selected databases, state, replication mode, partner endpoint, and failover readiness.
Update replication mode when the migration team moves from asynchronous validation to a planned cutover posture.
Run a planned link failover during cutover, or reserve forced failover for an approved emergency where data loss is accepted.
Before you run CLI
Confirm tenant, subscription, resource group, managed instance name, link name, source SQL Server endpoint, database list, and availability group names.
Verify SQL Server version support, endpoint certificates, network reachability, firewall rules, DNS, seeding approach, and required SQL permissions.
Check that the target managed instance has enough compute, storage, backup policy, security controls, and monitoring before replication starts.
Use a tested JSON or shorthand database list and record output because link commands affect migration state for production data.
What output tells you
Link state tells whether replication is created, updating, failed, or ready enough for the next validation or cutover step.
Database membership confirms that the intended databases are included and that no unrelated production database joined the migration link.
Partner endpoint and availability group names show whether the link is connected to the expected SQL Server source configuration.
Replication mode and failover mode reveal whether the link is configured for validation, planned migration, or a higher-risk emergency posture.
Operation errors usually point to certificate trust, endpoint reachability, malformed database lists, missing permissions, or unsupported source configuration.
Mapped Azure CLI commands
SQL Managed Instance link CLI operations
direct
az sql mi link create --resource-group <resource-group> --mi <managed-instance> --name <link-name> --instance-ag-name <instance-ag> --partner-ag-name <partner-ag> --partner-endpoint <tcp-endpoint> --databases <database-list>
az sql mi linkprovisionDatabases
az sql mi link list --resource-group <resource-group> --mi <managed-instance>
az sql mi linkdiscoverDatabases
az sql mi link show --resource-group <resource-group> --mi <managed-instance> --name <link-name>
az sql mi linkdiscoverDatabases
az sql mi link update --resource-group <resource-group> --mi <managed-instance> --name <link-name> --replication-mode Sync
az sql mi linkconfigureDatabases
az sql mi link failover --resource-group <resource-group> --mi <managed-instance> --name <link-name> --failover-type Planned
az sql mi linkprotectDatabases
Architecture context
Architecturally, I treat SQL managed instance link as a controlled migration and hybrid data-mobility channel. The SQL Server side needs supported versions, availability group preparation, endpoint configuration, certificates, and reachable network paths. The Azure side needs a properly sized managed instance, private connectivity, monitoring, and security controls ready before replication begins. Application teams need a cutover plan that explains when writes stop, when failover occurs, how validation works, and what rollback means. The link can also support read-only reporting or disaster recovery, but those scenarios need separate decisions about data freshness, latency, licensing, and who owns operations across both environments.
Security
Security impact is direct because the link creates a trusted replication path between SQL Server and SQL Managed Instance. Certificates, endpoints, firewall rules, private network routes, database permissions, and administrative rights must be tightly controlled. The source SQL Server and target managed instance should both use least privilege, auditing, encryption, secure secret storage, and restricted operators. A migration link can accidentally expose production data to a broader Azure environment if the target is not governed before seeding. Forced failover and delete operations should require explicit approval. Test links must be isolated so nonproduction systems cannot replicate or fail over production data.
Cost
Cost impact is indirect but material. The target SQL Managed Instance must be provisioned and sized before cutover, which may mean paying for source SQL Server and Azure capacity at the same time during migration. Read-only offload can justify that overlap if it avoids primary scaling or improves analytics, but idle replication targets still need owner approval. Network connectivity, monitoring, storage, backup, and testing environments also contribute. The biggest cost surprise is letting migration links run long after decision makers expected cutover. FinOps teams should track migration timeline, target utilization, source decommission dates, and whether reporting value offsets dual-run cost.
Reliability
Reliability impact is direct because the link can keep a target managed instance closely synchronized for migration, read offload, or disaster recovery. The link is only reliable when replication health, seeding state, network connectivity, endpoint trust, and failover procedures are monitored. Planned failover should be rehearsed with application owners before production cutover. Operators must understand the difference between planned failover and forced failover that may allow data loss. The link should not be the only protection against bad data because corruption or accidental writes may replicate. Backup retention, validation queries, and rollback planning remain essential. Rehearsals turn assumptions into evidence.
Performance
Performance impact appears in replication latency, source workload overhead, target capacity, seeding duration, and failover readiness. Initial seeding can move large amounts of data, so network throughput and source I/O matter. Ongoing replication should be monitored during peak write periods because lag can affect read-only reporting and migration confidence. The target managed instance must be sized for validation queries and eventual production load, not merely for storage. Planned failover performance depends on stopping writes, draining application work, completing synchronization, and reconnecting clients. Operators should test with realistic write volume, not only idle databases. Test results should be kept with cutover evidence.
Operations
Operators manage SQL managed instance links through preparation, creation, monitoring, failover, update, and cleanup. Day-to-day work includes listing links, showing replication state, checking database membership, validating endpoints, and watching lag or health signals. Migration work includes seeding databases, testing read-only queries, rehearsing planned failover, coordinating application freezes, and documenting validation results. Cleanup matters after cutover; stale links, certificates, firewall rules, and old SQL Server permissions can confuse support teams. Good runbooks name the source server, target managed instance, databases, failover mode, approved command patterns, and exact rollback conditions. Cleanup reviews should confirm the bridge did not become permanent technical debt.
Common mistakes
Creating the link before the managed instance has proper security, monitoring, backup, and capacity settings, then replicating production data into an unfinished target.
Confusing planned failover with forced failover and accepting data loss during what should have been a controlled migration cutover.
Letting a migration link run for months without a business-approved cutover date, source decommission plan, or dual-run cost owner.
Forgetting to update application connection strings, jobs, reports, and dependent services during cutover validation.
Deleting the link or source-side objects before proving the managed instance workload, backups, alerts, and rollback plan are healthy.