MySQL 8.0 to 8.4 LTS Migration Checklist

Organizations still operating MySQL 8.0 in production should be aware that Oracle moved this release to Sustaining Support in April 2026. In practical terms, this means no further security patches or bug fixes will be issued. Any new vulnerabilities discovered in 8.0 going forward will remain unaddressed, which represents a material and escalating risk for production systems.

AWS RDS MySQL 8.0 Support Ending

Standard support concludes on July 31, 2026. Use our RDS MySQL 8.0 EOL Cost Calculator to find your financial exposure to Extended Support fees.

The transition from 8.0 to 8.4 is considerably less disruptive than the earlier 5.7-to-8.0 migration. There is no change to the underlying data dictionary format, and the core query optimizer behavior remains largely consistent. However, Oracle used this version boundary to formally remove a number of features and variables that had been deprecated for an extended period. Any configuration or application code that still depends on these will cause the upgrade to fail, either immediately at startup or at runtime under specific conditions.

This blog outlines a complete, actionable checklist for planning and executing a migration from MySQL 8.0 to 8.4 LTS, supporting our specialized MySQL 8.4 Upgrade Services.

Understanding the Release Model

MySQL 8.4 is the first release under Oracle's revised versioning model, which distinguishes between Innovation releases (8.1, 8.2, 8.3 - short-lived releases intended for feature preview) and Long-Term Support releases (8.4, and subsequent LTS versions) intended for production stability. MySQL 8.4 LTS receives Premier Support through April 2029 and Extended (security-only) Support through April 2032, making it the appropriate target for organizations requiring a stable, supported baseline.

It should also be noted that MySQL supports upgrades only between adjacent major versions. Organizations still running MySQL 5.7 cannot migrate directly to 8.4, an intermediate upgrade to a current 8.0.x release is required first. This checklist assumes the source environment is already on a recent 8.0 patch release.

Breaking Changes That Will Prevent Server Startup

The following items must be addressed prior to upgrading. Each of these represents a hard failure condition, not a deprecation warning.

Task 1 - Authentication Plugin Changes

The mysql_native_password authentication plugin is disabled by default in MySQL 8.4. Any application accounts still relying on this plugin will be unable to authenticate following the upgrade. Prior to migration, run the following query to identify affected accounts:

SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';

Accounts returned by this query should be migrated to caching_sha2_password in advance of the upgrade. Where immediate migration is not feasible, the plugin may be temporarily re-enabled by setting mysql_native_password=ON in the server configuration. This should be treated strictly as a transitional measure, as the plugin is scheduled for full removal in a future release.

Task 2 - Removed Configuration Variables

Several variables deprecated in 8.0 have been fully removed in 8.4. Their presence in the configuration file will prevent the server from starting. Notable examples include:

• innodb_log_file_size and innodb_log_files_in_group, which have been consolidated into a single variable, innodb_redo_log_capacity. For example, a prior configuration of a 1GB log file with two files in the group (2GB total) should be replaced with innodb_redo_log_capacity=2147483648.
• default_authentication_plugin, replaced by the new authentication_policy variable.
• master_info_repository and related legacy replication parameters.

Configuration files should be reviewed against the complete list of removed variables prior to the upgrade. Detailed documentation on parameters is accessible in the official MySQL 8.4 Reference Manual.

Task 3 - Replication Terminology Changes

MySQL has completed its transition away from "master/slave" terminology in favor of "source/replica." Commands that generated deprecation warnings under 8.0 have been removed entirely in 8.4. CHANGE MASTER TO is now CHANGE REPLICATION SOURCE TO, and SHOW SLAVE STATUS is now SHOW REPLICA STATUS. All slave_* system variables have corresponding replica_* equivalents; for instance, slave_parallel_workers is now replica_parallel_workers. Any monitoring systems, orchestration tooling, or operational scripts using the legacy syntax will fail after the upgrade and should be identified and updated in advance.

Task 4 - AUTO_INCREMENT on FLOAT or DOUBLE Columns

This usage pattern, deprecated since MySQL 8.0.17, now generates a hard error (ER_WRONG_FIELD_SPEC) in 8.4. Schemas should be reviewed for any remaining instances prior to migration.

Task 5 - Nonstandard Foreign Keys

Foreign keys referencing non-unique or partial keys are rejected by default in 8.4 through the new restrict_fk_on_non_standard_key variable, which defaults to ON. This setting can be temporarily disabled during a transition period, but affected schemas should ultimately be corrected.

Task 6 - Index Prefix Columns in Partitioning Keys

