· ReadyStack
Worked example
Real numbers from this tool, line by line.
Azure MySQL Extended Support: 6 findings in one 44-line Terraform file, and for the Azure platform engineer in the US who owns it, 4,905.60 dollars a year at the East US list price once all three servers are billed.
| Line | Server | Pin | Billed from | Per year |
|---|---|---|---|---|
| L11 | orders (4 vCores) | 5.7 via var default | 2026-10-01 | 2,452.80 USD |
| L19 | billing (2 vCores) | 8.0.21 | 2027-02-01 | 1,226.40 USD |
| L29 | billing_replica (2 vCores) | 8.0.21 | 2027-02-01 | 1,226.40 USD |
The other three findings are what breaks the upgrade itself: L22 says the replica has to be upgraded before its primary, L33 sets query_cache_type (removed in MySQL 8.0), and L40 sets default_authentication_plugin (removed in MySQL 8.4).
What Azure changed
The Azure Database for MySQL version policy page (last updated 2026-09-11) gives the dates. Azure standard support for MySQL 5.7 ended on 2026-09-30. From 2026-10-01 every server still running 5.7 is enrolled in Extended Support automatically and charged per vCore per hour. MySQL 8.0 follows: standard support ends 2027-01-31 and Extended Support billing starts 2027-02-01. Extended Support ends on 2029-03-31 for 5.7 and 2029-05-31 for 8.0.
Stopped servers are not charged. Read replicas and HA-enabled servers are billed for the extra vCores they consume. The Azure retail price API lists the meter "Extended Support vCore" at 0.07 USD per hour in East US, effective 2025-11-01. That is 613.20 USD per vCore per year (0.07 × 8,760 hours).
Why the portal button is not the fix
The portal has an Upgrade button, and the az CLI has az mysql flexible-server upgrade. Both change one server. Neither changes the file that created it. If main.tf still says version = "5.7", the next environment you build from it is a fresh 5.7 server, enrolled in Extended Support on day one. The pin can also hide: in the sample, the orders server reads version = var.legacy_mysql_version, and only the variable default on line 3 says 5.7.
The migration path, line by line
Microsoft's major version upgrade article gives 5.7 to 8.0 and 8.0 to 8.4 as its examples. So for a 5.7 server the map writes version = "8.0.21", apply, then version = "8.4". For an 8.0 server it writes version = "8.4" directly. The Terraform azurerm provider accepts 5.7, 8.0.21 and 8.4 for that argument; Bicep and ARM take '5.7', '8.0.21' and '8.4'.
Before each step:
- Upgrade read replicas first. Until they are done, the primary's Upgrade is disabled.
- Delete parameters the target version removed: query_cache_type, query_cache_size and tx_isolation for 8.0; default_authentication_plugin and expire_logs_days for 8.4.
- Run the community upgrade checker for 8.0 to 8.4, because Azure online validation does not cover that step yet.
- Plan for mysql_native_password: Azure keeps it enabled, but 8.4 creates new accounts with caching_sha2_password.
What the map does
mysql 8.4 Azure Extended Support Map runs 9 rules over Terraform, Bicep, ARM JSON and az CLI scripts. It reads variable defaults, HA blocks and sku_name, so each finding carries the line, the billing date, the days left or days already billed, the yearly vCore cost and the exact replacement line.
Checking one file is complete without a key. The licence key covers the next job: a whole-workspace sweep that writes a dated Markdown migration plan, and a CI step that fails any build adding a new 5.7 or 8.0 pin.
15 seconds — what it actually does
Questions people ask
What does mysql 8.4 Azure Extended Support Map do?
It reads Terraform, Bicep, ARM JSON and az CLI files and lists every Azure Database for MySQL server pinned to 5.7 or 8.0, with the file line, the Extended Support billing date, a yearly vCore cost at 0.07 USD per vCore-hour, and the exact version = "8.4" line to write. It also flags server parameters removed in 8.0 or 8.4 and replicas that must be upgraded first.
Who is this for?
Azure platform engineers, DevOps teams and consultancies that manage Azure Database for MySQL flexible servers as code in Terraform, Bicep or ARM templates. It fits teams that saw Extended Support appear for MySQL 5.7 after 2026-10-01, or that still run 8.0 servers which start billing on 2027-02-01.
Why not just click Upgrade in the Azure portal?
The portal upgrades one server, but your Terraform or Bicep file still says version = "5.7" or "8.0.21", so the next apply or a rebuilt environment brings the old pin back. This map reads the code itself and shows each line to change, including versions hidden in variable defaults and removed parameters like query_cache_type.
What is free and what needs a licence key?
Free, with no key: check any single open file and get every finding, billing date, cost and replacement line. The licence key adds a whole-workspace sweep that writes a dated Markdown migration plan, plus a CI step that fails any build adding a new 5.7 or 8.0 pin. The answer itself is never locked.
How does the cost compare with staying on Extended Support?
Azure lists Extended Support at 0.07 USD per vCore-hour in East US. One 4-vCore server left on 5.7 costs 2,452.80 USD a year, and the sample file with one 5.7 and two 8.0 servers totals 4,905.60 USD a year once 8.0 billing starts. The full version is a one-time 29 USD licence.
When is the next Azure MySQL billing change?
MySQL 8.0 leaves Azure standard support on 2027-01-31 and is billed as Extended Support from 2027-02-01. Extended Support itself ends on 2029-03-31 for 5.7 and 2029-05-31 for 8.0, according to the Azure Database for MySQL version policy page last updated 2026-09-11.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.