Best Practices for SQL to Azure SQL Managed Instance Migration

Question

Best Practices for SQL to Azure SQL Managed Instance Migration

InfraSolutions 711

An SAP tool is hosted in Azure across two regions (one for primary and another for disaster recovery), with web servers and SQL servers in different subnets, as illustrated in the diagram below.

User's image

The plan is to migrate from hosted SQL VMs to Azure SQL Managed Instance (SQL MI). After reviewing Microsoft documentation, it was noted that there are four available migration options:

Managed Instance Link
Log Replay Service (LRS)
Native RESTORE DATABASE FROM URL (using native backups from SQL Server and necessitating some downtime)
Azure SQL Migration Extension for Azure Data Studio (allowing migration with near-zero downtime)

The database sizes are manageable, with three databases: one around 10 GB, another 150 GB, and the third is 160 GB. A combination of LRS and Database Migration Service (DMS) is intended to automate the end-to-end data migration (Assuming this would work)

However, there is confusion about how the "to-be" diagram would look after migration based on the current setup.

A note from Microsoft states the following:

Azure SQL MI requires a dedicated subnet. If this is the case, can a VNet-local endpoint be used during data transfer (for connectivity between the old SQL VM and Azure SQL MI)?

Given that there are two SQL servers enabled with Failover Cluster Instances (FCI), would one Azure SQL MI typically replace the need for multiple FCIs?

During the transition phase, is the data transfer from Azure Blob Storage to Azure SQL MI a straightforward process?

Apologies if the "to-be" diagram lacks clarity; it serves as a rough representation. Confirmation on these assumptions would be appreciated for a smooth migration process.

Transition:

User's image

To-Be:

User's image

Adithya Prasad K 1,375 Reputation points Microsoft External Staff Moderator

2025-04-08T17:26:20.4633333+00:00
Hi MJ-1983,

Thanks for sharing the details of your SAP migration from SQL VMs to Azure SQL Managed Instance (SQL MI)—it’s a great move toward a managed platform! I’ll address your questions and provide some clarity on the "to-be" architecture based on your current setup (web servers and SQL servers in subnets across primary and DR regions) and the migration plan. Apologies if I misinterpret anything due to not seeing the diagrams directly, but I’ll work with what you’ve described.

"To-Be" Diagram Overview

After migrating to Azure SQL MI, your architecture will shift from SQL VMs to a managed instance setup. Here’s how it might look:

Primary Region: Web servers remain in their subnet, now connecting to an Azure SQL MI deployed in a dedicated subnet within the same VNet (or a peered VNet). SQL VMs will be phased out post-migration.

DR Region: A second Azure SQL MI instance in a dedicated subnet, paired with the primary via auto-failover groups for disaster recovery, replacing the secondary SQL VM setup.

Connectivity: Web servers will use the SQL MI Fully Qualified Domain Name (FQDN) or private endpoints for secure, low-latency access.

Now, let’s tackle your specific questions:

1. Can a VNet-local endpoint be used during data transfer (SQL VM to SQL MI)?

Yes, absolutely! Azure SQL MI requires a dedicated subnet, and you can enable a VNet-local endpoint (specifically a Private Endpoint) for secure connectivity between the old SQL VM and SQL MI during migration. Here’s how:

Place the SQL MI in a dedicated subnet within the same VNet as your SQL VMs (or a peered VNet).

Use Azure Private Link to create a private endpoint for SQL MI, allowing the SQL VM to communicate with it over the Azure backbone network, avoiding public internet exposure.

For migration tools like Log Replay Service (LRS) or Managed Instance Link, this setup ensures data transfer stays within the VNet, enhancing security and performance.

Ensure the SQL VM subnet and MI subnet have proper Network Security Group (NSG) rules and routing configured (e.g., TCP 1433, 445 for SQL traffic).

2. Can one Azure SQL MI replace multiple Failover Cluster Instances (FCIs)?

Typically, yes—one Azure SQL MI can replace multiple SQL Server FCIs, depending on your workload and database consolidation needs. Here’s why:

Instance-Level Features: SQL MI supports instance-level capabilities (e.g., SQL Agent, cross-database queries) that align with FCI setups, unlike Azure SQL Database.

Consolidation: With your databases (10 GB, 150 GB, 160 GB), a single SQL MI instance (e.g., General Purpose or Business Critical tier) can host all three, assuming they don’t require separate FCIs for isolation or performance reasons.

