Migrating Your Hosting from Another Provider

Moving hosting sounds risky and mostly is not, provided you do things in the right order. The order is the whole trick: copy everything first, test it on the new server, and change DNS last. Done that way your existing site keeps serving visitors until the moment the new one is proven, and there is no window where neither works.

The slow, nervous version of this is doing it backwards — pointing the domain at an empty server and then racing to fill it.

If you would rather not do any of this yourself, we migrate sites for customers and for most sites there is no charge. Skip to the end.

Step 1: Take stock of what you actually have

Before touching anything, write down what is currently running. Sites acquire pieces over the years and the forgotten one is what breaks.

• The website files and which application they are — WordPress, a site builder’s export, or plain HTML.
• Databases, if the site has any. WordPress has one.
• Email: are the mailboxes on the hosting account, or with a separate provider? This changes the plan significantly.
• Anything scheduled — cron jobs, backup tasks, a nightly export.
• Where DNS is managed today, which is not always the same company as the hosting.
• Your current SSL certificate and whether it was free or paid.

Step 2: Take a backup you keep yourself

Download a full backup from your current provider — files, databases, and mailboxes — and keep it somewhere that is not either host.

You will probably never open it. It costs you twenty minutes and it is the difference between a bad afternoon and a lost website, because the one thing you cannot undo is cancelling the old account before you find something was missing.

Step 3: Set up hosting with us

Choose a plan on the web hosting page and complete the order. Your control panel login arrives by email and is also in your client area.

Add the domain to the new account without changing its DNS yet. The hosting is now ready and waiting; nothing about your live site has changed.

Step 4: Copy everything across

Upload the files, import the databases, and recreate the mailboxes on the new server.

Two details save most of the pain here:

• Match the paths. If the site lived in the web root before, put it in the web root now. Applications store internal paths, and a moved directory quietly breaks images and links.
• Recreate the database user with the same name and password where the application’s config file expects them. It is far quicker than editing config to match a new one.

For WordPress specifically, a migration plugin will do the whole copy in one operation and is worth using rather than moving the pieces by hand. Our WordPress guide covers the install if you would rather start clean and import content.

Step 5: Test on the new server before anyone else sees it

This is the step that makes the migration safe, and it is the one most often skipped.

You can preview the site on our server while the domain still points at your old host, by telling your own computer only to resolve the domain to the new server. That is what the hosts file on your machine does. Ask us and we will send you the exact line to add for your account — it is specific to your server, and a stale value copied from an article is worse than none.

With that in place, browse your own site as it will exist after the switch:

1. The home page loads and looks right.
2. Inner pages load — not just the front page, which can be cached.
3. Images appear, rather than showing as broken.
4. Forms submit, and the submission arrives.
5. The admin area or CMS login works.
6. Anything with a database behind it returns real data.

Fix what is broken now, while the live site is still happily served by the old host. Remove the hosts entry when you are done.

Step 6: Lower your DNS TTL

A day before you plan to switch, lower the TTL on your DNS records — 300 seconds is a good value.

TTL is how long other servers may cache the old answer. Lowering it in advance means that when you do switch, the world picks up the change in minutes instead of hours. Lowering it at the moment of the switch is too late, because the old, long TTL has already been handed out. See DNS records explained.

Step 7: Note your MX records, then switch DNS

Now point the domain at us — either by changing its nameservers to ours, or by updating the A record if you are keeping DNS where it is.

Before you do: write down your current MX records. Changing nameservers replaces your entire DNS zone, and MX records are what route your email. If your mail is with Microsoft 365, Google Workspace, or anyone other than your old host, those records must be recreated on the new nameservers or mail stops arriving — and it stops quietly, which is worse.

If you are unsure, send us the domain and we will migrate the zone with the mail records intact.

Step 8: Watch for a day, then cancel

Traffic moves across gradually as caches expire — usually within an hour, occasionally up to 48. During that window some visitors see the old server and some the new, which is normal and harmless because both are working.

Once it has settled:

1. Confirm the site loads with a padlock. Your free SSL certificate is issued automatically once the domain resolves to us, usually within the hour.
2. Send and receive a test email from an outside address.
3. Check the forms again from a normal browser.
4. Re-enable any scheduled tasks from step 1.
5. Put the TTL back up to something ordinary, like 3600.

Only then cancel your old hosting, and give it a week rather than a day. The old account is your fallback for as long as it exists, and it is worth more than the fortnight of overlap costs.

Need help?

We do this regularly and we are happy to do it for you — for most sites at no charge. Open a ticket from your client area or send us a message with your domain and your current provider, and we will handle the copy and the testing and tell you when it is safe to switch.