Inventory domains, website files, databases, PHP requirements, mailboxes, cron jobs, certificates, external integrations and DNS records. Confirm which source-panel importer your installed Webuzo version supports and what it excludes. Retain independent source backups and keep source access until verification and retention requirements are satisfied.

1. Prepare a supported Webuzo destination with sufficient disk, database and mail capacity. Install compatible supported runtimes and extensions. Create the required destination account identity according to the selected importer requirements.
2. Lower relevant DNS TTLs in advance when you control the authoritative zone. Record the existing records and choose an explicit rollback point. Avoid changing nameservers before copying all required records.
3. For an account-level cPanel import, open Server Utilities > Import From cPanel and choose either the supported remote connection or a trusted full backup already placed at the destination. Follow the importer requirement for matching account usernames.
4. For another source, use its documented importer if supported. If no importer covers the application, plan separate file transfer, database export/import, mailbox migration and account configuration. Do not assume a generic archive reproduces panel-specific permissions or services.
5. Run the initial import and read all task logs. Record skipped items and warnings. Test the destination using controlled hostname resolution so you can preserve the public hostname and HTTPS behaviour without moving live traffic yet.
6. Check login, uploads, application writes, scheduled commands, mail folders and outgoing mail. Prevent the test copy from sending duplicate customer notifications or processing scheduled payments.
7. Arrange a final write freeze or application-specific synchronization. Transfer changed files and database data consistently, complete the mail synchronization plan, then change the intended website and MX records.
8. Monitor both destinations during cached traffic overlap. Reconcile mail or writes received by the former host and confirm that only one production scheduler is active. Keep source backups and a time-limited recovery route until the migration is accepted.

Do not assume it. Downtime depends on application write handling, database consistency, transfer time, DNS caches and the source/destination feature differences. Test the migration and agree an appropriate maintenance window.

No. Payment callbacks, external DNS, SMTP providers, allowlists and third-party credentials require their own checks. Keep an inventory and explicitly test each integration after cutover.

Compare representative files, database records, mailbox folders and account settings. Test real public DNS and HTTPS from outside the server, then confirm backup coverage on the destination. Document any feature intentionally changed because the new platform implements it differently.

If the importer reports errors, preserve its log and determine whether the failure is authentication, capacity, archive compatibility or a specific object. Do not rerun with overwrite against an active destination without preserving new data. If you must return traffic to the source, first consider writes already accepted on the destination so DNS rollback does not silently lose them.

• Installing Webuzo on a supported clean server
• Creating and storing a Webuzo account backup
• Restoring a Webuzo account from a backup
• Using an external mail provider with a Webuzo domain

• Webuzo: Import From cPanel
• Webuzo: Import From Direct Admin
• Webuzo: Migration From Another Panel To Webuzo