Free migration or do it yourself?

In most cases, let us do it. Hostworld publishes free website migration on every plan, our in-house team moves website files, email and databases from any provider at no cost, and most migrations are finished within hours. Doing it yourself is genuinely faster in one narrow case: a small site with no email at the old host, which you could rebuild from scratch in an afternoon anyway.

This guide picks up from the point where you have chosen a Hostworld hosting plan, or are about to. If you have landed here from a search and have not ordered yet, that is fine. Nothing below requires you to have paid first, and the decision you are making changes what you order.

Before you start

Three things need to be true before either route works, and the second one catches people out most often.

• You can log in to your current hosting control panel. If you have lost that login, recover it with your current provider first. Neither we nor you can copy an account nobody can reach.
• You can log in to your domain registrar. The migration itself does not need this, but the final cutover does. You change the nameservers, not us. If your domain was registered by a web designer who has since vanished, sort that out now rather than on cutover day.
• You know whether your email lives at the old host. Mailboxes are where migrations go wrong. If you collect mail at the same place your site is hosted, that mail has to move too, and the order of operations matters. If your mail is on Microsoft 365 or Google Workspace, this gets considerably simpler.

Two things that can go wrong before anything has moved. First, a full cPanel account transfer depends on the losing host having backup generation enabled. Some providers disable it, and if yours has, the route changes to a slower file-by-file copy. Second, the source and destination need to be broadly compatible: OS family, cPanel version channel, EasyApache profile, PHP version and the PHP extensions your site actually uses. A source server on a much older cPanel release than the destination can complicate a transfer. Our team checks this. If you are doing it yourself, you check it.

What a free migration actually covers

Hostworld's published position is that the migration team will move your website, emails and databases from any provider at no cost, with most migrations completed within hours. Our plans also include free SSL and daily backups, and there is a 30-day money-back guarantee, so if the migrated site is not what you wanted, you are not trapped.

What we do not publish is a line-by-line scope: how many sites are included, whether there is a time window from signup, and how unusual setups are handled. Rather than guess, ask. When you open a support ticket, describe what you have and the team will confirm what is covered before any work starts.

Mechanically, a cPanel-to-cPanel move uses WHM's Transfer Tool. This is worth understanding because it explains why you cannot do it yourself on shared hosting. The Transfer Tool is a WHM feature, and WHM is the server-wide panel, not the per-site panel you get as a shared hosting customer. It automates moving accounts between cPanel servers: files, home directories, databases and database users, mailboxes and a long list of account settings. It encrypts data between the two servers automatically. A shared hosting customer has no WHM, so this route is only available through us.

Where root access to the old server is not available, which is most shared hosting, the standard route is a full cPanel account backup taken at the old host and restored here at server level. Same result, one more step.

Step 1: Write down what is actually on the site

Ten minutes here saves a week of "where did that go". List the domains and subdomains, every mailbox and roughly how large each one is, every database, any cron jobs, any scheduled scripts, the PHP version the site currently runs on, and whether you have any custom SSL certificate rather than a free one. Take screenshots of anything in the old panel you cannot export.

Mailboxes matter most. A copied site with missing mail is a much worse Monday morning than a copied site with a broken contact form.

Step 2: Lower your DNS TTL before anything moves

TTL is how long other people's DNS resolvers cache your records. It controls how long the internet keeps sending visitors to your old server after you have switched. Lowering it during the cutover is too late, because the old, long value is already cached everywhere.

Do this a few hours before the move, at minimum. If your current TTL is 3600 seconds, drop it to somewhere between 300 and 600. You change this wherever your DNS is currently hosted, which is usually the old host or the registrar. Put it back up to a normal value a few days after the move.

To undo it: the TTL change is harmless and reversible at any time, and it has no effect on the running site other than slightly more DNS traffic.

Step 3: Gather the details the migration team needs

The ticket goes faster if the first message contains everything. For a cPanel source, we need the old host's cPanel username and password, and the control panel URL or the server hostname. For a server-level transfer we need the source server's IP address, the SSH port it listens on, and root credentials. Do not assume the SSH port is 22. Plenty of hosts move it, and a wrong port number is a wasted round trip.

Also include the domain names to be moved, whether mail is hosted at the old provider, and any deadline you are working to, for example a shop you cannot have offline on a Friday. Good ticket practice is the same here as anywhere: be specific, name the systems involved, and paste any error messages in full rather than describing them.

On credentials in tickets: change the old host's password to something temporary before you send it, and change it again afterwards. That is the undo step and it costs you two minutes.

