Applies to: Web Hosting (cPanel)

Web Hosting (cPanel) Help

Preparing a backup for migration to Web Hosting (cPanel)

You need to package your website files and databases correctly before uploading them for migration to Web Hosting (cPanel). Here are the things you should keep in mind while preparing your backup:

File format and size limits

You can upload a single backup file containing your website files and a database dump for each database.

  • Accepted formats: .ZIP, .TAR, .TAR.GZ (.tgz), .TAR.BZ2, .TAR.XZ, .TAR.ZST and .7Z.
  • Unacceptable formats: RAR archives, password-protected archives and archives split into several volumes (such as .z01 or .part1) can't be processed.

Formats are identified by what's inside the file rather than by its extension. If your backup is in an unsupported format, repackage the content as a .ZIP or .TAR.GZ before uploading it.

Keep these limits in mind:

  • Up to 100 GB of content, counting your site files and databases together. They share the same disk space as your hosting account.
  • Up to about 249,000 files, depending on your hosting plan. Logs and caches are removed first and don't count toward this limit.
  • Compressed database dumps are unpacked during the check, so a dump of roughly 500 MB or more, when unpacked, works best when supplied as a plain .sql file.

Back to top

Organize your backup files

If your current hosting uses cPanel, Plesk, DirectAdmin, Hestia, VestaCP, CloudPanel or Virtualmin, download its full backup and upload it as is. You don't need to unpack or rearrange anything.

Otherwise, put 2 folders at the top level of your archive: one for your site files and one for your database dumps. For example:

backup.tar.gz
├── public_html/          (site files, including wp-config.php and .htaccess)
│   ├── site1/            (with several sites, one subfolder each)
│   └── site2/
└── databases/
    ├── site1.sql         (one file per database)
    └── site2.sql

Use one of these folder names so we can find your content:

  • Site files: public_html, www, htdocs, httpdocs, web or html
  • Databases: databases, db, dumps or sql

Name each database dump after the database your site's configuration expects. The dump's file name becomes the database name (for example, shop.sql creates a database named shop).

If you have several domains, keep all sites under a single site files folder rather than creating a separate folder for each domain at the top level. A folder-per-domain layout is only recognized inside a control panel backup.

Back to top

Make sure everything you need is included

Your archive should include your site as it runs today, including files that don't appear in a normal folder listing. Check for these in particular:

  • Configuration files: wp-config.php, configuration.php, settings.php, .env and app/etc/env.php. These tell us which database belongs to which site.
  • Hidden files: .htaccess and .env. Many backup tools skip these by default, so it's worth checking that yours didn't.

Export each database as a single MySQL or MariaDB .sql file, using a tool such as mysqldump or phpMyAdmin. Split dumps and folder-per-table exports aren't supported.

Back to top

What applications are recognized?

WordPress, Joomla, Drupal, TYPO3, Magento, PrestaShop, Shopware, OpenCart, phpBB, MediaWiki, Moodle, Nextcloud, Laravel, Symfony and around 50 other common PHP applications are detected automatically along with their version. Anything else is recognized as a plain PHP or static HTML site.

Back to top

What won't be migrated?

Log files, statistics, caches (such as node_modules, vendor or cache folders), version control folders (such as .git), panel mail and stats folders, and links pointing outside the backup won't be migrated. Email mailboxes and FTP accounts aren't part of this migration either.

Back to top

What happens after you upload your backup?

  1. We check it to ensure it can be migrated.
  2. You need to review the websites we found. You'll get an editable list where you can correct the domain, folder, PHP version and database for each site, remove sites you don't want or add ones we missed. The detected application and version are shown for informational purposes; you only need to change them if they don't match your backup.
  3. The migration runs. This can take minutes to a few hours, depending on the size of your websites and databases.
  4. You review the results and accept or reject them.
Warning: You have 3 days to complete the review in step 2 and 3 days to complete the review in step 4. If we don't hear back within that time, the attempt will close, and your account will reset, so you can start again when you're ready.

Back to top

Verify the results

For each website, you'll get:

  • A screenshot taken after migration
  • The HTTP status code
  • A status of working, needs attention or broken
  • A summary
  • Any browser errors found
  • Guidance on what to do about the domain (for example, update Domain Name System (DNS), transfer it or register it)

If you accept the results, your account is finalized and becomes your live hosting account. If you'd rather not keep the result, reject it to reset the account and upload a corrected backup.

Your site doesn't automatically go live on your domain. Depending on where your domain is managed, you may still need to update DNS. The results page tells you what to do.

Back to top

What if your backup can't be used?

The usual reasons are:

  • A password-protected or incomplete archive
  • An unsupported format
  • More than 100 GB of content
  • Too many files for your plan
  • A large compressed database dump
  • A missing configuration file
  • Folders named differently than listed above

Each attempt works with a fresh upload. Once you've fixed the cause, upload the corrected backup to start a new check.

Back to top

More info