Microsoft has introduced a paid Extended Support program for Azure Database for MySQL, automatically enrolling servers that run community end-of-life versions and charging customers on a per-vCore, per-hour basis. The move gives enterprises breathing room to upgrade from MySQL 5.7 and 8.0 without rushing into production outages, but it also locks them into a time-boxed, fee-based stopgap that demands a concrete migration plan.

The program, detailed in the official Azure version support policy, ends the era of informal, free-of-charge transitional support that followed MySQL community retirements. Starting with MySQL 5.7 – which reached community end-of-life on October 31, 2023 – Azure’s Standard Support will continue until July 31, 2026. On August 1, 2026, servers still on 5.7 will automatically move into Extended Support, where they will remain until March 31, 2029, unless upgraded. For MySQL 8.0, community retirement hits April 30, 2026; Azure Standard Support wraps up December 31, 2026, and Extended Support kicks in on January 1, 2027, running through May 31, 2029.

These dates are the final word from Microsoft Learn, correcting earlier reports that pegged 5.7 Standard Support ending in March 2026 and 8.0’s ending in May 2026. The discrepancy underscores how quickly the schedule solidified: organizations must now plan against the official milestones.

What Extended Support Actually Delivers

Extended Support is not a traditional support plan but a feature of the Azure Database for MySQL service. It provides:

  • SLA-backed availability for the managed service infrastructure, though the SLA does not cover every engine-level defect.
  • Critical security updates – patches for high-severity vulnerabilities identified during the window. Minor version bumps, feature enhancements, and non-critical bug fixes are explicitly excluded.
  • Technical support from Azure engineers to help manage upgrades or mitigate service-level issues.
  • Automatic enrollment – no opt-in or configuration needed. Once a version enters its Extended Support phase, all servers on that version are enrolled and charged after a one-month grace period.
  • Per-vCore, per-hour billing that stops the moment a server is upgraded to a version within Standard Support.

This narrow focus – security and uptime, not engine evolution – reveals the program’s true intent: a paid bridge, not a long-term home.

Pricing: A Calculated Cost for Delaying Upgrades

Pricing is published on the Azure pricing calculator and follows a straightforward model: per vCore, per hour. Microsoft originally targeted September 2025 for disclosing rates, and those details are now live. The cost multiplies for large fleets: a tiny dev/test instance with 2 vCores might rack up pennies an hour, but a production cluster spanning tens of vCores can accumulate substantial monthly bills if the Extended Support window is fully consumed.

Billing begins after a one-month grace period following the community end-of-support date of the MySQL version. For MySQL 5.7, that means charges start roughly in early November 2023 – though note that Standard Support continues without charge until July 2026, so the grace period essentially covers the initial post-EOL month before Standard Support’s protections apply. For MySQL 8.0, the grace period follows its April 2026 community retirement and precedes Extended Support billing in January 2027. Microsoft clarifies that servers in a “stopped” state are not billed; only those actively running (succeeded state) incur fees.

IT buyers should model worst-case costs by multiplying current vCore counts by an assumed hourly rate, then by the number of hours until a planned upgrade. Since the program is pay-as-you-go, the total expense scales directly with how long the organization procrastinates.

Why Enterprises Are Paying for More Time

MySQL 5.7 remains deeply embedded in business-critical applications – CRM systems, e-commerce backends, and custom ERP modules – many of which depend on specific query behaviors, connector versions, or stored procedures that break under MySQL 8.0’s stricter sql_mode, removed features, or changed authentication defaults. Forced upgrades have historically caused cascading failures when teams discover incompatible third-party libraries or vendor-certified stacks only in production.

Extended Support answers that pain by converting a hard cutover into a defined, billable transition period. It mirrors the logic behind Extended Security Updates (ESU) for Windows Server and SQL Server: pay for time, maintain security, and reduce immediate risk while acknowledging that the long-term answer is modernization. Analysts have often warned that such programs can mask growing technical debt, and the same caution applies here – every hour of Extended Support is an hour not spent on a permanent fix.

Upgrade Paths That Avoid the Bill

Microsoft recommends – and Azure documents – several ways to avoid Extended Support charges altogether. Each comes with its own tradeoffs in downtime, testing effort, and complexity.

