MySQL 8.0 Reached Sustaining Support: A Production Migration Plan to MySQL 8.4 LTS

MySQL 8.0 entered Sustaining Support on April 21, 2026, meaning that it will no longer receive active updates, apart from rare critical fixes under contract. A seemingly simple upgrade attempt can then reveal multiple problems: an unsupported MySQL 5.7 source server, replicas blocked by obsolete options, or an application calling a removed function. For example, calling WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), which was removed in MySQL 8.4, would produce an unexpected syntax error (see section 5). Sustaining Support is not an immediate shutdown, but it signals increasing operational risk and the need to plan the move to the current Long-Term Support (LTS) release, version 8.4, seriously. Refonte Learning's SQL Server 2016 end-of-support article reminds readers that each vendor has its own lifecycle; you cannot simply “apply a patch” in the same way across every database management system. This migration therefore requires a concrete inventory and plan, led by a SQL-focused database administrator (DBA) rather than a NoSQL DBA.

This guide presents a 14-step migration plan: inventorying instances, confirming the upgrade path, checking compatibility, choosing a method, rehearsing, cutting over, validating, and observing the new environment. Each step is assigned to an owner, including the DBA, platform team, site reliability engineering (SRE) team, application teams, and others, and has clear acceptance criteria. The goal is to move gradually to MySQL 8.4 LTS without an unexpected outage while preserving the ability to roll back until the last safe point.

1. Sustaining Support Changes the Risk Decision for MySQL 8.0

With MySQL 8.0 in Sustaining Support, the estate moves from an active support model to a residual support model. This changes the decision matrix: should you remain temporarily on 8.0, apply workarounds, migrate, replatform, or retire the affected database? Each option carries different risks and accountable parties, as summarized below.

Each option must be approved by the corresponding service owner. These decisions belong with the SQL DBA because they affect the core SQL engine and its compatibility, including how it differs from a NoSQL schema. For example, Refonte Learning's guide to SQL DBA versus NoSQL DBA specialization shows why SQL expertise matters in this type of project. In the next step, every 8.0 instance selected for migration must be inventoried precisely.

2. Discover Every MySQL 8.0 Instance and Dependency

Before any migration, create a complete inventory of every MySQL 8.0 database in production. Document each instance, whether physical, virtual machine (VM), container, or managed service, with at least the following information:

Keep this table current in your configuration management database (CMDB) or inventory tool. Automate discovery where possible using scripts, Ansible or Chef playbooks, and continuous integration (CI) pipelines to reduce omissions. See Refonte Learning's article on automating database administration with DevOps tools for an example of this type of process.

Also catalog every software dependency:

• Drivers and ORMs: list every connector, including JDBC, ODBC, Python, PHP, and Node.js, and every object-relational mapper (ORM), such as Hibernate, Django ORM, and ActiveRecord, used by applications. Record their versions and verify MySQL 8.4 compatibility, including authentication and SQL types. For example, an outdated driver may not support the caching_sha2_password plugin.

• Proxies and connection pools: identify ProxySQL, HAProxy, MySQL Router, and connection pools such as HikariCP and c3p0. Confirm that they accept the protocols and options used by 8.4, and determine whether an upgrade or reconfiguration is required.

• Backup and monitoring: inventory backup tools, including mysqldump, Percona XtraBackup, and cloud solutions; replication-related tools, including MySQL Router and mariadb-backup; and monitoring systems, including Prometheus exporters, MySQL Enterprise Monitor, and CloudWatch. Verify that supported versions cover MySQL 8.4 or that an upgrade is scheduled.

• CDC and ETL: if you use change data capture (CDC) tools such as Debezium, AWS Database Migration Service (DMS), or Maxwell, or extract, transform, and load (ETL) pipelines, confirm that they support the new version, including the 8.4 binary log, Global Transaction Identifiers (GTIDs), and character sets.

• Scripts and jobs: identify every administration script, cron job, batch job, and integration container that accesses the database. For example, a maintenance cron job that uses deprecated SQL syntax must be updated.

Finally, record the contracts, licenses, and guarantees associated with each instance, including Oracle MySQL Enterprise support, cloud support, or the absence of formal coverage, because these may determine available upgrade options and maintenance policies. This complete inventory is the foundation for every subsequent decision.

3. Confirm the Supported Upgrade Path to MySQL 8.4 LTS

The move to MySQL 8.4 LTS requires every source instance to be eligible. The manual specifies that an in-place upgrade from 8.0 to 8.4 is supported only from version 8.0.37 or later. In practical terms:

