HelpWithWebGet Help Now

Move your website from Bluehost to SiteGround

If the site is WordPress, do not do this by hand. SiteGround's Migrator plugin installs on the Bluehost site, copies the content into an empty site at SiteGround, and leaves the original running throughout. It also rewrites internal links as it goes, which is the part people most often get wrong manually.

If the site is not WordPress — plain PHP, a static site, something bespoke — you are back to files and a database, and the second half of this page covers that.

Either way this is the safest task to do first. The Bluehost site keeps serving the public until you change DNS, so nothing here is visible to anyone but you.

Hands-on time
30–90 minutes with the Migrator
Start to finish
Same day
Difficulty
Easy
Steps
5

Downtime risk: None. The Migrator copies rather than moves, and the live site stays on Bluehost until DNS changes.

Can I do just this, and nothing else?

Yes — this works on its own

Yes, and this is the most common way people do it. You can have a working copy of the site on SiteGround and change nothing else — the domain stays at Bluehost, email keeps flowing, and visitors keep reaching the Bluehost copy until you decide otherwise.

What changes

  • A second, working copy of the site exists on SiteGround
  • You have a tested target to point at when you are ready

What stays exactly as it is

  • The domain stays registered at Bluehost and is billed by Bluehost
  • Nameservers and DNS records are untouched
  • Email continues to work exactly as before
  • Visitors still reach the Bluehost copy

Before doing website files & database on its own: Nothing. The Migrator needs the Bluehost site to be publicly reachable, which it already is.

Before you start

  • An active SiteGround plan with an empty site created for the domain
  • WordPress admin access on the Bluehost site, to install the Migrator plugin
  • For non-WordPress sites: Bluehost File Manager or FTP, and phpMyAdmin
  • The Bluehost site publicly reachable — the Migrator works by copying the live site

Step-by-step

Each step is labelled with which side you are working on, so you always know whether you should be signed in to Bluehost or SiteGround.

  1. 1At SiteGround

    Create the empty destination site at SiteGround

    The Migrator needs somewhere to put the copy. Create the site in SiteGround first, using the same domain name, even though the domain does not point there yet.

    • SiteGround Client Area → Websites → New Website
    • Choose the domain, and let SiteGround create an empty WordPress install
    • Note the temporary URL SiteGround gives you — you will test on it shortly
  2. 2At SiteGround

    Get the migration token from Site Tools

    The Migrator pairs the two ends with a token rather than asking for credentials, so you are never typing your SiteGround password into the old host.

    • Site Tools → WordPress → Migrator
    • Choose the domain and the path the site should be transferred into
    • Copy the token it generates
  3. 3At Bluehost

    Install the Migrator plugin on the Bluehost site

    This is the only change made to your live site, and it is additive — the plugin reads the site and sends a copy. Nothing on Bluehost is modified or removed.

    • On the Bluehost WordPress site: Plugins → Add New → search for SiteGround Migrator
    • Install and activate it, then paste the token
    • Start the transfer and leave the tab open while it runs
  4. 4Either side

    Or move it by hand, if the site is not WordPress

    For anything the Migrator does not cover, it is the familiar files-and-database routine. Zip on the server rather than dragging thousands of files over FTP.

    • Bluehost File Manager → open public_html → select all → Compress → Zip Archive
    • Turn on hidden files first, or .htaccess is left behind
    • Export the database from phpMyAdmin: select it → Export → Quick → SQL
    • Upload and extract into SiteGround's public_html, then create a database and user in Site Tools → Site → MySQL and import the SQL
    • Update the application's database credentials to the new names
  5. 5At SiteGround

    Test on the temporary URL before touching DNS

    The whole point of copying rather than moving is that you get to find the problems with no audience. Use it.

    • Load SiteGround's temporary URL, or add a hosts file entry so the real domain resolves to SiteGround for you only
    • Click through properly — forms, logins, checkout, an image deep in an old post
    • Check the PHP version matches what the site ran on at Bluehost, and change it later as a separate step
    hosts file entry (macOS/Linux: /etc/hosts)
    35.214.0.10  example.com www.example.com

What goes wrong

The failures that actually happen on this step, rather than a generic warning to be careful.

  • The Migrator will not handle every site

    Can cause downtime

    SiteGround documents three cases it does not cover: sites on WordPress.com, sites built locally on your own machine, and Multisite installations. If you are in one of those, the Migrator is not a fallback option — plan for a manual move or a plugin-based export from the start.

  • The Bluehost site must stay publicly reachable

    Can cause downtime

    The Migrator works by fetching your live site, so anything that blocks it blocks the migration — maintenance mode, an IP allowlist, a security plugin challenging non-browser requests, or a half-finished DNS change. Run the migration before you touch DNS, not during.

  • Email does not live in the files

    Can cause downtime

    Mailboxes hosted with your old provider are not in public_html and are not in the database. If you use host-provided email, that is a separate migration — download the mail over IMAP before you cancel, or the messages go with the account.

  • A copied site can drift from the original

    Can cause delays

    Because the Migrator copies rather than moves, both sites are live and editable during the changeover. Anything published on the Bluehost site after the copy exists only there, and is lost the moment DNS points at SiteGround. Stop publishing once you have migrated.

How to check it worked

Do not rely on the site looking fine in your own browser — it caches, and it will tell you what you want to hear.

  • The site loads on SiteGround's temporary URL, or on the real domain via a hosts file entry
  • Interior pages load, not just the homepage
  • Images in old posts render, confirming uploads came across in full
  • wp-admin logs in and the plugin list matches the Bluehost site
  • Internal links point at the right place — the Migrator rewrites these, so spot-check a few

If it goes wrong

Nothing is live yet, so rollback is simply: do not change DNS. The Bluehost site is untouched and still serving. Delete the SiteGround copy and run the Migrator again if it went badly.

Questions about this step

Does the Migrator cause downtime?

No. SiteGround is explicit that it copies your content into an empty site and does not affect the live one. The only downtime risk in this whole migration is the DNS cutover later, and even that is avoidable.

Does it move my email too?

No. The Migrator moves WordPress — themes, plugins, uploads and the database. Mailboxes are a separate system and do not travel with it.

What about my SSL certificate?

Certificates do not transfer. The new host issues its own once the domain resolves to its servers, which means there is a short period after cutover where HTTPS may warn. Provision the certificate as soon as DNS points there, and check the site still forces HTTPS afterwards.

Reference documentation

Provider interfaces change. When these steps and the official documentation disagree, the documentation wins.

Only if you are doing the full move

Stuck on this step?

Send me the domain and what you have tried. I do Bluehost to SiteGround moves regularly and can tell you what is actually blocking it.

← All Bluehost to SiteGround stepsMigration guide tool

CallTextMessage