Record the current WHMCS version, PHP version and extensions, database version, installation path, public URL, custom admin directory and cron command. List attachment and download locations, mail piping or importing, payment callbacks, registrar connections and server API allowlists. Include remote storage and any integration that depends on the old IP address.

Check the destination against the requirements for the exact WHMCS release being moved. Keep the application version unchanged during migration unless an upgrade is independently tested. Confirm how your licence can be reissued through WHMCS or the reseller that supplied it.

1. Choose a maintenance period and identify who can stop and restart automation. Inform staff when customer and billing changes must pause.
2. Disable the old scheduled cron and other background imports. Restrict new changes while taking the final database backup so that the destination does not begin with missing orders or payments.
3. Copy the complete application, custom modules and templates, private attachments and downloads, and a database backup. Preserve the original configuration.php and its encryption hash securely.
4. Create the destination database and an appropriately restricted database user. Restore the database and update the database connection values in the destination configuration.
5. Adjust absolute paths for private storage and moved cron directories. Apply ownership and permissions appropriate to the new PHP execution user.
6. Reissue the licence when required and arrange DNS and HTTPS for the intended public address. If the URL changes, update WHMCS System URL and the affected integrations.

Check administrator and client login, an existing service, a private attachment, a download and the order form. Confirm that the destination can contact its configured mail server, payment gateway, registrars and hosting servers without creating unnecessary test transactions. Update API allowlists only for the verified destination address.

Compare counts and recent timestamps for clients, services, invoices and transactions against the final source backup. An application that opens successfully can still contain an earlier database snapshot. Check that encrypted server and gateway credentials work, which also helps reveal a changed or missing encryption hash.

Review the proposed cron command on the new server and run only the appropriate scheduled process once the destination is authoritative. Confirm Automation Status and logs. Keep the old installation restricted with automation disabled so that two sites cannot invoice or provision simultaneously.

Reconcile gateway transactions and messages received during the maintenance period. Some providers retry callbacks, while others require an explicit resend or manual reconciliation. Do not replay a successful payment without checking its transaction ID against WHMCS.

Keep the migration backup and old environment available for the agreed recovery period. If rollback becomes necessary after new orders or payments reach the destination, reconcile those changes before restoring the old database. A simple DNS reversal does not merge the two histories.

• Back up and restore the WHMCS database and application files
• Schedule the WHMCS system cron and daily automation
• Change the domain or directory of your WHMCS installation
• Troubleshoot WHMCS payment callbacks and unpaid invoices

• WHMCS: move to a new server
• WHMCS: configuration.php
• WHMCS system cron
• WHMCS 9.0 system requirements