Cross tenant database migration - mysql flexible server

Hi Vincent Kiti,

Thank you for providing the detailed scenario — we understand the complexity involved, especially with cross‑tenant networking and large data volumes.

From the error message:

“Unable to connect to any of the specified MySQL hosts”

we can confirm that this issue is related to network connectivity, where Azure Database Migration Service (DMS) is not able to reach the source MySQL Flexible Server.

For Azure DMS to work successfully, it must have direct network access to both source and target databases. If this connectivity is not fully established, the migration activity will fail with the exact error you’re seeing.

In cross-tenant scenarios (like yours), the most common gaps are:

1. Firewall configuration (Mandatory)

We recommend ensuring that server-level firewall rules are properly configured on both:
Source MySQL Flexible Server
Target MySQL Flexible Server

The firewall must allow traffic from the DMS subnet or VNet IP range, otherwise the connection attempt will fail.
2. DNS resolution (Critical but commonly missed)

Even when VNet peering is configured:

• Azure MySQL Flexible Server uses FQDN (DNS name) for connections
• If DNS resolution is not working across VNets/tenants, DMS cannot locate the server

We recommend:

• Linking the private DNS zone to both VNets
• Validating DNS resolution from a VM inside the DMS subnet

This is a key requirement for private networking scenarios.
3. VNet peering and routing validation

• Ensure bidirectional peering is enabled
• Confirm:
  • Allow virtual network access is selected
  • Verify that NSG or route tables are not blocking traffic

Once the above (Firewall + DNS + VNet) are correctly configured, the connectivity issue should be resolved.
Important guidance for your 20 TB reporting database

While the above steps will fix the connection problem, we also want to clarify that:

Using DMS alone is not recommended for very large databases (like 20 TB)

For large-scale migrations, we suggest a more efficient approach

• Use parallel tools (such as mydumper/myloader) for bulk data transfer
• Use binlog-based replication or DMS for incremental changes and cutover

This hybrid approach:

• Improves performance significantly
• Supports minimal downtime
• Scales better for large datasets

We are explaining that:

• The current error is caused by incomplete network configuration (especially DNS and firewall settings) rather than a DMS limitation
• Once these networking components are correctly configured, the migration connection should succeed

For your 20 TB reporting database, using DMS alone is not sufficient — a hybrid migration strategy is recommended for better performance and scalability

We recommend validating DNS resolution, firewall rules, and VNet configuration to resolve the DMS connectivity error. Additionally, for the 20 TB database, consider using a hybrid migration approach (parallel load + replication) to achieve better performance and minimal downtime.
Microsoft Reference Links:

• Migrate MySQL to Azure using Azure DMS [Tutorial:...soft Learn | Learn.Microsoft.com]
• Networking concepts for Azure MySQL Flexible Server [learn.microsoft.com]
• Azure MySQL migration guidance and large database strategies [Cross-Tena...tion Guide | Word]

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

The error indicates that Azure Database Migration Service (DMS) cannot reach the source MySQL flexible server over the network. For cross-tenant migrations with VNet peering, the key is to ensure that the DMS subnet can reach both source and target servers and that firewall rules allow this traffic.

To resolve the connectivity error for the transaction database:

1. Verify DMS deployment and networking
   • Ensure the DMS instance is created in Azure service mode and in a virtual network that must have IP connectivity to both:
     • The source MySQL flexible server VNet (in tenant A).
     • The target MySQL flexible server VNet (in tenant B).
   • Confirm VNet peering between the two VNets is fully configured in both directions, with:
     • “Allow virtual network access” enabled.
     • No custom route tables or network virtual appliances blocking traffic between the subnets.
2. Confirm firewall rules on MySQL servers
   • For both the source MySQL server and the target MySQL flexible server, create server-level firewall rules that allow inbound connections from the DMS subnet (or VNet) IP range.
   • This is required so that the DMS instance can access both source and target databases.
   • The guidance for physical migration explicitly calls this out, and it applies similarly to online migrations:
     • “Create a server-level firewall rule for both the source MySQL server and the target MySQL flexible server to allow the virtual network for Azure Database Migration Service access to the source and target databases.”
3. Validate connectivity from inside the DMS VNet
   • Create a temporary test VM in the same subnet as the DMS instance.
   • From that VM, attempt to connect to the source MySQL flexible server using the same hostname, port, username, and password configured in DMS.
   • If the VM cannot connect, the issue is purely networking/firewall and must be fixed before DMS will work.
4. Recreate or reconfigure the DMS project after connectivity is fixed
   • In the DMS project wizard:
     • On Select source, ensure the correct source server name, port, username, and password are used.
     • On Select target, choose the target flexible server and provide the correct credentials.
   • Then select the databases and tables to migrate and start the migration once validation passes.

Efficient approach for the 20 TB reporting database:

For very large MySQL databases, use the DMS physical migration approach (Preview) with Percona XtraBackup to minimize downtime and improve performance:

1. Use DMS physical online data migration
   • DMS supports physical backup file–based migration from on-premises or VMs to Azure Database for MySQL flexible server using Percona XtraBackup.
   • This method is designed for large workloads and can restore the source server to the target flexible server with minimal downtime.
2. Prepare target flexible server for high-throughput migration
   • For faster data loads, configure the target flexible server with:
     • A General Purpose or Business Critical SKU with sufficient vCores (for example, 16 vCores or higher during migration).
     • Ensure the MySQL version on the target is greater than or equal to the source.
     • Set Availability Zone to “No preference” unless a specific zone is required.
   • After migration completes, scale down to the desired size.
3. Co-locate storage and target for performance
   • For physical migration, deploy the Azure Blob Storage used for backup files and the target flexible server in the same region to improve import performance.
4. Create and run the DMS physical migration project
   • Create a DMS instance (Premium 4 vCores is recommended; it is free for 183 days from creation).
   • Place DMS in a VNet with access to the source MySQL server (or backup location) and the target flexible server.
   • Create a MySQL physical migration project in DMS and follow the steps to:
     • Point to the backup files created by Percona XtraBackup.
     • Restore them into the target flexible server.
   • Monitor the migration and perform post-migration validation.
5. General migration flow
   • Create and configure source and target servers and networking.
   • Create the DMS instance.
   • Create a migration project specifying source, target, and objects to migrate.
   • Run the full load and then perform validation.
   • Perform a manual cutover/switchover once satisfied with the data.

For the 309 GB transactional database, the standard online data migration to Azure Database for MySQL – Flexible Server via DMS is appropriate once the cross-tenant connectivity issue is resolved. For the 20 TB reporting database, the physical migration with Percona XtraBackup is more efficient and scalable.

References:

• Tutorial: Migrate from MySQL to Azure Database for MySQL - Flexible Server online using DMS via the Azure portal
• Tutorial: Migrate from MySQL to Azure Database for MySQL using DMS physical migration with the Azure portal (Preview)
• FAQ about using Azure Database Migration Service
• Known Issues With Migrations To Azure Database for MySQL