InterServer Website Migration: Eligibility, Backups and Support

For an eligible web hosting migration, start with a support ticket before changing DNS. Tell us which hosting account you are moving, which control panel it uses, and whether the move includes email. Confirm the matching-panel destination and restore method before creating or uploading a backup.

Reviewed October 14, 2026. This guide explains the migration workflow and existing service limitations. Support must confirm the scope for your particular source and destination; a hosting order alone does not confirm that every application, mailbox or control-panel setting can be transferred.

Check migration eligibility first

InterServer provides complimentary migrations for web hosting plans only. The source and destination must use matching supported panels: cPanel-to-cPanel or DirectAdmin-to-DirectAdmin. VPS and dedicated-server migrations are not offered.

Cross-panel transfers, migrations to Webuzo or Plesk, and proprietary website-builder conversions are outside this service. These are self-managed moves or work for your own administrator/developer; a single WordPress website does not create an exception to the matching-panel requirement.

A full-account restore is not a merge into an account that already contains unrelated websites. It creates an account or replaces its contents; the username may need to match the source backup. Confirm the source panel and the web hosting plan you ordered before requesting migration.

• Existing destination data: disclose it in the ticket. Do not upload a full-account restore over an account you need to keep. A separate account or reseller arrangement may be necessary.
• Software compatibility: identify PHP, MySQL/MariaDB, extensions and application versions. End-of-life software may not run on a supported destination stack. Encoded applications, including those requiring ionCube, can need a compatible loader or an update from their developer.
• Source limitations: disabled backups, insufficient disk space, resource limits or an unresponsive old server can prevent a normal export. Support needs to assess an alternative before promising completion.
• Compromised sites: cleanup is best effort, not a guarantee that a transferred backup is malware-free. Tell support about a known compromise before the move.
• Email: confirm mailbox and storage-format compatibility. A website export is not proof that mail, passwords, aliases and filters are included. Cross-panel email conversion is not guaranteed by the standard account-restore workflow.

What to include in your support ticket

Sign in to the InterServer customer portal and open a support ticket for the destination service. Include this information, but do not put passwords, private keys or public backup links in the initial message:

• The destination service or account and the old hosting provider.
• The source control panel, account username and domains or subdomains being moved.
• Whether this is a complete account, selected websites, a reseller account group, or a website-only move.
• Whether email is moving, where DNS is managed, and any third-party mail or CDN services that must stay in place.
• Any existing destination data, application requirements, backup restrictions and cancellation deadlines.
• Whether the site accepts orders, uploads, form submissions or other changes that need a final synchronization.

Ask support for the approved credential-sharing and private backup-transfer method. Use temporary, appropriately scoped access where possible, and revoke it after verification.

Allow time for preparation and verification

Migrations may take 24 hours to begin. The dedicated migration team does not operate around the clock, and rushed migrations are not available. Allow at least seven days of remaining source service when a migration begins, and extend that overlap if testing or troubleshooting needs longer. This is planning guidance, not a completion deadline.

Zero downtime is not guaranteed. Keeping the old host available and testing the destination reduces risk, but a write freeze, maintenance window or final database/mail synchronization may still be needed. Two reachable copies of a store can accept different orders; availability alone does not keep their data synchronized.

Create and transfer a private backup

For a confirmed cPanel-to-cPanel migration, use the account’s enabled backup interface to generate a full account archive, then wait for generation to finish. Account users can create this backup when their provider permits it; restoring the full account requires provider or authorized WHM access. See our cPanel backup and transfer guide for the distinction between full and partial backups.

Keep the archive outside every public website directory. Download it through the authenticated HTTPS control panel, or use the encrypted transfer method agreed with support. SFTP and SCP require the relevant access to be enabled. Ordinary FTP is not encrypted, and installing an FTP client does not change the protocol.

Never move a full backup into a web-accessible directory or relax its permissions to create a download link. Such archives can contain database contents, email and credentials. A random filename is not access control. Do not attach a large backup to a ticket unless support explicitly approves that transfer route.

If the source cannot generate a full backup, a file copy alone does not recreate databases, mailboxes, subdomains or other panel settings. Support may ask for separate database exports and an inventory of the remaining components. Use the pre-migration backup checklist to identify what is missing.

Reseller accounts need an account-by-account plan

For the standard reseller workflow, provide full backups for the individual accounts rather than assuming reseller access includes the source server’s root privileges. Agree the private delivery location and destination account mapping with support. Confirm capacity, package limits and username conflicts before restoring.

Afterward, compare the account list, domains, databases and mailboxes with the source inventory. Different storage totals can result from compression or server configuration, so matching disk usage alone is not a successful restore test.

Verify the restored service before changing DNS

1. Preview the intended destination. Use the agreed preview method or a local hosts-file override with the actual hostname. Test the correct HTTPS virtual host; an IP-only request can display a different site. Do not bypass certificate warnings to declare success.
2. Test application behavior. Check important pages, images, login, uploads, database-backed actions and error logs. Use sandbox transactions and prevent test copies from sending real emails, webhooks or payments.
3. Check mail separately. Verify accounts, aliases, folders, message samples, sending and receiving. If mail stays elsewhere, preserve its routing and authentication records.
4. Plan the final data copy. Agree how writes and scheduled jobs are paused or synchronized so recent orders, uploads and mail are not lost between the first backup and cutover.
5. Apply the agreed DNS changes. Record previous values. Review A/AAAA records, mail routing and any nameserver or DNSSEC changes as applicable; do not replace an entire zone without preserving required records.
6. Monitor before cancelling. Confirm that traffic and mail reach the intended service and that the owner accepts the migration. Keep a private, verified backup and retain the source account until the overlap and rollback plan are no longer needed.

Changing domain registration is separate from moving website files. You do not need to transfer a domain’s registration simply to point its DNS to new hosting.

Technical reference: cPanel’s backup documentation describes account backup creation and the full-restore permission boundary. This editorial review did not perform a customer migration or verify a particular account’s eligibility.