MySQL 8.0 support ended in April; count your instances

Check the date. MySQL 8.0 left Oracle extended support on April 30, 2026. That was four and a half months ago. No more security patches on the 8.0 series, and no invoice or dashboard told you, because a database that starts every morning looks exactly like a supported one.

This deadline gets missed more than the Windows ones, and the reason is boring: MySQL is rarely the system. It is under the system. It came bundled with the wiki in 2019, inside the vendor appliance, under the timesheet app the intranet team owns. The teams that run those boxes patch the app and never think of themselves as database administrators, because nobody ever told them they were. Same mechanism as the database that stayed after its application left.

So run the census this month. The procedure fits in a week of half days.

1. Sweep for listeners on 3306 and 33060 across every subnet, then sweep the container registries and compose files for mysql: images. The port scan finds the servers; the registry scan finds the ones that only exist on Tuesdays.
2. Record the version string from the server itself (SELECT VERSION()), not from the install docs. Appliances lie in their manuals and tell the truth on the wire.
3. Write down an owner per instance. Not a team, a name, per the ownership rule. The instances with no name attached go to the top of the risk list, not the bottom of the backlog.
4. Note what each one holds. A cache someone can rebuild is not the same finding as nine years of order history.

Then triage. Three piles, dates attached.

Upgrade the easy ones now. 8.0 to 8.4 LTS is a minor-feeling major: test the deprecated auth plugin, test replication settings, move. 8.4 has premier support to April 2029, which buys the estate three quiet years. Book the first candidate for October, not for "after the freeze," because the freeze, as we have written before, is never as frozen as the calendar claims.

Escalate the bundled ones. Where MySQL lives inside a vendor product, the version is the vendor's problem, in writing. Open a ticket asking which supported series their current release ships and when they certify 8.4 or 9.7. A vendor who cannot answer by November has answered.

Leave the last pile alone on purpose, with the controls priced in. An air-gapped 8.0 instance under a system already scheduled for retirement in March does not need a database migration; it needs a deliberate decision to stand still, a note in the risk register, and a firewall rule the auditor can read. Unsupported and unmanaged are different findings. The first is sometimes a fine trade. The second never is.

Two dates for the wall. April 2029: MySQL 8.4 premier support ends, so the estate you migrate this winter needs its next plan by then anyway. And whatever date your census finishes: put it in the calendar now, because the count is the deliverable. Our inventories keep producing the same surprise, per the standing rule: the estate holds roughly a third more MySQL than anyone believed, and the extra third is always the unpatched third.

The dolphin did not send a retirement notice. The port scan is the retirement notice. Run it.