Moving a client between plans is one screen in WHM and takes a few seconds. The care is in what happens around it: an upgrade is harmless, a downgrade can put an account instantly over quota, and both silently discard any individual adjustments you made to that account previously.
This covers the mechanics, the check that prevents the downgrade problem, and the difference between this screen and the one that adjusts a single account.
Which screen you want
Upgrade/Downgrade an Account applies a different package wholesale. Every limit on the account is replaced with that package's values.
Modify an Account changes individual fields and leaves the package alone.
The consequence people run into: if you previously used Modify to give a client an extra 2GB, and you later use Upgrade/Downgrade to move them to a bigger plan, that 2GB adjustment is gone. Every field now comes from the new package, including the ones you had tuned for a reason. Editing cPanel account resources explains the other direction.
Doing it
Open Account Functions then Upgrade/Downgrade an Account. Choose the account, choose the new package, and confirm.
The change is immediate. There is no restart, no propagation delay, and the client does not need to do anything. Their cPanel shows the new limits on the next page load.
Before a downgrade, check current usage
This is the only step in this article that prevents real damage.
Look at what the account is actually using before reducing its quota. If a client is using 8GB and you move them to a 5GB package, they are immediately over quota. Nothing is deleted, but the account cannot write anything from that moment. Email stops being delivered, uploads fail, database writes are refused.
The client experiences this as the site breaking for no reason, and it happens the instant you click confirm rather than at some later point where you might connect the two events.
List Accounts shows current usage against quota for everything you host. Check there first. If the usage exceeds the new package, either get the account under the limit before downgrading, usually by clearing old backups, which is where the space nearly always is, or do not downgrade yet.
Upgrades
Upgrades are safe. Limits go up, nothing is over quota, and the client gains capacity immediately.
Two things are worth doing afterwards. Check that any individual adjustments you had made are still what you want, because they have been replaced by the new package's values. And update your billing so the client is charged for the plan they now have, WHM and billing do not talk to each other unless you connected them, and an upgraded account still being billed at the old rate is a mistake that runs for months before anyone notices.
Downgrades
Beyond the disk check, the other limits matter less than people expect. Reducing the allowed number of databases, email accounts or subdomains below what already exists does not delete anything. The client simply cannot create more. That is a mild inconvenience in place of a failure, and it is worth mentioning to them rather than letting them discover it.
Bandwidth is the exception to watch mid-month. If a client has already used more transfer than the new package allows, the account can be suspended for exceeding bandwidth. Downgrading at the start of a billing month avoids this entirely.
When neither package fits
If a client needs slightly more than one package and much less than the next, the temptation is to use Modify and create a one-off arrangement. That is fine once. It becomes a problem when you have done it eleven times and no account matches any package.
When the third client wants the same in-between arrangement, create a package for it instead. A package is a thing you can reason about and reapply; three modified accounts are three things you have to remember. Creating hosting packages deals with adding one, and there is no cost to having a package that only three accounts use.
Telling the client
WHM does not notify anyone. If a client asked for more space, tell them it is done: otherwise they sit watching an old figure in a tab they have not reloaded and conclude nothing happened.
For a downgrade, tell them before rather than after, and say what it means in practice: how much space they will have and what happens if they exceed it. A downgrade a client understood in advance is routine. The same downgrade discovered when their email stops is a complaint.
Before selling a larger plan it is worth confirming the plan is actually the constraint. How to Handle a Client Who Outgrows Shared Hosting deals with the check and the conversation.
Check what the change actually costs the customer
Moving an account between packages applies new limits at once, and one direction is materially riskier than the other.
du -sh /home/username 2>/dev/null find /home/username -xdev 2>/dev/null | wc -l mysql -e "SELECT COUNT(*) FROM information_schema.SCHEMATA WHERE schema_name LIKE 'username\_%'"
Read the current disk, file count and database count against the target package before applying it. An account above the new limit lands over quota immediately, and an over quota account cannot write, receive mail, or in many cases serve pages that need to write.
Where the account is above the limit, resolve that first. Applying the change and dealing with the consequences afterwards means the customer experiences an outage caused by their own upgrade request.
Confirm the change took and the billing matches
The package change is one operation. Several things around it are separate and frequently forgotten.
grep -E 'PLAN|MAXPOP|MAXSQL|BWLIMIT' /var/cpanel/users/username quota -s -u username
Confirm the stored plan name changed and the limits match the package definition. A mismatch means the account carries custom limits that override the package, which is fine when deliberate and confusing when not.
Then check the billing side separately, since the two systems do not always update together. An account upgraded technically and still billed at the old rate is a discrepancy that surfaces at renewal, by which point it has to be explained rather than corrected.