• MySQL 8.0 ≥ 8.0.37: a direct upgrade to 8.4 is possible through packages, binaries, cloning, or another supported method.

• MySQL 8.0 8.0.22–8.0.36: a direct upgrade is not supported. First upgrade the 8.0.x instance to version 8.0.37 or later, then migrate to 8.4.

• MySQL 5.7.x: there is no direct jump. Upgrade to MySQL 8.0 first, following the 5.7-to-8.0 path, and then upgrade from 8.0 to 8.4.

• Other forks, including Aurora, Percona, and MariaDB: these branches require a logical migration or a vendor-specific tool. For example, you cannot reinstall MariaDB binaries as MySQL; use a dump and reload or a data-replication method instead.

At the same time, verify that the operating system hosting MySQL is supported by version 8.4. If you are running an older Linux version that is not listed for 8.4, upgrade the operating system before changing the MySQL version. For each instance, run SELECT VERSION(); or mysqld --version to record the exact release. At this gate, confirm that every 8.0 instance meets the prerequisites, especially the minimum 8.0.37 source version, before making any change.

4. Run Upgrade Checker and Build the Remediation Backlog

Before upgrading anything, run MySQL Shell's Upgrade Checker Utility against every 8.0 instance with MySQL 8.4 as the target. MySQL recommends this tool to “detect incompatibilities” between versions. It inspects schemas, settings, and functions, then generates a report detailing the required corrections. For example, it flags use of the deprecated utf8mb3 character set or obsolete SQL mode flags such as MAXDB. It also provides guidance for cases that “cannot be automated,” including performance impact and application compatibility.

Follow this process for each instance:

1. Run mysqlsh> util.checkForServerUpgrade() and export the report in JSON or CSV format.

2. Classify the findings: critical blocking errors, warnings, and informational notes.

3. For each item, create a migration-backlog entry: describe the issue, assign an owner, such as a DBA, developer, or systems administration team, and plan a correction or documented justification.

4. Apply the fixes in a test environment, then rerun the utility to verify that all blocking errors have disappeared. For example, if the utility reports an obsolete sql_mode flag, remove or replace it and check again.

Do not rely on the utility alone. Add real application tests, including functional test suites and critical business queries, to validate code compatibility. Retain every report and log as documented evidence. Do not approve promotion to 8.4 until the utility reports no critical errors and the business tests pass.

5. Test Removed Features, Defaults, Authentication, and Privileges

Test every feature, mode, and option that was removed or changed in 8.4. Any dependency on those elements must be resolved. Examples include:

• Removed functions and syntax: run existing critical queries on a test MySQL 8.4 server. For example, the WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() function was removed, so any call will fail. Also check for removed legacy keywords or syntax, such as DISTINCTROW, LOCK TABLE, and GET_MASTER_PUBLIC_KEY, and correct the affected queries.

• Variables and modes: some system variables have changed or disappeared. For example, the old MAXDB SQL mode is no longer recognized. Replace tx_isolation with transaction_isolation. Ensure that no configuration uses syntax that is now prohibited, such as assigning NULL to a variable without the required privilege. Update my.cnf and session-level SQL settings accordingly.

• Authentication: MySQL 8.4 uses caching_sha2_password by default and disables mysql_native_password. Review every user account. If an account used mysql_native_password, convert it with ALTER USER ... IDENTIFIED WITH caching_sha2_password. Existing connections using the old plugin may continue to work temporarily, but creation of new native-password accounts is disabled; for example, Google Cloud SQL no longer permits mysql_native_password for new accounts. Update connection settings, including JDBC URLs, when required.

• Privileges and roles: review privileges in mysql.user and all roles. New 8.4 system tables may require additional privileges for some operations. For example, create a test replication user and verify that it has REPLICATION SLAVE/ADMIN. Test triggers and stored routines with their DEFINER because the new data dictionary may require definition updates.

• Collations and character sets: check whether schemas still use the legacy utf8 character set alias, utf8mb3. MySQL 8.4 supports utf8mb3 but recommends utf8mb4. If Upgrade Checker flagged it, consider migrating tables to utf8mb4 before or after the upgrade. Confirm that the default collation, such as utf8mb4_0900_ai_ci, does not affect applications.

In summary, exercise every schema feature and SQL code path against a test 8.4 server. Correct or document every error caused by the changes. A database is ready for upgrade only when it no longer calls removed functions or syntax and all accounts work with the new authentication modes and privilege model.

6. Compare SQL Semantics, Optimizer Plans, and Performance

