In-place automigration from Azure Database for MySQL – Single Server to Flexible Server
APPLIES TO: 
Azure Database for MySQL - Single Server
Important
Some Single Server instances might require mandatory inputs to perform a successful in-place automigration. Review the migration details in the Migration blade on Azure portal to provide those inputs. Failure to provide mandatory inputs 2 days before the scheduled migration will lead to re-scheduling of the migration to a later date.
In-place automigration from Azure Database for MySQL – Single Server to Flexible Server is a service-initiated in-place migration during planned maintenance window for Single Server database workloads with Basic, General Purpose or Memory Optimized SKU and no complex features (Read Replica, Virtual Network, Double Infra encryption, Service endpoint/VNet Rules) enabled. The eligible servers are identified by the service and are sent an advance notification detailing steps to review migration details.
The in-place migration provides a highly resilient and self-healing offline migration experience during a planned maintenance window, with less than 5 mins of downtime for General Purpose and Memory optimized SKU and up to 30 mins for Basic SKU.. It uses backup and restore technology for faster migration time. This migration removes the overhead to manually migrate your server and ensure you can take advantage of the benefits of Flexible Server, including better price & performance, granular control over database configuration, and custom maintenance windows. Following described are the key phases of the migration:
- Target Flexible Server is deployed, inheriting all feature set and properties (including server parameters and firewall rules) from source Single Server. Source Single Server is set to read-only and backup from source Single Server is copied to the target Flexible Server.
- DNS switch and cutover are performed successfully within the planned maintenance window with minimal downtime, allowing maintenance of the same connection string post-migration. Client applications seamlessly connect to the target flexible server without any user driven manual updates. In addition to both connection string formats (Single and Flexible Server) being supported on migrated Flexible Server, both username formats – username@server_name and username are also supported on the migrated Flexible Server.
- The migrated Flexible Server is online and can now be managed via Azure portal/CLI. Stopped Single Server is deleted seven days after the migration.
Note
If your Single Server instance has Basic SKU, your scheduled instance will be migrated with a downtime window of up to 30 minutes. The instance will be migrated to a higher General Purpose SKU to ensure a successful migration and will be downscaled to Burstable SKU in 24-48 hours. If post migration to Burstable SKU, your instance runs out of credits due to heavy CPU workload, consider upgrading to General Purpose SKU on the Flexible Server instance.
Note
If your Single Server instance has General Purpose V1 storage, your scheduled instance will undergo an additional restart operation 12 hours prior to the scheduled migration time. This restart operation serves to enable the log_bin server parameter needed to upgrade the instance to General Purpose V2 storage before undergoing the in-place auto-migration.
Eligibility
If you own a Single Server workload with no complex features (Read Replica, Virtual Network, Double Infra encryption, Service endpoint/VNet Rules) enabled, you can now nominate yourself (if not already scheduled by the service) for automigration by submitting your server details through an Azure Support ticket.
In order to make your ineligible server eligible for auto-migration perform the following steps :
- The Single Server instance should be in ready state and shouldn't be in stopped state during the planned maintenance window for automigration to take place.
- If your source Azure Database for MySQL Single Server has engine version v8.x, ensure to upgrade your source server's .NET client driver version to 8.0.32 to avoid any encoding incompatibilities post migration to Flexible Server.
- If your source Azure Database for MySQL Single Server has engine version v8.x, ensure to upgrade your source server's TLS version from v1.0 or v1.1 to TLS v1.2 before the migration as the older TLS versions have been deprecated for Flexible Server.
- If your server has Read Replicas, drop Read Replicas. You can configure Read Replicas post auto-migration.
- If your server has Service Endpoints (VNet Rules) or Virtual Network configuration enabled, consider dropping them or move to Private Link feature on your Single Server instance.
- If your server has Double Infrastructure Encryption enabled, consider moving to Customer Managed Key (CMK) feature on your Single Server instance.
Configure migration alerts
Servers eligible for in-place automigration are sent an advance notification by the service.
Following described are the ways to check and configure automigration notifications:
- Subscription owners for Single Servers scheduled for automigration receive an email notification.
- Configure service health alerts to receive in-place migration schedule and progress notifications via email/SMS by following steps here.
- Check the in-place migration notification on the Azure portal by following steps here.
Review and configure migration schedule and details
Following described are the ways to review your migration schedule once you receive the in-place automigration notification:
Note
The migration schedule is locked 2 days prior to the scheduled migration window after which you'll be unable to reschedule.
The Single Server overview page for your instance displays a portal banner with information about your migration schedule.
For Single Servers scheduled for automigration, a new Migration blade is lighted on the portal. You can review the migration schedule by navigating to the Migration blade of your Single Server instance.
If you wish to defer the migration, you can defer by a month at a time by navigating to the Migration blade of your single server instance on the Azure portal and rescheduling the migration by selecting another migration window within a month.
If your Single Server has General Purpose SKU, you have the other option to enable High Availability when reviewing the migration schedule. As High Availability can only be enabled during create time for a MySQL Flexible Server, it's highly recommended that you enable this feature when reviewing the migration schedule.
If your Single Server instance has one or more of Private Link, Customer Managed Key (CMK) and Microsoft Entra Admin enabled, the in-place auto-migration requires mandatory inputs for the private endpoints, CMK and Microsoft Entra Admin to be migrated from your Single Server instance to the target Flexible Server instance. The user inputs must be provided 2 days prior to the scheduled migration window. If the user inputs are not provided before the migration details are locked, your migration will be re-scheduled to a later point-in-time. After providing all inputs, ensure to Save the configuration in the auto-migration wizard. Steps to provide user input :
- Navigate to the Migration blade of your Single Server instance and select edit scheduled migration.
- In the Auto-migration details section click on Authenticate button to authenticate and save ARM API connection to migrate your server.
- If your server has Microsoft Entra Admin configured, you can provide inputs under the Microsoft Entra Admin section in the auto-migration wizard :
- Migrating Microsoft Entra admin for target server requires an Identity to be added to Azure Database for MySQL – Flexible Server. The Identity requires the following privileges – User.Read.All, GroupMember.Read.All and Application.Read.All to be granted. Please select an appropriate user assigned managed identity and grant the right permissions by following steps here.
- If your server has Customer Managed Key configured, you can provide inputs under the Data Encryption section in the auto-migration wizard :
- Migrating customer managed key encryption requires an Identity to be added to Azure Database for MySQL – Flexible Server. Please select an appropriate user assigned managed identity. The listed key identifier/key would be migrated from the source to target server and should be granted the following privileges – Get, Wrap Key, Unwrap Key in order to access the key vault.
- If your Single Server has private endpoints, perform the following mandatory steps when reviewing the migration schedule at least 2 days before the scheduled migration:
- Review the private endpoints listed to be migrated. Ensure they are marked as Ready to Migrate. If they are marked as ineligible, select the appropriate subscription and private DNS Zone.
- Custom Private DNS Zone are not supported by auto-migration. The Private DNS Zone must be privatelink.mysql.database.azure.com.
- The private endpoints connection approval method should be set as auto-approval and not manual approval. Manual approval private endpoints are not supported by auto-migration.
- Ensure you have the Subscription level or Resource Group level Contributor role access to avoid any permissions issue while authenticating.
- Select the confirmation checkbox after performing the listed prerequisite checks for migrating private endpoints.
- Review the private endpoints listed to be migrated. Ensure they are marked as Ready to Migrate. If they are marked as ineligible, select the appropriate subscription and private DNS Zone.
Note
If the mandatory inputs for migration are not provided at least 2 days before the scheduled migration, the migration is rescheduled to a later date.
Note
For Single Server instance with private endpoints, delete the Single Server source instance post migration validation. If no server delete operation is performed, the source instance is maintained until 14 days post which it will be deleted by the service.
Prerequisite checks for in-place automigration
Review the following prerequisites to ensure a successful in-place automigration:
- The Single Server instance should be in ready state and shouldn't be in stopped state during the planned maintenance window for automigration to take place.
- The Single Server instance's server parameters, settings, configuration and firewall rules should not be updated during the 2 day window prior to the scheduled automigration.
- For Single Server instance with SSL enabled, ensure you have all three certificates (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA and DigiCertGlobalRootCA Root CA) available in the trusted root store. Additionally, if you have the certificate pinned to the connection string create a combined CA certificate with all three certificates before scheduled automigration to ensure business continuity post-migration.
- The MySQL engine doesn't guarantee any sort order if there's no 'SORT' clause present in queries. Post in-place automigration, you might observe a change in the sort order. If preserving sort order is crucial, ensure your queries are updated to include 'SORT' clause before the scheduled in-place automigration.
- If your source Azure Database for MySQL Single Server has engine version v8.x, ensure to upgrade your source server's .NET client driver version to 8.0.32 to avoid any encoding incompatibilities post migration to Flexible Server.
- If your source Azure Database for MySQL Single Server has engine version v8.x, ensure to upgrade your source server's TLS version from v1.0 or v1.1 to TLS v1.2 before the migration as the older TLS versions have been deprecated for Flexible Server.
- If your source Azure Database for MySQL Single Server has firewall rule names exceeding 80 characters, rename them to ensure length of name is fewer than 80 characters. (The firewall rule name length supported on Flexible Server is 80 characters whereas on Single Server the allowed length is 12 8 characters.)
- If your source Azure Database for MySQL Single Server utilizes nondefault ports such as 3308,3309 and 3310, change your connectivity port to 3306 as the above mentioned nondefault ports aren't supported on Flexible Server.
How is the target MySQL Flexible Server autoprovisioned?
The compute tier and SKU for the target flexible server is provisioned based on the source single server's pricing tier and VCores based on the detail in the following table.
| Single Server Pricing Tier | Single Server VCores | Flexible Server Tier | Flexible Server SKU Name |
|---|---|---|---|
| Basic | 1 | Burstable | Standard_B1s |
| Basic | 2 | Burstable | Standard_B2s |
| General Purpose | 2 | GeneralPurpose | Standard_D2ds_v4 |
| General Purpose | 4 | GeneralPurpose | Standard_D4ds_v4 |
| General Purpose | 8 | GeneralPurpose | Standard_D8ds_v4 |
| General Purpose | 16 | GeneralPurpose | Standard_D16ds_v4 |
| General Purpose | 32 | GeneralPurpose | Standard_D32ds_v4 |
| General Purpose | 64 | GeneralPurpose | Standard_D64ds_v4 |
| Memory Optimized | 4 | MemoryOptimized | Standard_E4ds_v4 |
| Memory Optimized | 8 | MemoryOptimized | Standard_E8ds_v4 |
| Memory Optimized | 16 | MemoryOptimized | Standard_E16ds_v4 |
| Memory Optimized | 32 | MemoryOptimized | Standard_E32ds_v4 |
- The MySQL version, region, *storage size, subscription, and resource group for the target Flexible Server is same as that of the source Single Server.
- For Single Servers with less than 20-GiB storage, the storage size is set to 20 GiB as that is the minimum storage limit on Azure Database for MySQL - Flexible Server.
- Both username formats – username@server_name (Single Server) and username (Flexible Server) are supported on the migrated Flexible Server.
- Both connection string formats – Single Server and Flexible Server are supported on the migrated Flexible Server.
- For Single Server instance with Query store enabled, the server parameter 'slow_query_log' on target instance is set to ON to ensure feature parity when migrating to Flexible Server. For certain workloads this could affect performance and if you observe any performance degradation, set this server parameter to 'OFF' on the Flexible Server instance.
Post-migration steps
Here's the info you need to know post in-place migration:
Note
Post-migration do no restart the stopped Single Server instance as it might hamper your client's and application connectivity.
- Copy the following properties from the source Single Server to target Flexible Server post in-place migration operation is completed successfully:
- Monitoring page settings (Alerts, Metrics, and Diagnostic settings) and Locks settings
- Any Terraform/CLI scripts you host to manage your Single Server instance should be updated with Flexible Server references.
- For Single Server instance with Query store enabled, the server parameter 'slow_query_log' on target instance is set to ON to ensure feature parity when migrating to Flexible Server. Note, for certain workloads this could affect performance and if you observe any performance degradation, set this server parameter to 'OFF' on the Flexible Server instance.
- For Single Server instance with private endpoints, delete the Single Server source instance post migration validation. If no server delete operation is performed, the source instance is maintained until 14 days post which it will be deleted by the service.
- For Single Server instance with Microsoft Defender for Cloud enabled, the enablement state is migrated. To achieve parity in Flexible Server post automigration for properties you can configure in Single Server, consider the details in the following table:
| Property | Configuration |
|---|---|
| Suppress specific alert types | Disable specific alert types with the Microsoft Defender for Cloud platform. For more information, visit Suppress alerts from Microsoft Defender for Cloud guide. Single Server users can use the API property: properties.disabledAlerts |
| Email notifications | Define email notification for Microsoft Defender for Cloud Alerts for all resources in a subscription. For more information, visit Configure email notifications for security alerts. Single Server users can use the API properties: properties.emailAccountAdmins,properties.emailAddresses |
| Export alerts for further processing and/or archiving | Alerts are stored in the Microsoft Defender for Cloud platform and exposed through the Azure Resource Graph. You can export alerts to a different store and manage retention separately. For more information, visit Set up continuous export in the Azure portal - Microsoft Defender for Cloud. Single Server users can use the API properties: properties.retentionDays,properties.storageAccountAccessKey,properties.storageEndpoint |
Frequently Asked Questions (FAQs)
Q. Why am I being auto-migrated?
A. Your Azure Database for MySQL - Single Server instance is eligible for in-place migration to our flagship offering Azure Database for MySQL - Flexible Server. This in-place migration will remove the overhead to manually migrate your server and ensure you can take advantage of the benefits of Flexible Server, including better price & performance, granular control over database configuration, and custom maintenance windows.
Q. How does the automigration take place? What all does it migrate?
A. The Flexible Server is provisioned to match the same VCores and storage as that of your Single Server. Next the source Single Server is put to stopped state, data file snapshot is taken and copied to target Flexible Server. The DNS switch is performed to route all existing connections to target and the target Flexible Server is brought online. The automigration migrates the entire server's data files (including schema, data, logins) in addition to server parameters (all modified server parameters on source are copied to target, unmodified server parameters take up the default value defined by Flexible Server) and firewall rules. This is an offline migration where you see downtime of up-to 5 minutes or less.
Q. How can I set up or view in-place migration alerts?
A. Following are the ways you can set up alerts:
- Configure service health alerts to receive in-place migration schedule and progress notifications via email/SMS by following steps here.
- Check the in-place migration notification on the Azure portal by following steps here.
Q. How can I defer the scheduled migration?
A. You can review the migration schedule by navigating to the Migration blade of your Single Server instance. If you wish to defer the migration, you can defer by a month at the most by navigating to the Migration blade of your single server instance on the Azure portal and rescheduling the migration by selecting another migration window within a month. The migration details are locked seven days prior to the scheduled migration window after which you're unable to reschedule. This in-place migration can be deferred monthly until 16 September 2024.
Q. What username and connection string would be supported for the migrated Flexible Server?
A. Both username formats - username@server_name (Single Server format) and username (Flexible Server format) are supported for the migrated Flexible Server, and hence you aren't required to update them to maintain your application continuity post migration. Additionally, both connection string formats (Single and Flexible server format) are also supported for the migrated Flexible Server.
Q. How to enable HA (High Availability) for my auto-migrated server??
A. By default, automigration sets up migration to a non-HA instance. As HA can only be enabled at server-create time, you should enable HA before the scheduled automigration using the automigration schedule edit option on portal. HA can only be enabled for General purpose\Memory Optimized SKUs on target Flexible Server, as Basic to Burstable SKU migration doesn't support HA configuration.
Q. I see a pricing difference on my potential move from MySQL Basic Single Server to MySQL Flexible Server??
A. Few servers might see a small price increase after migration (estimated costs can be seen by selecting the automigration schedule edit option on the portal), as the minimum storage limit on both offerings is different (5 GiB on Single Server; 20 GiB on Flexible Server) and storage cost (0.1$ on Single Server; 0.115$ on Flexible Server) for Flexible Server is slightly higher than Single Server. For affected servers, this price increase in Flexible Server provides better throughput and performance compared to Single Server.