MySQL 5 to 8 migration checklist

Two dates to plan around. Oracle moved MySQL 5.7 to Sustaining Support on 25 October 2023, and its documentation says MySQL 8.0 reached end of life in April 2026. So 8.0 is now a stop on the way rather than a destination. MySQL 8.4 can be reached from 8.0, not directly from 5.7.

• Take a full backup and restore it somewhere else. A backup you haven’t restored is only a hope.
• Record row counts and totals for tables that hold money, stock and customers, so you have something to compare.
• List everything that connects: the application, reports, cron jobs, spreadsheets, other systems.
• Note the character set of the server, each database, table and column. They often differ on old systems.
• Save the current sql_mode and configuration file. You will want to compare them later.

MySQL Shell’s upgrade checker covers 5.7 and later, and looks for reserved keywords, removed functions, zero dates, old temporal columns, utf8mb3 and authentication problems among other things. It doesn’t support anything older than 5.7, so on an older system, run it against your staging copy once that reaches 5.7.

mysqlsh -- util checkForServerUpgrade user@localhost:3306 --target-version=8.4.0 --output-format=JSON
mysqlcheck -u root -p --all-databases --check-upgrade

• Old temporal columns. In-place upgrade isn’t supported if TIME, DATETIME or TIMESTAMP columns are still in the pre-5.6.4 format. Upgrade them with REPAIR TABLE first.
• Partitioned tables on an engine without native partitioning, such as older MyISAM tables. Convert them to InnoDB or remove the partitioning.
• Long names and values. Foreign key constraint names over 64 characters, and ENUM or SET elements over 255 characters or 1,020 bytes, cause the upgrade to fail.
• Reserved words. Some names that were fine in 5.7 are reserved in 8.0. A column called rank is a typical case. Quote identifiers with backticks.
• lower_case_table_names. Don’t plan to change it at upgrade time. In 8.0 the server won’t start with a value different from the one it was initialised with.
• Removed SQL modes. Take NO_AUTO_CREATE_USER out of your configuration, or the 8.0 server won’t start.

The full lists are in the manual: changes in MySQL 8.0 and changes in MySQL 8.4.

This is the part most checklists leave out. On the cabinet manufacturer’s move from MySQL 5.0 to 8, we validated data at every step and checked workflows against the old system in parallel. A check like that can include:

1. Row counts per table, old against new.
2. Sums on money and quantity columns, grouped by month or by customer, so an error can be located.
3. Text comparison on a sample with accents and symbols, because encoding damage is invisible in counts.
4. Date checks on any column that held zero dates, and a written decision on what those values mean now.
5. Real workflows run on both systems with the same input, comparing the results.

Write down how you will decide to go ahead before you run the cutover, and keep the old server untouched until you have decided.

• Rehearse the whole migration on a copy, and time it. That time sets your maintenance window.
• Stop writes to the old database during the final copy, and record the moment you did.
• Keep a tested way back, and decide in advance how long it stays valid once new data starts arriving.
• Watch slow queries for the first week. 8.0 and 8.4 change defaults that can shift query plans.
• Run your reports early. They tend to use the oldest SQL in the building.

A database move rarely happens on its own, since old MySQL usually comes with old PHP. See the PHP upgrade matrix for that side, and MySQL development if you only need database work.