Even when queries remain valid, moving to MySQL 8.4 can change execution plans and performance. Establish a performance baseline by comparing the old and new versions. MySQL explicitly recommends benchmarking workloads before and after migration.

Method: identify a representative query corpus, including key transactions, reports, and frequent operations, and run it on a test 8.0 server and then under the same workload on 8.4. Measure the following for each scenario:

• Latency, including average response time and p95 and p99 query percentiles

• Throughput, measured as transactions or queries per second

• Resource use, including CPU, memory, and disk input/output utilization

• MySQL resources, including temporary-table counts, locks or waits, and InnoDB input/output per query

• Execution plans: compare EXPLAIN output to detect changes, including additional table scans or different index use.

Set acceptance thresholds, such as allowing a 10% latency increase or a 5% throughput decrease, and record every regression beyond those limits. The following table shows sample criteria:

If a test exceeds the threshold, investigate indexes, statistics, and plans; a hint or setting may change the result. Repeat the tests after every optimization. MySQL notes that although the newer release is often faster, internal changes, including new indexes and InnoDB changes, can cause isolated regressions. The objective is to verify that overall performance remains within the approved margins.

7. Qualify Connectors, ORMs, Proxies, Backup, and Monitoring Tools

Every component around MySQL must be qualified for 8.4. For example:

• Drivers and ORMs: test connection drivers and ORMs against 8.4. Confirm compatibility with the new authentication protocol. For example, verify that the JDBC URL or Python library supports caching_sha2_password. Upgrade components where necessary. Refonte Learning's article on database integration for backend developers covers these general practices.

• Proxies and connection pools: if you use ProxySQL, HAProxy, MySQL Router, or another load balancer, verify 8.4 compatibility. Ensure that these components do not block new commands or parameters. At cutover, clear application and ProxySQL connection pools to force clients to reconnect.

• Backup and replication: verify that backup tools, including mysqldump, XtraBackup, and cloud services, work with the 8.4 format. For example, use an XtraBackup version that corresponds to MySQL 8.x. Also test any replication tooling, including buffer-pool-related functions, if applicable.

• Monitoring and metrics: update every monitoring agent, including Prometheus, Percona PMM, and Datadog, that queries MySQL. Some schemas, including performance_schema or information_schema tables, may have changed. Verify that every collection query works and adjust dashboards as needed.

• CDC and ETL tools: verify that Debezium, AWS DMS, Maxwell, and similar tools support MySQL 8.4 binary logs and GTIDs. If you use Liquibase or Flyway for schema migrations, configure them for 8.4 or update their drivers.

In summary, build a compatibility matrix covering drivers and ORMs, proxies, backup and export tools, monitoring, CDC, and related components. Where possible, test a connection from every component to a representative 8.4 database. Application integration must remain transparent.

8. Choose In-Place, Logical, or Replication-Assisted Migration

Choose the migration method based on downtime, additional capacity, and rollback constraints. Compare the approaches:

• In-place upgrade: install the MySQL 8.4 package on the existing server. This is quick to implement but requires a complete server outage. Run mysql_upgrade and checks such as mysqlcheck --check-upgrade before reopening the database. Rollback is possible only if you have a reliable 8.0 data-directory backup or snapshot, because the operation changes the internal schema.

• Dump and reload: create a complete export of the 8.0 database with mysqldump or MySQL Shell dump, then import it into a new 8.4 instance. This method creates a clear recovery point; retain the 8.0 dump for rollback. It can take a long time for large data volumes, but it lets you validate consistency through row counts and checksums before cutover. Rollback means redeploying the original dump or redirecting the application to the old database.

• MySQL 8.4 Clone: MySQL 8.4 provides a Clone Plugin that copies data from an 8.0 server to a new 8.4 instance online. This preloads the data, leaving only a brief outage, such as the DNS switch, to finalize the migration. If the migration fails, redirect traffic to the old server, provided it has remained read-only until cutover is confirmed.

• MySQL 8.4 replication (rolling upgrade): build one or more 8.4 replicas from the 8.0 primary using Global Transaction Identifiers (GTIDs). When the 8.0 primary and its replicas are ready, stop writes on the primary, wait for final replication, then promote an 8.4 replica to primary. Upgrade the former 8.0 primary offline afterward. This approach minimizes downtime to the promotion interval and supports a controlled failover. The MySQL manual recommends this rolling upgrade for replication topologies.

Choose according to your priorities. If you need near-zero downtime, prefer replication or cloning. If you can stop the application for longer, a dump and reload is robust. If the data volume is small, a simple in-place upgrade may be sufficient. Document the selected method, estimated downtime, and rollback plan clearly.