High Availability: SQL MI includes built-in HA (e.g., 99.99% uptime SLA with Business Critical tier using Always On under the hood), eliminating the need for manual FCI management across two SQL servers.

Caveat: If your two FCIs serve distinct purposes (e.g., different SAP modules with strict separation), you might opt for two SQL MI instances. For your sizes, though, one should suffice unless there’s a specific business or compliance need.

3. Is data transfer from Azure Blob Storage to Azure SQL MI straightforward?

Yes, it’s fairly straightforward, especially with the methods you’re considering:

Native RESTORE FROM URL: You’d back up your SQL VM databases to Azure Blob Storage (e.g., using BACKUP TO URL), then restore them to SQL MI with RESTORE DATABASE FROM URL. It’s simple but requires downtime (your databases are offline during the restore). Given your sizes (max 160 GB), this should be quick—hours, not days—assuming good bandwidth.

LRS with Blob Storage: Log Replay Service can read full backups and transaction logs from Blob Storage, replaying them to SQL MI with minimal downtime. It’s more complex to set up (needs backup files in a container with SAS token) but keeps your app running until the final cutover.

Transition Phase: Upload backups from SQL VMs to Blob Storage via AzCopy or similar, then point your migration tool (LRS or RESTORE) to the container. Ensure SQL MI has access (e.g., via system-assigned managed identity or SAS token).

Your plan to combine LRS with Azure Database Migration Service (DMS) is solid—DMS can orchestrate LRS for near-zero downtime, automating the process end-to-end. Just validate that your SAP app tolerates the brief cutover latency.

Migration Option Recommendation

Given your database sizes and automation goal:

LRS + DMS: Best for near-zero downtime. Start with a full backup to Blob Storage, followed by incremental log backups. DMS manages the orchestration, and LRS keeps SQL MI in sync until you’re ready to switch. Test the cutover with your 10 GB database first as a pilot.

Managed Instance Link: Also near-zero downtime, but it’s more suited for ongoing replication. It might be overkill unless you need continuous sync post-migration.

"To-Be" Diagram Suggestions

Your rough "to-be" diagram likely shows SQL MI in a dedicated subnet, web servers connecting to it, and a DR setup. To refine it:

Add the Private Endpoint for SQL MI in the primary region.

Show VNet peering or a VPN/ExpressRoute link to the DR region’s SQL MI (with auto-failover groups enabled).

Remove SQL VMs once migration completes, keeping web servers intact.

No need to apologize for clarity—it’s a solid starting point! Microsoft’s docs-
Migration guide: SQL Server to Azure SQL Managed Instance ) and the Azure Architecture Center have great reference diagrams too.

Let me know if you’d like me to sketch out a more detailed "to-be" concept or dig deeper into any part of this. Happy to help ensure a smooth migration!
InfraSolutions 711 Reputation points

2025-04-09T08:41:27.6533333+00:00

Thank you so much for the detailed explanation of all the queries I posted. It is truly appreciated. After reading your responses, I have a few additional questions. Could you please help clarify the following points?

Connectivity Between Web Servers and Azure SQL MI:

If we have a firewall that filters incoming and outgoing connections to the internet, are there any Microsoft recommendations for whether to use Private Endpoints or FQDN in this scenario?

Private Endpoints and VNet-local Communication:

Once we’ve created a separate subnet for Azure SQL MI, does the communication between the SQL server hosted in Azure (Subnet 1) and Azure SQL MI (Subnet 2) use the VNet-local (private) endpoint by default? If so, why would we need to create a separate private endpoint, given that communication would already be private by default?

Data Migration Strategy:

If we combine LRS with Azure Database Migration Service (DMS), it seems we can achieve near-zero downtime and seamless integration. However, if we prefer no downtime and an immediate switch to the DR region, which migration strategy would Microsoft recommend for a simple to medium-sized data storage migration?

To-Be Diagram:

Since Azure SQL MI has built-in DR capabilities (including data backup), would it be correct to assume that once the data migration, connectivity, and configurations are working as expected, the existing Azure Blob Storage and SQL VMs will be decommissioned?
InfraSolutions 711 Reputation points

2025-04-09T23:35:00.47+00:00

Excellent, thank you so much again for taking the time to explain my queries. I believe you've clarified everything I asked, and I really appreciate the reference links. I'm sure they'll be very helpful for my migration. Thanks once again!