Deprecated since MySQL 8.0.21, this feature has been removed in 8.4. Any partitioned tables relying on prefix-indexed partitioning keys will require redesign prior to migration.

Task 7 - Encryption Key Management: Keyring Plugins to Keyring Components

• Environments using InnoDB tablespace encryption, redo/undo log encryption, or encrypted persisted variables in MySQL 8.0 typically rely on keyring plugins such as keyring_file, deprecated since 8.0.24 in favor of equivalent keyring components (component_keyring_file, and so on).
• MySQL 8.4 does not support keyring plugins, so this migration must be completed before upgrading.
• Components are configured differently than plugins — via a startup manifest file (mysqld.my) and a separate component configuration file, rather than system variables — and existing keys must be transferred to the new keystore using mysql_migrate_keyring in key migration mode.
• Migration success should be confirmed via performance_schema.keyring_component_status before the old plugin is uninstalled. Skipping this step leaves the server unable to access encrypted tablespaces after the upgrade.

Changes That Affect Tooling and Operations Without Preventing Startup

FLUSH HOSTS Removal

This statement has been removed. Scripts relying on it to clear the host cache should be updated to use TRUNCATE TABLE performance_schema.host_cache instead.

Configuration Defaults

Existing configuration files should not be copied directly to the new environment without review. MySQL 8.4 introduces revised default values for several variables, including innodb_io_capacity and innodb_log_buffer_size, calibrated for more current hardware assumptions. Configuration should be evaluated against the new defaults rather than assumed to remain optimal.

Client Driver Compatibility

Application connectors and drivers should be verified for compatibility with caching_sha2_password and the current authentication handshake protocol prior to migration.

Recommended Migration Procedure

1. Update to the latest 8.0.x patch release. Ensure the source environment is on a current 8.0 build before beginning the migration to reduce the scope of changes introduced in a single step.
2. Conduct a full compatibility audit. Identify accounts using deprecated authentication plugins, configuration variables scheduled for removal, replication scripts using legacy terminology, and any schema elements affected by the changes described above. For an automated assessment, leverage the MySQL Shell Upgrade Checker Guide.
3. Establish a verified backup. Confirm that a recent backup exists and has been successfully restored in a non-production environment. A tested restore path is a prerequisite for any major version upgrade.
4. Rehearse the migration in a staging environment. Execute the full upgrade procedure against a non-production copy of the environment and validate application behavior prior to any production change.
5. Re-establish performance baselines. Compare query execution plans and performance metrics against pre-upgrade baselines to identify any regressions introduced by changes to optimizer behavior or default configuration values. Reference real-world scaling scenarios in our Mydbops Database Case Studies.
6. Execute the production cutover with a tested rollback plan. There is no supported downgrade path from MySQL 8.4 to 8.0. In the event of a failed migration, rollback consists of restoring from the backup taken in step 3. Restore time should be measured in advance and incorporated into the planned maintenance window.
7. Monitor system performance following cutover. Memory utilization, query latency, and I/O metrics should be monitored closely during the initial period following migration, as configuration tuning adjustments are common even when default values have improved. Refer to our Mydbops Managed Database Services for persistent performance management.

Additional Consideration: utf8mb3 Tables

Tables still using the legacy utf8 character set (functionally utf8mb3) are not automatically converted to utf8mb4 during the upgrade to 8.4. Deprecation warnings for this character set will become more prominent, but conversion remains a manual, separate undertaking. Organizations with outstanding utf8mb4 migrations should plan this as an independent project rather than combining it with the version upgrade itself.

Summary

While the migration from MySQL 8.0 to 8.4 LTS is comparatively low-risk relative to prior major version upgrades, it is not without operational impact. The majority of migration failures observed in practice stem from four sources: legacy authentication plugin usage, removed configuration variables retained in existing configuration files, replication tooling still referencing deprecated master/slave terminology, and — for encrypted environments — an unmigrated keyring plugin configuration. A thorough compatibility audit, a verified backup and restore procedure, and a staged rehearsal prior to production cutover address the majority of risk associated with this migration.

Given that MySQL 8.0 no longer receives security patches, the operational cost of completing this checklist is modest relative to the exposure associated with continued operation on an unsupported release.

Protect Your Infrastructure From Extended Support Fees

Standard support for MySQL 8.0 on Amazon RDS ended on July 31, 2026. Avoid automatic and compound extended support surcharges while eliminating security vulnerabilities. Let Mydbops execute your seamless transition to MySQL 8.4 LTS.