MySQL 8.0 to 8.4 LTS migration checklist

MySQL 8.0 is no longer the obvious safe default. Oracle announced that, as of April 21, 2026, MySQL 8.0 is covered under Oracle Sustaining Support, and users are encouraged to upgrade to MySQL 8.4 LTS or 9.7 LTS.

Source facts last checked May 3, 2026: MySQL product support EOL announcements and MySQL release model documentation.

For most production PHP, Laravel, WordPress, and WooCommerce systems, MySQL 8.4 LTS is the conservative planning target. The point is not to chase the newest database release. The point is to land on a supported LTS line with a tested rollback path.

1. Confirm the database you actually use

Start from the application connection, not the hosting dashboard.

• SELECT VERSION();
• server package source
• primary and replica versions
• managed database engine family
• backup tool version
• client driver used by the application
• ORM or query builder version

If production has replicas, report exports, or admin tools, include them. A database upgrade that only tests the primary web app can still break the reporting job that runs every Monday morning.

2. Decide whether 8.4 LTS is direct or staged

MySQL 8.0 to 8.4 is a smaller jump than 5.7 to 8.0, but it is still a database migration. Use the vendor-supported path for the platform you are on. Managed hosts, cPanel, cloud databases, and self-managed packages may expose different upgrade routes.

Choose a direct 8.0 to 8.4 path when:

• backups restore cleanly
• the app already runs cleanly on recent 8.0 patch releases
• the connector and ORM support 8.4
• staging can mirror production data and configuration

Stage the work when:

• 8.0 is several patch levels behind
• replication is involved
• the hosting platform controls package upgrades
• there are old client libraries
• the application has no database smoke tests

The safest plan is the one you can explain and reverse.

3. Check compatibility before data movement

Most MySQL upgrade pain is application behavior, not the database booting.

Review:

• SQL modes, especially assumptions around grouping and invalid dates
• character set and collation defaults
• reserved words used as column names or aliases
• JSON functions and generated columns
• stored procedures, triggers, and events
• authentication plugin and client-library support
• full-text search behavior
• indexes that exist only to rescue slow legacy queries
• backup and restore tooling

If the system came from MySQL 5.7 originally, also read the existing MySQL 5.7 EOL upgrade checklist. Old 5.7 assumptions often survive inside an 8.0 database.

4. Test with production-shaped data

Database upgrades lie when tested against tiny seed data.

Use a recent anonymized production copy where possible, then run:

• application boot and migrations
• core read/write flows
• checkout, payment, order, invoice, or billing flows
• search and reporting queries
• long-running exports
• queue jobs that write to the database
• cron jobs that aggregate or delete data
• backup, restore, and point-in-time recovery process

Record query plans for the slowest business-critical queries before and after. The migration is not complete if the database starts but the monthly report now takes an hour.

5. Plan rollback around data writes

Database rollback is harder than application rollback because writes continue after cutover.

Write down:

• the final backup point
• whether binary logs are retained
• how replicas are promoted or rebuilt
• whether the old database can remain read-only
• how application writes are paused during cutover
• what triggers rollback
• who has authority to call rollback

For smaller VPS-hosted apps, a short maintenance window may be safer than pretending a live migration is free. For larger systems, use replicas, rehearsal cutovers, and explicit write-freeze windows.

6. Pair database work with runtime planning

MySQL rarely moves alone. PHP, Laravel, WordPress, WooCommerce, and Ubuntu support windows tend to collide.

Do not bundle every upgrade into one production weekend unless the system is small and the rollback path is clean. Sequence the work:

1. map current versions
2. prove backups and restore
3. create production-shaped staging
4. upgrade one major layer
5. run smoke and performance checks
6. document the new baseline

That sequencing is the same operating model as the PHP upgrade playbook and legacy PHP modernization.

When to audit first

Start with an audit when the system has no restore test, unclear replication, unknown query load, old Laravel or WordPress dependencies, or a hosting platform that may force database upgrades on its own schedule.

The useful output is a database risk register, cutover plan, smoke-test set, restore transcript, and a practical recommendation on whether MySQL 8.4 LTS can be reached directly or needs staging.