Decide whether you want a reversible deactivation or permanent deletion of module data. Before either path, inventory connected billing and outstanding operations so you do not lose the information needed to reconcile customers' services.
IN THIS ARTICLE
01 Prepare for ordinary deactivation
- Back up the WHMCS database, module files and relevant configuration.
- Use Renewal studio and Renewal invoicing to return connected services to WHMCS billing after resolving their handoff requirements.
- Resolve open renewals, pending hosting jobs or requests, and notifications that are queued or held for review.
- Turn off the switches that permit new hosting, renewal, account-change or queue work as required by the dependency checks.
- Open WHMCS System Settings > Addon Modules and deactivate the addon with Delete all data on deactivate left unticked.
02 Read dependency messages
Ordinary deactivation checks outstanding dependencies and reports Deactivation is waiting on when work remains. Follow the named area and resolve the underlying record. Keep the module and hooks installed until the check succeeds.
A successful ordinary deactivation retains module records for audit and a controlled later reactivation. Verify that native WHMCS billing now owns the intended services and that an external payment subscription cannot create an unexpected duplicate charge.
03 Understand permanent deletion
Delete all data on deactivate is a destructive option. When selected, saved and followed by Deactivate, it deletes Hosting Suite tables, including settings, policies, renewals, trials, tasks and audit records, together with the module-owned email templates. It bypasses the ordinary dependency blockers.
Do not use this option merely to silence an unresolved dependency warning. Complete the operational handoff first and retain the records your business needs. WHMCS products, services, invoices and remote hosting accounts are not deleted by removing the suite's data, so removal is not a customer account termination procedure.
04 Remove files and verify
After the intended deactivation is complete, remove only the module's installed files and hooks identified by the release manifest. Check that no live product still depends on the supplied server module before removing it. Preserve unrelated addons, templates and hooks.
Verify client-area pages, checkout, the normal WHMCS cron and upcoming invoice generation. Review trial services and application plans that need a replacement management workflow.
Can you reinstall later?
Retained records support controlled reactivation. Permanently deleted records require a suitable backup to recover their history and configuration. Reinstalling files alone does not recreate the previous renewal audit trail or credit accounting.
05 Review application and external dependencies
Application products may depend on the suite's server module for future account lifecycle actions, even when existing websites continue to run on the hosting server. Decide how staff will create, suspend, unsuspend, change and terminate those services after removal, and test the replacement workflow before deleting its integration files.
Cloudflare zones and other external resources can remain active after module access is removed. Record their ownership and the credentials or provider accounts needed for future management without placing secrets in the uninstall notes. Check that customers have a supported route to their websites and billing. Removing a client-area management interface should not leave your team without a documented way to operate the underlying service.