SiteGround to InterServer: Self-Managed Website Transfer

To move a website from SiteGround Site Tools to InterServer, identify the application, export its files and databases, and prepare a compatible destination yourself or with your administrator. SiteGround’s current documentation uses Site Tools, so this is a self-managed transfer rather than a cPanel-to-cPanel migration.

Complimentary migration eligibility: InterServer provides migrations for web hosting plans only, limited to cPanel-to-cPanel and DirectAdmin-to-DirectAdmin. VPS and dedicated-server migrations are not offered. Cross-panel transfers and website-builder conversions are outside this service; the manual instructions below are for self-managed moves when the matching-panel web hosting requirements are not met.

Reviewed October 14, 2026. This replaces our 2017 cPanel walkthrough and screenshots. The steps below describe the documented Site Tools export options, not a migration we performed in a customer account. Download availability and transfer eligibility depend on the services you have.

1. Define what is moving

List the main site, subdomains, databases, mailboxes, scheduled tasks and any content stored outside the website directory. Decide whether email and DNS will move or remain with their current providers. A WordPress site export is not an export of the entire hosting relationship.

Confirm the destination hosting supports your application and required database/runtime versions. SiteGround Site Tools does not produce a universal cPanel or DirectAdmin account archive. Its cross-panel transfer is outside InterServer’s complimentary migration service.

The InterServer migration guide explains the standard same-panel workflow and limitations. This Site Tools move requires that compatibility discussion. Keep the source service active while it is being assessed.

2. Export through Site Tools

SiteGround documents two options in its website backup download guide:

• Premium Backup download: where enabled, open Site Tools > Security > Backups, select the relevant backup’s actions and request its download. Wait for preparation to finish.
• Manual export: download the website files through Site Tools > Site > File Manager, and export each required database through Site > MySQL > phpMyAdmin.

The files and database are separate components in a manual export. Identify the correct database from the application’s configuration and repeat for additional sites or databases. Check separate document roots for subdomains. Do not assume the main website directory contains them all.

Retain hidden files and any application dependencies outside the document root. If you create a temporary archive, keep it outside public website directories and retrieve it through authenticated access. Treat configuration files and database dumps as sensitive because they can contain credentials and personal data.

3. Arrange a private transfer and restore

Keep exported files and database dumps private. Transfer them through authenticated HTTPS, SFTP or another encrypted method supported by your destination. Do not publish a backup link or assume that ordinary FTP is encrypted.

A Site Tools backup is not automatically a compatible full-account restore for the destination panel. The work may instead involve placing the website files in the correct document root, importing the database, creating a database user and updating application configuration. Confirm who is responsible for those tasks and protect existing destination data first.

SiteGround’s manual transfer guide distinguishes transferring website data from moving other services. Its SiteGround Migrator workflow is for migration into SiteGround; do not assume it exports an account to InterServer.

4. Recreate what a website archive does not establish

• Email: agree how mailbox accounts, messages, aliases and filters will be preserved. If mail remains with SiteGround or a separate mail provider, preserve the required mail routing and confirm that cancelling another service will not remove it.
• Scheduled work: inventory cron jobs and background processes. Enable only the intended production copy after cutover, not both copies.
• HTTPS: arrange certificate issuance or an authorized certificate transfer for the destination. Do not share private keys through a public ticket or treat a certificate warning as a successful test.
• Application dependencies: check PHP/runtime versions, extensions, filesystem paths, caching configuration, external storage and outbound integrations. A provider-specific cache setting may need to change.

5. Test before changing DNS

Preview the new hosting with the actual domain name using a method agreed with support. A local hosts-file override can direct your own browser to the destination while public DNS remains unchanged, but you must still check HTTPS and the intended virtual host.

Test pages, login, media and database-dependent actions. Keep payment processing, outgoing mail and webhooks in sandbox or disabled on a test copy. For stores or other frequently updated sites, plan a write pause or final synchronization so orders and uploads created after the first export are not discarded.

Apply the DNS changes needed for this specific move. Review A and AAAA records for the website; review MX and email-authentication records only as required by the mail plan. If changing nameservers, reproduce the necessary zone records and coordinate DNSSEC rather than copying only the website address.

Keep the old service and private backup until the site owner has verified the application, email and new data after cutover. For a rollback, reconcile any writes accepted on the new host before pointing traffic back. See the migration backup checklist for a practical verification record.