In-Place Major Version Upgrade (MVU)
Azure Database for MySQL Flexible Server enables an in-place upgrade from 5.7 to 8.0 via portal, CLI, or ARM templates. A built-in Validate tool checks schema compatibility and flags deprecated settings before the actual migration. Downtime varies with database size; Burstable SKUs may need a temporary compute tier change. Microsoft strongly advises performing the upgrade on a restored copy first.

Replica-Based Minimal-Downtime Upgrade
For mission-critical workloads, the pattern is to create a read replica, upgrade the replica to 8.0, verify application compatibility, and then promote the replica to primary. This reduces production cutover to a brief window. The detailed workflow, including replication sync checks, is outlined in the Azure tech community blog with step-by-step guidance.

PITR-Based Validation
Point-in-time restore (PITR) lets teams create a restored copy of a production server, run a full upgrade test, and validate schema, performance, and runtime behavior without touching the live environment. On-demand backups taken right before the final upgrade provide a rollback safety net.

Best Practices Microsoft Stresses
- Use both Oracle’s MySQL upgrade checker (for deep client-side analysis) and Azure’s Validate tool.
- Upgrade read replicas before primaries to preserve replication compatibility.
- Schedule validation during low-traffic windows to avoid locking or timeouts.
- Document and test the restore process for pre-upgrade backups.

Benefits, Risks, and the Pragmatic Trade-Offs

Upsides
- Operational breathing room: Avoids rushed, poorly tested upgrades.
- Managed security: Critical patches reduce exposure to high-severity CVEs.
- No manual enrollment: Servers are automatically covered, removing administrative gaps.
- Budget predictability: Published dates and per-vCore billing make financial planning straightforward.

Downsides
- Technical debt accrual: Extended Support is a temporary crutch; leaning on it for years inflates the eventual migration scope.
- Patch scope limitations: Only critical security updates are guaranteed. Important but non-critical bugs may remain unfixed, and feature parity is not promised.
- Potential for unplanned downtime: Microsoft’s docs warn that in extreme cases, it may stop compute nodes to protect the service against a live engine vulnerability, which could cause unforeseen outages.
- Cost at scale: Hourly vCore billing adds up. An organization with 100 vCores on 5.7 could see four-figure monthly charges if the upgrade is delayed a full year.

A Tactical Migration Checklist for IT Leaders

  1. Inventory and Prioritize – Catalog all Azure MySQL servers by version, vCore count, and criticality. Flag any with third-party connectors or vendor-locked stacks.
  2. Compatibility Assessment – Run Oracle’s upgrade checker locally and Azure’s Validate tool. Address deprecated sql_mode values or removed features.
  3. Build Test Environments – Use PITR to restore a copy and perform a full upgrade; for minimal-downtime plans, create a read replica and test the promotion workflow.
  4. Backup and Rollback – Take on-demand backups before any production MVU and confirm that restore procedures are documented and tested.
  5. Schedule and Communicate – Plan upgrades during low-traffic windows; estimate downtime based on replica test results and alert stakeholders.
  6. Cost Modeling – If Extended Support is unavoidable, calculate per-vCore fees using current pricing and set a firm deadline for upgrade completion. Revisit the Azure pricing calculator for the latest rates.
  7. Engage Support – For complex environments, open a Microsoft support case or involve a migration partner to de-risk the process.

Beyond Extended Support: Long-Term Modernization

Extended Support is a mitigation, not a destination. Once the immediate pressure is off, teams should move workloads to MySQL 8.0 or 8.4 on Flexible Server, or even consider Azure Database for MySQL – Hyperscale if scale-out patterns fit. Alternatives like containerized MySQL on AKS or cloud-native databases (e.g., Azure Cosmos DB for PostgreSQL) may better align with future architecture goals. Hybrid options using Azure Arc can keep data on-premises while centralizing management and patching – a path that reduces the temptation to overstay on legacy versions.

The clock is ticking, and the program’s design makes the economics plain: the longer you wait, the more you pay. For organizations with MySQL 5.7 or 8.0 still humming in production, the next 90–180 days should be spent on discovery, compatibility testing, and a concrete upgrade schedule. Extended Support is there as a safety net, not a hammock. Use it strategically, price it into your cloud budget, and keep the end of support dates on your dashboard – because when the bridge ends, there is no further extension.