Editing a package changes the template, not the accounts already created from it. That single fact causes most of the confusion in this area: you raise a package from 5GB to 10GB, tell your clients, and none of them get any more space.
This covers what editing and deleting actually do, how to push a change out to existing accounts, and the two ways a package change can break something quietly.
Editing a package
In WHM, open Packages then Edit a Package. Choose the package, change the fields, and save.
From that moment, every new account created from the package gets the new values. Every account that already exists keeps exactly what it had. Nothing about them changes, and WHM does not warn you about the gap.
That is reasonable behaviour: automatically changing live accounts because a template moved would be worse, but it means editing a package is only half a job whenever existing clients are meant to benefit.
Applying a change to existing accounts
There is no bulk button. For each account that should receive the new values, open Account Functions then Upgrade/Downgrade an Account and reapply the package.
Reapplying replaces every limit with the package's current values, which is what you want, and also means any individual adjustment made to that account with Modify is discarded. If you had given one client extra space as an exception, it disappears here, and they will notice before you do.
This is the strongest practical argument for keeping the number of packages small. Reapplying across three packages is tedious; across nine it is an afternoon you will not spend, which means the change never fully lands.
Watch downgrades in a package edit
Reducing a package's disk quota and then reapplying it puts every account using more than the new figure instantly over quota. Nothing is deleted, and nothing can be written either: email stops being delivered, uploads fail, database writes are refused.
Check current usage before reapplying a reduced package. List Accounts shows usage against quota for everything you host. Upgrading or downgrading client accounts goes over this in more detail, because the failure mode is identical.
Deleting a package
In WHM, Packages then Delete a Package. Choose it and confirm.
Accounts created from the package are not deleted and not changed. They keep the limits they had and simply stop being associated with a package. Functionally nothing breaks.
Two things can break, though, and both are quiet.
Billing integration. Billing software maps its products to WHM packages by name. Delete or rename a package and the mapping points at nothing. Provisioning then fails on the next order, and the failure surfaces as a paying client asking where their hosting is. Check your billing products before removing any package.
Your own ability to reason about accounts. Accounts belonging to no package are accounts you can no longer treat as a group. A handful is fine; a habit of deleting packages leaves you with an inventory of one-offs.
Renaming is deleting
WHM has no rename. Changing a package name means creating a new one and removing the old one, with all the mapping consequences above.
So pick names that will still make sense in a year, and make them describe resources rather than marketing. web-5gb-10db tells you what it is; gold requires you to remember. Marketing names belong on your price list, where changing them costs nothing.
A safer way to change what you sell
Rather than editing a package that live accounts depend on, create the new one alongside it.
Make web-plan-v2 with the new values. Point new sales at it. Move existing clients across individually as it suits them: at renewal, or when they ask for more space. Retire the old package once nothing uses it.
This costs a little clutter and removes the entire class of problem where a package edit affects people you did not intend. It also means a mistake in the new package affects nobody until you deliberately move someone onto it.
For sizing the new one against what you actually hold, creating hosting packages walks through the arithmetic.
Read what a package currently contains
Editing a package is safer with the current values written down, since the change is applied immediately and there is no undo.
cat /var/cpanel/packages/PACKAGENAME 2>/dev/null ls /var/cpanel/packages/ grep -c "PLAN=PACKAGENAME" /var/cpanel/users/* 2>/dev/null | grep -vc ':0'
The last command counts how many accounts use it, which is the number of customers affected by any change.
Copy the file before editing. Restoring a package definition from a copy takes seconds; reconstructing it from memory after a customer reports a problem takes considerably longer and is never quite right.
Check nobody is above the new limits
A reduction applied to a package is applied to every account on it, including the ones already using more than the new figure.
for u in $(grep -l "PLAN=PACKAGENAME" /var/cpanel/users/* 2>/dev/null | xargs -n1 basename); do printf '%-16s %s\n' "$u" "$(du -sh /home/$u 2>/dev/null | cut -f1)" done
Any account above the proposed limit lands over quota the moment the change is applied, which stops it writing, receiving mail and in some configurations serving pages.
Deal with those accounts before the edit rather than after. A customer whose site breaks because of a change to a package they did not know existed is a support conversation that starts badly.