1. Create and verify the target package or plan on every server that may host the affected services.
2. Confirm that the provisioning module supports package changes for the relevant account type. Check any restrictions on moving between reseller and shared-hosting products.
3. Open the source product's Upgrades tab in Products/Services. Select the products customers may move to and enable configurable-option changes only where the module supports their intended effect.
4. Review the target product's price, tax treatment, module, server group and package mapping. A different product group does not by itself migrate an account to another server.
5. Test the allowed path on an isolated service, including the resulting invoice, recurring amount and actual remote limits.

Before a manual change, inspect unpaid renewal or upgrade invoices and the service's current due date. WHMCS calculates upgrade charges using the remaining portion of the billing period. A delayed unpaid upgrade can be cancelled when the normal renewal invoice is generated, requiring a new upgrade order.

For downgrades, check current disk use, databases, mailboxes and other limits against the target plan. A panel may reject a smaller package or permit it while leaving the account above a quota. Resolve that situation with the customer before applying the change.

1. Open the client's profile, select Products/Services and open the specific hosting service.
2. Choose More > Upgrade/Downgrade. Select the approved target product and review the proposed charge and billing details before placing the upgrade order.
3. Check that the target is compatible with the service and has the customer's approval. Administrators can select products outside the upgrade paths offered to customers in the Client Area, so the available selection alone does not prove that the move is appropriate.
4. Review the generated upgrade invoice and its payment status. The upgrade workflow calculates the prorated difference and can apply the remote package change after payment through a supported provisioning module. Check its result using the verification steps below.

Use the upgrade workflow when the customer is buying a supported package change. Merely changing a product selection on a service record does not replace the upgrade order, prorated invoice and remote provisioning checks.

After the approved upgrade is paid and processed, compare the WHMCS product and recurring amount with the panel package and limits. Review any recurring promotion separately. Use the module error and queue entry to repair failed remote changes instead of collecting a second payment for the same upgrade.

If the request also changes servers or platforms, handle the data migration as a separate planned operation. Retain a record of the old package and agreed target so that a failed change can be assessed without guessing.

• Add and price WHMCS configurable options
• Change a WHMCS service due date without creating a billing gap
• Investigate a paid WHMCS order that did not create hosting
• Define acceptance checks for a completed website migration

• WHMCS: Upgrade or Downgrade a Service
• WHMCS upgrades and downgrades
• WHMCS Plesk module
• WHMCS DirectAdmin module
• WHMCS products