Accepted answer

0 additional answers

Your answer

InfraSolutions 711 Reputation points

2025-04-09T08:41:27.6533333+00:00

Thank you so much for the detailed explanation of all the queries I posted. It is truly appreciated. After reading your responses, I have a few additional questions. Could you please help clarify the following points?

Connectivity Between Web Servers and Azure SQL MI:

If we have a firewall that filters incoming and outgoing connections to the internet, are there any Microsoft recommendations for whether to use Private Endpoints or FQDN in this scenario?

Private Endpoints and VNet-local Communication:

Once we’ve created a separate subnet for Azure SQL MI, does the communication between the SQL server hosted in Azure (Subnet 1) and Azure SQL MI (Subnet 2) use the VNet-local (private) endpoint by default? If so, why would we need to create a separate private endpoint, given that communication would already be private by default?

Data Migration Strategy:

If we combine LRS with Azure Database Migration Service (DMS), it seems we can achieve near-zero downtime and seamless integration. However, if we prefer no downtime and an immediate switch to the DR region, which migration strategy would Microsoft recommend for a simple to medium-sized data storage migration?

To-Be Diagram:

Since Azure SQL MI has built-in DR capabilities (including data backup), would it be correct to assume that once the data migration, connectivity, and configurations are working as expected, the existing Azure Blob Storage and SQL VMs will be decommissioned?
InfraSolutions 711 Reputation points

2025-04-09T23:35:00.47+00:00

Excellent, thank you so much again for taking the time to explain my queries. I believe you've clarified everything I asked, and I really appreciate the reference links. I'm sure they'll be very helpful for my migration. Thanks once again!

Answer 1

Hi
Allow me to address your queries in detail:

Private Endpoints vs. FQDN for Firewall Scenarios Microsoft recommends utilizing Private Endpoints for secure and isolated connectivity between your web servers and Azure SQL Managed Instance (MI). This ensures that traffic remains within your virtual network, avoiding traversal over the public internet for enhanced security. If you choose to use an FQDN, please ensure that DNS resolution is correctly configured to route traffic to the private endpoint, which can be managed through Azure Private DNS Zones.

VNet-local Communication Between Subnets Once the Azure SQL MI is placed in its designated subnet, communication between SQL Server (Subnet 1) and Azure SQL MI (Subnet 2) will utilize the VNet-local endpoint by default. This provides private communication within the virtual network itself, without requiring a separate private endpoint. A dedicated private endpoint is only necessary for scenarios involving resources across different VNets or for additional isolation.

Data Migration Strategy For minimal downtime during migration, combining the Log Replay Service (LRS) with Azure Database Migration Service (DMS) is highly recommended. However, if zero downtime and instant switchover to the Disaster Recovery (DR) region are priorities, solutions like Failover Groups or Geo-Replication can be explored to ensure seamless migration and operational continuity.

Decommissioning Existing Resources Yes, you are correct. Once data migration, connectivity, and configurations have been validated, the existing Azure Blob Storage and SQL VMs can be decommissioned. Azure SQL MI provides robust disaster recovery capabilities, including automated backups and high availability, ensuring data resilience and security moving forward.
I hope this information helps. Please do let us know if you have any further queries.
I would request you to refer the below mentioned links for more information
1-Azure Private Endpoint private DNS zone values
2-What is a private endpoint?
3-Disaster recovery guidance - Azure SQL Managed Instance
4-Connectivity architecture for Azure SQL Managed Instance
5-Azure SQL Managed Instance connection types
6-Azure Private Link for Azure SQL Managed Instance
7-Migrate databases from SQL Server by using Log Replay Service - Azure SQL Managed Instance
8-Overview of Log Replay Service with Azure SQL Managed Instance
9-Overview of business continuity with Azure SQL Managed Instance

If this answers your query, do click "Accept the answer” for the same, which might be beneficial to other community members reading this thread. And, if you have any further query do let us know
User's image, Picture

Share via

Best Practices for SQL to Azure SQL Managed Instance Migration

"To-Be" Diagram Overview

1. Can a VNet-local endpoint be used during data transfer (SQL VM to SQL MI)?

2. Can one Azure SQL MI replace multiple Failover Cluster Instances (FCIs)?

3. Is data transfer from Azure Blob Storage to Azure SQL MI straightforward?

Migration Option Recommendation

"To-Be" Diagram Suggestions

0 additional answers

Your answer