Website migration: panels, backups and DNS

InterServer's policy limits complimentary migrations to web-hosting plans using cPanel-to-cPanel or DirectAdmin-to-DirectAdmin transfers. VPS and dedicated-server migrations are not offered within that service. Cross-panel moves, Webuzo or Plesk migrations and proprietary website-builder conversions are also outside scope. This matters when considering Standard with DirectAdmin for a site currently hosted in cPanel. A single WordPress installation does not create an exception. Ask support to confirm eligibility for the specific source and destination before committing to the route. View hosting offers.

• Name the source provider, control panel and account, including domains and subdomains.
• Identify the destination service and panel, and disclose any data already present there.
• List application, PHP and database versions, required extensions and known compatibility issues.
• Specify the websites, databases and mailboxes being moved, and services staying elsewhere.
• Identify who controls DNS, any CDN configuration, mail routing and scheduled jobs.
• Explain which orders, uploads, messages or other records will keep changing during the move.

General InterServer hosting support is available around the clock, but the dedicated migration team is not a 24/7 service. The guide says migrations may take 24 hours to begin and that rushed migrations are unavailable. Allow at least seven days of remaining source service when the migration starts, extending the overlap if testing needs longer. This is planning guidance, not a guaranteed completion time. Keep the old account available for comparison, final synchronisation and rollback. Cancelling it as soon as a destination account exists removes useful recovery options.

Inventory files, databases, mail and account settings, then confirm what the proposed backup actually includes. A full cPanel account archive is different from downloading a site's files; restoring the full account requires the appropriate provider or WHM permissions. If the old host disables backups or lacks free disk space, agree an alternative with support before proceeding. Never put an archive containing databases and mail under public_html to create a download link. A random filename is not access control. Use the approved protected transfer method, remembering that ordinary FTP does not encrypt the transfer.

A full-account restore is not a merge into an account containing unrelated sites. It can replace contents or create an account, and its username may need to match the source. Tell support about existing destination websites, mail and databases before delivering the archive. A separate account or a different account mapping may be necessary. Do not judge success solely by matching storage totals: compression and server configuration can change the size, while important settings may be stored elsewhere. Verify the inventory and the application behaviour instead.

• Preview the destination using the real hostname and correct HTTPS virtual host through an agreed method.
• Check important pages, images, authentication, uploads and database-backed functions.
• Use sandbox transactions and prevent test copies from sending real emails, webhooks or payments.
• Check mailboxes, folders, message samples, sending and receiving separately.
• Confirm required extensions, scheduled jobs, queues and application versions.
• Record errors, resolve them and agree acceptance before the final cutover.

An initial copy becomes outdated while a shop continues accepting orders or users keep uploading files. Agree a write freeze, maintenance window or final database, file and mail synchronisation. Two reachable copies can accept different orders; availability alone does not keep data consistent. Record the old DNS values and change only what is needed. Review A and AAAA records, mail routing and any DNSSEC requirements when nameservers change. Moving domain registration is not required merely to point a domain at new hosting. Monitor traffic, mail and errors after cutover while retaining the source for rollback.

Siteman began using InterServer in the early 2000s at its Moscow office. A second office opened in Baku in 2007 and later became the main and only office. That background helps frame migration questions, but does not remove the need to check today's software and eligibility rules. Cross-panel conversions, application changes and testing outside the complimentary service need their own scope and responsibility. For a wider preparation checklist, see Web hosting options and Siteman's experience and the platform budget guide at Hosting prices in USD and AZN.

The service conditions were checked on 3 November 2026: the official plan documentation and the official help center. The detailed guide is marked reviewed 14 October 2026. This article explains preparation and eligibility; it does not confirm acceptance of a particular account for migration or replace a support ticket agreeing the actual scope.