MySQL 8.0 Reached End of Life: Moving a Legacy App to MySQL 8.4 LTS

MySQL 8.0 end of life arrived on April 30, 2026, when Oracle's extended support for the version ended for good. The database does not stop running that day. It just stops getting security patches, bug fixes, or any help from Oracle if something breaks, for the rest of the time it stays in production. For anyone who has been putting off the upgrade, this is the point where "we'll get to it eventually" stops being a workable plan.

The path Oracle wants you on is MySQL 8.4, the first release in its new long-term support model. It is not a minor point release. One authentication plugin got turned off by default, one long-standing upgrade command disappeared, and a handful of server defaults changed. None of it is dramatic by itself, but it can break an application that nobody has touched since it shipped.

What MySQL 8.0 end of life actually means for your database

MySQL follows a fixed support schedule. Premier support, which includes new features and faster bug fixes, ran out first. Extended support, which covers security patches only, ran out on April 30, 2026. After that date, a newly discovered vulnerability in MySQL 8.0 stays unpatched for as long as you keep running it. No point release is coming to fix it, no matter how serious it turns out to be.

This tends to surface at an inconvenient time: a security questionnaire from a client, a compliance audit, or a hosting provider's notice that a plan tier is changing. "We were still on an end-of-life database version" is not a sentence anyone wants to explain after an incident.

Finding out what you're actually running

Run SELECT VERSION(); in a MySQL client, or check your hosting provider's dashboard; most control panels list the engine version somewhere in the database settings. If someone else manages the server, ask them directly: "What MySQL version are we on, and has anyone looked at the 8.4 upgrade?" How quickly and confidently they answer says something about how closely the database is actually being watched.

If the answer comes back as any 8.0 release, the clock has already run out on patches.

What actually changes between 8.0 and 8.4

Two changes are worth knowing before anyone touches a production server, because they're the ones most likely to break something quietly.

The mysql_native_password authentication plugin is disabled by default in 8.4. Older applications, especially anything running on PHP that hasn't had its database connection code touched in years, sometimes still authenticate with it. After the upgrade, those accounts fail to connect with an error like Plugin 'mysql_native_password' is not loaded. The fix is to move those accounts to caching_sha2_password, which PHP has supported since version 7.4: ALTER USER 'username'@'host' IDENTIFIED WITH caching_sha2_password BY 'password'. Find the affected accounts before you upgrade, not after, with SELECT user, host, plugin FROM mysql.user WHERE plugin='mysql_native_password'.

The mysql_upgrade command is gone. Older versions of MySQL needed it run by hand after an upgrade to fix up system tables. In 8.4, the server does that work on its own the first time it starts. That removes a manual step, but it also removes a checkpoint some upgrade scripts relied on.

The official 8.4 release notes list other removed options and changed server variables beyond these two. Most won't touch a typical web application, but if your codebase runs raw SQL against system variables, or uses an older ORM written against 8.0-specific behavior, it's worth reading that list rather than assuming none of it applies.

Test on a copy before you touch production

Copy the database to a separate server or container, install MySQL 8.4 there, and point a staging copy of the application at it. Mismatched authentication plugins, SQL syntax that no longer works, and any script calling mysql_upgrade directly will all surface there instead of in front of customers.

MySQL Shell includes an upgrade checker, util.checkForServerUpgrade(), that flags most of this automatically, including accounts still on the old authentication plugin. Running it against a copy of production before scheduling the real cutover catches the obvious problems in one pass.

Take a full backup before any of this starts, with mysqldump --single-transaction --routines --triggers --events or your provider's equivalent snapshot tool, stored somewhere other than the server being upgraded. If the live upgrade goes wrong, that backup, with a restore procedure you've actually tested beforehand, is what gets the system back up, rather than turning a planned change into a longer outage.

What managed hosting providers do about this

If the database runs on a managed platform, such as a cloud provider's managed MySQL service or a hosting company's database tier, ask what happens to 8.0 instances specifically on that platform. Some providers offer paid extended support that keeps 8.0 patched past April 2026 for an added fee. Others schedule an automatic upgrade on their own timeline rather than yours. A few simply stop offering new 8.0 instances while leaving existing ones running for now. None of these answers is wrong on its own, but each changes how much runway you actually have, so it's worth a direct question to your provider instead of an assumption.

A quick note on MariaDB

If the plan is to evaluate alternatives rather than upgrade in place, MariaDB is the option people usually bring up, since it started as a MySQL fork and stays broadly compatible. It's a reasonable path for some setups, but it's a separate migration with its own compatibility testing, not a drop-in swap, and it doesn't skip the work of checking an application against a different engine. For most businesses already on MySQL 8.0 with no specific reason to switch engines, upgrading to 8.4 is the simpler route.

A rollback plan, not just a backup

A backup and a rollback plan are not the same thing. Before upgrading anything in production, decide in advance how to roll back if a problem shows up after the switch, rather than working that out mid-incident. In practice that means keeping the old server available and unchanged for a defined window after cutover, having a restore procedure that's already been tested rather than just a backup file sitting somewhere, and knowing ahead of time who makes the call to roll back. Figuring this out under pressure is how a ten-minute rollback turns into a multi-hour outage.

The same discipline applies to any end-of-life deadline, not only this one. A yearly checklist for tracking what's approaching end of life across your stack is worth setting up if MySQL versions aren't the only thing you've been meaning to track. If the application sitting on top of this database is also running an unsupported language runtime, the same exposure applies there.

If you're bundling in schema changes

Teams sometimes combine a MySQL upgrade with schema changes they've been putting off, since both need a maintenance window anyway. If that's the plan, be careful running ALTER TABLE on large production tables during the same change. It carries a different kind of risk than the version upgrade itself, and doing it without downtime takes a different approach than a version bump does.

Where to start

Check your current MySQL version this week if you don't already know it, run the upgrade checker against a copy of the database, and fix any accounts still using mysql_native_password before scheduling the actual cutover. A focused tech stack review or a legacy system upgrade engagement can cover both the database work and anything in the application layer that depends on it.

If you'd like a second opinion before touching a production database, or help running the upgrade itself, reach out at hello@wolf-tech.io or visit wolf-tech.io. We've taken MySQL databases through version jumps like this one before, and the failures are almost always in an old authentication setting or a forgotten script, not in the database engine itself.