Moving HostBill requires its database, application files, private storage and configuration to arrive together. It also requires a controlled switch of automation and provider communications. Prepare a migration record before making the final copy so neither server can independently process the same billing work.
IN THIS ARTICLE
01 Plan the destination and handover
Confirm the destination meets the requirements of the installed HostBill build and its modules. Keeping the application version unchanged during the move makes faults easier to isolate. Inventory the current billing address, custom administrator directory, private paths, cron commands, mail routing, provider allowlists and payment callbacks.
Decide when orders and administrative changes will pause, how customer payments will be reconciled, and when the old installation will stop serving requests. If the address changes, list every integration that stores an absolute URL. A DNS change alone does not update a gateway's saved callback endpoint.
02 Copy and configure HostBill
- Prepare HTTPS, database access and the correct PHP runtime on the destination. Restrict the new installation so it cannot yet send customer messages or provision services.
- Make an initial copy of application files and the private attachments, downloads and compiled-template locations. Preserve the original configuration and encryption hash. Do not replace them with values generated by a new installation.
- At the agreed cutover, stop the old cron and queue jobs and prevent further writes through the old application. Export the final database and copy any files changed since the initial transfer.
- Import the database into the destination. Update
includes/config.phpfor the new database connection and actual private-directory paths. Apply ownership and permissions suitable for the destination's web and cron accounts. - Update the licence location in the HostBill customer portal when the domain, IP or installation location changes. Check application addresses and any integration-specific URLs or source-IP restrictions.
- Test the new installation privately before directing customers to it. Check staff and client access, representative historical invoices, private attachments and module connectivity.
03 Complete the cutover
Switch the public address or routing according to your plan. Configure and start both cron jobs on the destination only after confirming the old jobs are stopped. Update email piping or import connections and verify a real test message reaches the intended ticket department.
Review gateway records against HostBill for the cutover interval. A payment can succeed externally while its callback reaches an old or temporarily unavailable address. Reconcile each uncertain transaction before manually adding payment or retrying provisioning.
Keep an encrypted recovery copy of the old system while restricting its public and scheduled activity. Record the acceptance checks and the point after which restoring the old database would require reconciling new transactions. Remove obsolete credentials and infrastructure according to your approved retention plan.
Common questions
Can both servers run cron while DNS propagates?
No. Two independent schedulers can generate conflicting invoices, messages or remote actions. Choose one active system and explicitly disable the other.
Why are saved provider passwords unreadable after migration?
Confirm that the restored configuration contains the original encryption hash and belongs with the imported database. A newly generated configuration is not a substitute for the original encrypted-data context.