EnterraHost
To move a website between panels is mostly a question of carrying two things across, the files and the database, and then telling the application where its database now lives. The import tool does that from a backup file and goes further than the website itself.
This is not a WordPress feature. It works for WordPress, Joomla, or a plain HTML and PHP site with no database at all, and it reads the backup the same way regardless.
What the importer brings across
More than most people expect, and the list is the reason to use it rather than doing it by hand.
The primary website comes across, with sub, add-on and parked domains becoming mapped domains under a single website. So do all files, every database, and any installed application.
Then the parts people usually forget to migrate separately. An existing SSL certificate, cron jobs, FTP accounts, and the MX and TXT records your SPF setup depends on. A backup also contains the mail itself, and where that mail ends up is the subject of the next section rather than a detail of this one.
A Plesk import also carries the PHP version and the scheduled tasks.
What it cannot bring across
The most important thing to know before you start is about mail, and it is not a limitation of the importer. Web hosting here does not include mail. Mail is a separate service on its own infrastructure, which is why a mailbox never competes with a website for space and why it carries its own uptime commitment and filtering.
So whatever the importer says it can carry, the mailbox is not something this website plan can host. Anything mail-shaped on your old account, whether that is a mailbox, a catch-all address, an autoresponder or calendars and contacts, has to be set up as part of the mail service rather than alongside the website. A mailing list is worth calling out separately, because we do not run a list server at all. If you are leaving a host where a list server handled a list for you, that is a separate product to find rather than something this move can carry. Sort the mail out before you move DNS and no message bounces while the site makes its way across.
Beyond that, features that only exist on the panel you are leaving have nowhere to go. From cPanel that means wildcard subdomains, directory privacy, existing statistics and error pages.
PostgreSQL is a different case and worth separating. The importer does not carry a Postgres database across, but Postgres itself is supported here, so the answer is to move that database yourself rather than assume it has nowhere to live.
None of it stops a site working. It means a catch-all address has to be configured on the mail service if you still want one, and a mailing list stays where it is until you find a list host for it.
The conflict that blocks an import
If any domain in the backup already exists on this account, the import will not proceed. Delete the existing domain first.
This is the single most common reason an import fails, and the error is clear when it happens. A red panel lists anything that is blocking it, and the domain already existing is what appears.
Running it
Open the Website importer and choose New import.
Step one asks which panel you are leaving. Choose cPanel or Plesk. The two paths are the same after this point, which is why the next three steps look identical whichever you picked.
Step two asks for the import method. Upload website backup is the one to use.
Step three gives you the instructions for generating a compatible backup on the old host, and the upload field beside them. It has to be a full account backup, saved as a .tar.gz and under 10 GB.
Step four reviews it. Check for conflicts here, then choose Import now.
The Plesk importer is in beta. It is tested and it works, and unusual behaviour is worth reporting rather than working around.
How to move a website by hand instead
Four steps, and they apply whatever you are leaving.
Start by archiving the document root, or extracting it from a full backup you already have.
Then export the database. From phpMyAdmin on the old host, select the database and export as SQL. A plain HTML site has none, and the rest of this section does not apply to it.
Upload the archive to public_html and extract it through the Files tab, over FTP or over SSH. Create the database on the new account and import the SQL through phpMyAdmin.
The last step is the one people skip and then blame on the transfer. WordPress reads its credentials from wp-config.php in the site root. Joomla reads configuration.php. The old values still sit in that file until you change them, and the database host is almost always localhost on both hosts, so the name, user and password are what actually change.
That route works, and it is what you do when the backup is over the size limit or you would rather not move mail.
Testing before you move DNS
Load the site by whatever temporary address the panel gives you. If the pages render but the styling is missing, the application is still building URLs for the old domain, which is a setting rather than a missing file.
Load a page that reads from the database. A blank white page at this stage is far more often a wrong database password than a missing file.
Move DNS last. Old links, cached DNS records and an unfinished email migration are all reasons you might want the old host back for a week, and the article on restoring a backup covers what happens once it is gone.