Migration Blocker: Importing MySQL Dump with keyring_file encryption to Azure Database for MySQL Flexible Server

Virender Jain 65 Reputation points
2026-04-13T12:05:00.2433333+00:00

Hi,

My team is preparing to migrate a fleet of self-hosted MySQL VMs (ranging from 30GB to 150GB) to Azure. These instances currently use at-rest encryption via the keyring_file plugin. We have conducted preliminary research and internal technical reviews, but we require expert validation from the Azure Database team before finalizing our migration roadmap.

Primary Questions from our leadership:

  1. Migration Path: What is the best/recommended way to migrate from a self-hosted MySQL server where default MySQL encryption is enabled via the Keychain (Keyring) plugin to Azure Managed Databases?
  2. Decryption Workflow: Does the source MySQL data need to be manually decrypted (e.g., ALTER TABLE ... ENCRYPTION='N') before taking and importing the mysqldump?

When we try to explore these question via AI tools then got multiple diffrent kind of responses like:

  1. The Encryption Blocker Azure Managed MySQL (PaaS) does not support the "Keyring" plugin because it requires access to the underlying server files, which Azure hides from users. To use the Managed service, we must remove the encryption requirement from our data scripts before importing. What is best way to do so?
  2. Decryption is Not Mandatory on Source Research suggests we do not need to decrypt the live production database. Instead, we can take a "Logical Dump" (data script) and simply edit the text to remove the ENCRYPTION='Y' command. This allows the data to be imported into Azure without affecting the live source.
  3. Managed MySQL Security If we move to the Managed service, we lose our "Keyring" plugin, but we don't lose security. Azure provides its own Transparent Data Encryption (TDE) at the storage level, which is managed by Microsoft and meets most compliance standards.
  4. The "Lift & Shift" Alternative (IaaS) If we use an Azure Virtual Machine instead of the Managed service, we can keep our exact current setup. We would copy our Keyring files and the plugin to the new VM, and the database would work exactly as it does today with zero changes to the code. Is the "Lift & Sift" work with/without DMS?
  5. Technical Debt vs. Speed Using a VM (IaaS) is faster and easier for the initial move. However, using the Managed service (PaaS) reduces our long-term workload because Azure will handle the backups, security patching, and hardware scaling for us. Help us to make choose between IasS vs Paas?
  6. The "Managed" Future If we choose the VM path today to save time, we will eventually have to solve these encryption issues later if we ever want to move to a Managed service. It is a choice between "solving the problem now" or "moving quickly and solving it later."
  7. Secure Connectivity & VPN Requirements Since our source is private, we must establish a secure tunnel (S2S VPN or an Azure-hosted VPN Client) to move 150GB safely. We need to validate if our current OpenVPN/Cisco setup can maintain a stable, high-bandwidth connection for several hours without dropping, or if we need a dedicated Azure VPN Gateway for a more "production-grade" transfer.

We are looking forward to inputs from experts from the Azure Database team before finalizing our migration roadmap.

Regards,

Virender jain

Azure Database Migration Service

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.