Identify all consumers of the user, including staging sites and cron jobs. Keep current database and configuration backups. A dedicated replacement user can allow a controlled transition when the application and service permit it.

1. Open Manage My Databases and confirm the current user’s database assignments and privileges.
2. For a staged rotation, create a new dedicated user with the same required database scope and a strong unique password. For an in-place reset, prepare every configuration update first, then use Change Password for the intended user under Current Users. Enter and save the new password, then immediately complete the prepared configuration updates.
3. Update the application’s protected database configuration and any relevant scheduled-job environment. A staged replacement changes the username and password; an in-place reset changes the password for the existing user. Do not expose the new password in a public diagnostic file.
4. Test live application reads and writes, then check background jobs and connection pools that may retain old credentials until restarted through the supported process.
5. For a staged replacement, revoke the old user’s access after every required consumer has moved, and delete the retired user when it is no longer needed. Do not delete the active user after an in-place password reset. Record the rotation without storing the secret in ordinary notes.

The application should connect consistently after a fresh process or request. After an in-place reset, confirm the old password is rejected. After a staged replacement, confirm the retired user can no longer access the migrated database. Removing a user’s database privileges and deleting the user are different actions.

If the site loses connectivity, check whether the database password and application settings now match. In a staged rotation, a still-valid previous user may provide a temporary recovery route while you investigate. After an in-place reset, restoring an old configuration alone will not fix its now-outdated password. Complete the coordinated update instead of creating untracked users.

Do not assume it does. Application database users are separate identities with their own passwords and grants. Review and rotate the actual credential stored in the application configuration.

• Assigning a database user only the privileges an application needs
• Diagnosing database access denied after a hosting migration
• Exporting a recoverable database backup in phpMyAdmin
• Renaming a cPanel database without losing the application connection

• cPanel: Manage My Databases