9. Upgrade Replication, Group Replication, and High Availability Safely

For primary-replica topologies, follow the rolling-upgrade procedure in the MySQL manual. In practice:

• Upgrade replicas first: for each 8.0 replica, stop the service, upgrade it to 8.4, and then restart replication with GTIDs enabled. Upgrade replicas in cascading order, from the bottom of the topology upward.

• Switch the primary: stop writes on the old 8.0 primary. Confirm that every replica has caught up, with Seconds_Behind_Master = 0. Promote an 8.4 replica as the new primary by changing DNS or switching the endpoint.

• Upgrade the former primary: while it is offline, upgrade the former primary from 8.0 to 8.4. Reintroduce it into the topology if required.

This sequence preserves replication continuity with minimal client downtime. MySQL specifically instructs operators to upgrade replicas before the primary. During the process, verify replication settings such as binlog_format=ROW, GTID, and log_slave_updates.

For InnoDB Cluster and Group Replication, MySQL 8.4 adds flexibility: a group can contain nodes running different 8.4.x versions during the upgrade. You can therefore upgrade one node at a time online and rejoin it to the group. Ensure, however, that all nodes remain within the 8.x series; an 8.4 cluster cannot contain an 8.0 node. For planned downtime, you can choose an offline approach by stopping the cluster, upgrading it, and restarting it. In every case, run a failover test to confirm that MySQL Router or your high-availability solution supports the upgraded 8.4 members.

10. Rehearse Backup, Restore, Cutover, and Failure Recovery

Do not leave anything to chance. Run a complete rehearsal with production data. For example:

• Restore test: restore the latest full 8.0 backup in a test environment. Confirm that it restores without error by checking row counts and data integrity. MySQL emphasizes that you should verify that a complete, viable backup exists before the upgrade.

• Dry-run migration: on the restored test instance, execute the complete migration plan using the selected method. Measure the time required for every step, including dump, transfer, and import, and adjust the scripts as needed.

• Failure simulations: inject failures during the test, such as a network interruption or stopped process. Verify the resilience of the rollback runbook. Can you return to the initial state if a step fails? Simulate a failure midway through cutover and confirm that you can recover, for example by restoring the old server and cleaning up partial state.

• Rollback exercise: after switching the test environment to the 8.4 database, simulate rollback by reactivating the old 8.0 database. Determine how many transactions would be lost, specifically those written after cutover. Formally define the point of no return, such as “no rollback after N hours or after the maintenance window closes.”

• Detailed scheduling: record the measured duration of backup, migration, tests, and every other step, then compare the total with the planned maintenance window. Identify the longest stages and add contingency time. Create a precise schedule for shutdown, commands, validation, and recovery, with explicit stop and go criteria.

The objective is to rehearse under conditions as close as possible to production, using a timed and controlled process that eliminates unknowns. This dry run produces a refined and validated runbook with clear checkpoints and realistic durations.

11. Execute the Production Cutover with Explicit Stop Conditions

On cutover day, follow the runbook step by step and enforce the predefined stop conditions. Any blocking anomaly must trigger an abort or rollback. The critical phases are:

• Freeze writes: place the application in read-only mode or stop write traffic at the load balancer. The 8.0 server must receive no new data. Stop condition: if writes continue for more than X seconds, abort and verify write fencing.

• Final synchronization: on the 8.0 primary, run FLUSH TABLES WITH READ LOCK and record the binary log position or GTID. Confirm that every replica has applied the final logs, with Seconds_Behind_Master = 0. Stop condition: if a replica does not catch up within Y seconds, diagnose the issue or cancel the cutover.

• Switch connections: update the connection endpoint using a low-time-to-live DNS swap, virtual IP address (VIP), or cluster failover. Force reconnection by clearing pools and restarting application services or ProxySQL so that clients use the new 8.4 instance. Confirm that clients reconnect without error. Stop condition: if the DNS switch fails or new connections return errors, direct clients back to the old server.

• Smoke tests: immediately run a set of simple and business-critical queries against the new database. For example, execute representative end-to-end transactions, verify known totals, or run quality assurance (QA) test scripts. Stop condition: if a key query returns an error or inconsistent result, execute the rollback plan.

• Business validation: ask business teams or QA to confirm that the application works as expected through a rapid user acceptance test (UAT).

• Continuous monitoring: watch the MySQL error log for new critical errors and system metrics for abnormal latency or CPU spikes. Detect real-time regressions through dashboards and alerts.

The following is a sample control table used during cutover:

