Inventory domains, owners, database engines, PHP extensions, mail, scheduled work, DNS, certificates and external dependencies. Keep independent source backups and access. Prepare destination capacity and compatible supported software, and decide whether DNS and mail will move with the website.

1. Create a migration checklist and record current DNS records and TTLs. Arrange a maintenance window for final application writes if the data cannot be synchronized safely while active.
2. For a Virtualmin source, create complete domain archives and transfer them over a protected channel. Include global settings only when you intentionally plan to apply them to the new host.
3. Restore the domain through the supported workflow on the prepared destination, reviewing its new IP and feature settings. For another source, use an importer only when the source version and backup format are supported; otherwise separately transfer files, export/import databases and recreate scoped users.
4. Test using controlled hostname resolution so the real application hostname reaches the destination without a public DNS change. Keep production notifications and scheduled payments disabled on the test copy.
5. Compare database records, file counts and important application functions. Test mail separately and verify that external DNS records have been reproduced completely if delegation will change.
6. During final cutover, stop or control source writes, make a final consistent database transfer and copy changed files. Complete the mail synchronization plan, then update the intended public records.
7. Observe both machines during cached traffic overlap. Reconcile mail or writes that reach the former host and ensure only one active production scheduler processes business work.
8. Activate and verify destination backups before retiring the source. Retain agreed recovery data and document any intentional change in platform behaviour.

Not safely without review. Host-specific addresses, service paths and installed components can differ. Restore account data deliberately and compare global configuration before applying it.

No. DNS only changes where clients connect. The final database transfer and application write policy determine whether current content and business transactions arrive intact.

Test public HTTPS, login, uploads, database writes, mail delivery and scheduled tasks from outside the destination. Confirm that web-server rules and application secrets were transferred with correct permissions. A successful home page alone does not prove a complete migration.

If errors appear before cutover, keep traffic on the source while repairing the destination. If rollback is needed after the destination accepted writes, preserve and reconcile those writes before returning traffic. Avoid overwriting an active destination by repeatedly restoring an older archive.

• Installing Virtualmin on a supported clean server
• Restoring a single Virtualmin virtual server
• Making a Virtualmin BIND zone authoritative
• Selecting PHP versions and execution modes in Virtualmin

• Virtualmin: How To Migrate To A New Server
• Virtualmin: Migrate Domain
• Virtualmin: Transfer Domain