Planning a supported database-server upgrade from WHM

Confirm root-level responsibility, the exact current engine and version, application compatibility and sufficient maintenance time. Create verified database backups and a tested server recovery plan. Inventory custom configuration, authentication plugins, stored routines and external clients.

1. Check the supported upgrade paths for the installed cPanel version and operating system. Do not assume a MySQL-to-MariaDB move or the reverse is available between arbitrary versions.
2. Restore representative application databases into an isolated environment using the proposed engine version. Test reads, writes, schema migrations, scheduled tasks and backup/restore compatibility.
3. Open Database Services > Upgrade Database Version. Older WHM installations label this MySQL/MariaDB Upgrade. If MySQL Governor controls the engine, follow its supported process instead.
4. Run the available upgrade checker and resolve reported blockers. Review configuration validation and each warning before continuing.
5. Pause application writes according to the maintenance plan, preserve a final consistent backup and select the supported interactive or unattended workflow. Monitor the complete upgrade output.
6. After completion, inspect the engine logs and test every critical application and external client. Verify actual server version through a database query rather than relying on PHP client-library information.
7. Resume normal writes only after validation and monitor errors and performance. Retain the pre-upgrade recovery material for the agreed period.

Through an authorised SQL client connected to the database server being upgraded, run this read-only query before and after the maintenance:

SELECT VERSION() AS server_version;

Record the complete returned string together with the connection endpoint. The query asks the connected server for its version; information about a PHP database driver or a locally installed client is a different measurement.

The expected version confirms only one part of the result. Continue the application, authentication, schema, backup and recovery checks in the maintenance plan before reopening normal writes.

The engine should run the intended supported version with applications operating correctly and backup jobs still succeeding. Record the exact upgrade path and any configuration changes.

If the upgrade fails or an application is incompatible, use the documented recovery plan with qualified administrator assistance. Reinstalling an older database package over upgraded data is not a supported rollback. Database-format and engine changes may require restoring into a compatible separate environment.

No. The interface does not support engine downgrades, and some engine changes are one-way within WHM. Recovery must be planned before the change using tested backups and compatible infrastructure.

Avoid overlapping major maintenance operations. Complete and verify one controlled change at a time so failures have a clear cause and a usable recovery point.

• Configuring WHM backups and retention for the available storage
• Checking WHM service status before restarting anything
• Testing a cPanel backup before a major website change
• Using supported Apache include configuration in WHM

• cPanel: Upgrade Database Version

• MySQL: VERSION() returns the server version