Designate a single person or committee, such as the senior DBA or lead SRE, with authority to trigger rollback. Maintain a complete log of actions and results. After a successful cutover, do not immediately release the old database. Keep it read-only throughout validation so that you can temporarily redirect traffic to it if a major problem appears.

12. Observe MySQL 8.4 and Preserve the Rollback Boundary

After cutover, actively monitor the new 8.4 server throughout the defined observation window. Continuously compare its metrics with the baseline from section 6:

• Performance and errors: monitor p95 and p99 latency and overall throughput. Investigate every material regression beyond the approved thresholds. Review the MySQL error log for new WARNING or ERROR entries. An unexpected input/output spike, increased deadlocks, or InnoDB errors may indicate an optimizer or configuration problem.

• Remaining replicas: if disaster-recovery or reporting replicas remain, monitor their lag. An unexpected GTID gap may indicate that the 8.4 instance is no longer sending logs, which would be abnormal.

• Client connections: confirm that no client still attempts to use the old server. Each connection failure may reveal an endpoint that was not updated. Remove every code path and configuration entry that points to the old host.

• 8.4 backups: run a new backup on the 8.4 server and test a sample restore. Confirm that backup scripts and schedulers complete without error on the new version.

Define a point of no return, for example, “rollback is not permitted more than 72 hours after the upgrade,” or “after the final day-120 review.” Beyond this deadline, diverging data will prevent the old service from restarting without loss. Document this deadline clearly and obtain stakeholder approval. Until the deadline is reached, keep the old 8.0 server on standby in read-only mode.

13. Handle Managed Services and Mixed-Version Estates

If you use cloud services or forks, account for the following differences:

• Amazon RDS/Aurora: AWS supports MySQL 8.4 LTS as a managed service and permits direct migration from 8.0 when the current version is 8.0.22 or later. AWS also recommends a Blue/Green deployment to minimize downtime. For example, on RDS 8.4, innodb_adaptive_hash_index is disabled by default, unlike 8.0. Ensure that your parameter groups and RDS options reflect the new 8.4 values.

• Azure Database for MySQL: Azure's version policy supports MySQL 8.4, with version 8.4.8 generally available. In June 2026, Azure Database Migration Service added support for migrations to MySQL 8.4. Verify server parameter versions and feature compatibility because Azure may enforce some settings.

• Google Cloud SQL: Cloud SQL for MySQL 8.4 enables caching_sha2_password by default while continuing to accept existing mysql_native_password accounts. However, new accounts can no longer be created with mysql_native_password. If you use BigQuery or specialized tools, follow Google's recommendations, including guidance intended to avoid breaking connections through its authentication tools.

• Other forks, including Percona and MariaDB: Percona Server generally follows Oracle MySQL 8.x, so the migration is similar; use the corresponding Percona documentation. MariaDB is not binary-compatible, so moving from MySQL to MariaDB requires a complete dump and reload.

• Mixed environments: if your estate combines MySQL 8.0 and 8.4, for example hosted clusters and on-premises systems, verify replication compatibility. Cross-major-version replication is not available, so plan to upgrade all nodes before making them communicate.

In summary, each cloud provider or distribution has its own support policy and upgrade options. Use provider-specific documentation to plan the upgrade through the AWS RDS console, Azure CLI, Google Cloud Console, or equivalent tools. Do not treat “LTS” as a synonym for a simple patch, because each environment introduces new behavior and controls.

14. Execute the 120-Day Migration Plan

Plan the project over approximately 120 days, in waves where necessary. The following is a sample schedule:

Assign an owner, such as the DBA, SRE, or application team, to each phase. At the end of every stage, obtain approval from the responsible party; for example, quality assurance signs off phase 3. Record success metrics, actual timings, and tolerances, and archive the documentation. These stages draw on advanced DBA skills, including architecture, SQL tuning, high availability, and security, as described in Refonte Learning's resources on DBA skills, salaries, and projects in 2026 and database administration jobs and certifications. Completion means an operational 8.4 service and a decommissioned 8.0 environment.

By following these 14 phases, including inventory, upgrade-path selection, testing, rehearsal, cutover, and validation, you create a safe and controlled migration. Remember: once new data is written to 8.4, a complete rollback is no longer guaranteed. Only the steps completed before final cutover are fully reversible.

Refonte Learning Database Administrator Program: to prepare for these technical challenges, Refonte Learning's part-time, three-month Database Administrator training program covers SQL architecture, performance, security, migration, and high availability in detail. It draws on more than 15 years of database administration experience. To develop your DBA skills and learn to manage critical migration projects like this one, explore the Database Administrator Program.