Step 4: Open the ticket in your Hostworld account

The client area at portal.hostworld.uk is WHMCS, so the flow is the standard one. Go to open a support ticket and expect these screens in this order:

1. Choose a department. This is the first step, before the form itself. If you are logged out you may see fewer departments than a customer does, because departments can be set to clients only and are hidden from visitors by default. Log in first.
2. Select the related service. Attach the ticket to the Hostworld hosting service you want the site migrated into. This removes a round trip where we ask which account you mean.
3. Type your message. As you type, WHMCS may suggest knowledgebase articles matching your keywords. That screen surprises people who expected the form to submit. Read them if they help, then carry on past them and submit.
4. Watch for the Open status. Every ticket starts as Open, which means you have not had a reply yet. The status changing is how you know we have picked it up.

Step 5: Check the copy before you touch DNS

The copy itself is quick. The processing afterwards is the wait, and its length depends on the size of the account. A transfer that appears to sit at the same percentage for a while is normal behaviour, not a stall.

Ask in the ticket how to view the migrated site before it is live, then check the things that break quietly: contact forms, checkout, login, image paths, anything that talks to a database. Do not judge success from your own browser alone once DNS has changed, because different resolvers update at different times and yours is not representative.

Step 6: Point the domain at Hostworld

When you are happy with the copy, change the nameservers at your registrar to:

• ns1.serverworld.uk
• ns2.serverworld.uk
• ns3.serverworld.uk
• ns4.serverworld.uk

Yes, the domain is serverworld.uk and not hostworld.uk. That is correct. Enter all four. A typo in a nameserver takes your site and your email offline at the same time, so read them back before saving.

To undo: your old nameservers are whatever the registrar showed before you changed them. Copy them into a text file first. If something is badly wrong after cutover, putting the old values back sends traffic to the old server again, subject to the TTL you set in step 2.

Step 7: Do not cancel the old hosting yet

Keep the old account for at least a week or two after the move. This is the single most useful precaution in the whole process. It costs one more month of hosting and it is your rollback.

There is also a real data gap to close. Between the moment the copy is taken and the moment DNS has fully switched, new mail and new orders can still land on the old server. Depending on how the transfer is run, traffic and mail are either redirected to the new server as it goes, which loses nothing but exposes visitors to any problem, or they are not redirected, which gives time to test but means new messages and database changes stay behind. Ask the team which applies to your move and whether a top-up sync is needed afterwards. For a shop, ask before the cutover, not after.

When doing it yourself is genuinely faster

Three honest cases. A brochure site of a few pages with no mailboxes and no database changes. A staging or development site nobody depends on. A site you were going to rebuild anyway, where migrating the old one is wasted effort.

For a small WordPress site, a plugin-based export and import is fast: a blog under 500 MB typically takes five to ten minutes end to end. A multi-gigabyte WooCommerce site is more like thirty to sixty minutes, assuming nothing fails.

Two warnings on the plugin route. Free import limits are widely misreported, with published figures ranging from 50 MB to 512 MB, and the plugin's own vendor says the real ceiling comes from your server's PHP upload_max_filesize and post_max_size. Do not plan around a specific number. More seriously, a large wp-content/uploads folder can trigger a prompt to buy a paid extension partway through an import, which leaves you with a half-migrated site. If the export file is anything other than small, a ticket is quicker than finding out.

The cPanel backup dead end

This is the mistake that costs people an evening. You can generate a Full Backup in cPanel, and you cannot restore it from cPanel. The full backup exists to move an account to another server or to keep a local copy, and restoring it is a server administrator job done through WHM. What you can restore yourself, through cPanel's Backup or Backup Wizard screens, is the partial set: home directory, MySQL databases, and email forwarders and filters. Note what is absent from that list. Mailbox contents are not a partial restore item.

Self-service backup and restore also degrades as sites grow. Large backups fail to generate, and large restores fail partway. If your account is more than a couple of gigabytes, treat DIY as the slower option.

What next

If you are handing this to us, go and open a support ticket with the details from step 3 attached to the right service. If you are doing it yourself, the click-by-click for taking and restoring backups in cPanel lives in our how-to articles, which cover one route each and assume you are already logged in and mid-task.

The next step in this sequence is checking the move properly: mail flow, SSL and DNS from more than one resolver. Missing mail, a certificate that did not reissue, and answers that vary by resolver are the three things that surface a day later rather than an hour later. Our migration guides cover that verification pass, along with registrar-specific nameserver instructions if yours is not obvious.