HelpWithWebGet Help Now

Website files & database · Bluehost

Move your website to Bluehost

Moving the files is the only part of a hosting migration that touches the website itself. Everything else moves pointers.

Bluehost offers a paid Pro Migration, which is usually the right starting point. The part that matters is what it does not carry across, because those things fail silently.

Do it while the old host is still live. Nothing here is visible to the public until DNS changes, so a mistake at this stage costs time and nothing else.

Checked against Bluehost's documentation on August 9, 2026.

What is different about Bluehost

The process is standardised. These are the parts that are not — the things that are true of Bluehost and not of everyone else.

Decide which Bluehost product you are moving to first

Bluehost sells 3 distinct hosting products — Shared Hosting, Managed WordPress, VPS and Dedicated — and the differences between them are larger than the differences between providers. Shared Hosting gives you File Manager and FTP/SFTP with phpMyAdmin; Managed WordPress gives you SFTP and Limited file access with Restricted; VPS and Dedicated gives you SSH and SFTP and File Manager with phpMyAdmin. Following instructions written for the wrong one is the most common way a migration stalls halfway.

The Pro Migration is a paid add-on

Purchased as a service from the Bluehost portal. Typical duration: Varies.

What the migration deliberately excludes

Bluehost states that it does not carry across DNS records, email, the registrar transfer. Every one of those fails quietly — the site arrives looking perfect and simply stops doing something it used to do. Rebuilding them is your job, and it is the difference between a migration that looks finished and one that is.

Check compatibility first: Bluehost cannot run Long-running Node.js or Python services on standard shared plans

Bluehost executes PHP (multiple selectable versions), Static HTML, CSS and JavaScript, with MySQL / MariaDB for storage. It is built for wordpress, php applications, static sites. What it will not run: Long-running Node.js or Python services on standard shared plans. That is the question to settle before any of the mechanics below matter — no file manager rescues an application the platform cannot execute. Node and Python availability varies by plan — check yours before assuming

The control panel is cPanel

File access is via File Manager, FTP/SFTP, SSH on some plans, and databases through phpMyAdmin. The web root is public_html.

Bluehost at a glance

Languages / runtimes
PHP (multiple selectable versions), Static HTML, CSS and JavaScript
Databases
MySQL / MariaDB
Built for
WordPress, PHP applications, Static sites
Cannot run
Long-running Node.js or Python services on standard shared plans
Control panel
cpanel
File access
File Manager, FTP/SFTP, SSH on some plans
Database tool
phpMyAdmin
Web root
public_html
Assisted migration
Pro Migration (paid)
Typical duration
Varies
Not covered
DNS records, email, the registrar transfer

Bluehost hosting packages

Bluehost sells more than one kind of hosting, and they are not interchangeable. Pick the row that matches what you bought before following any steps.

Shared Hosting

shared

The standard entry product: your site shares a server with many others, administered through the Bluehost portal with cPanel behind it.

Best for
Small WordPress and PHP sites where cost matters more than isolation
File access
File Manager, FTP/SFTP
Database tool
phpMyAdmin
Languages
PHP (multiple selectable versions), Static HTML, CSS and JavaScript
Databases
MySQL / MariaDB
Cannot run
Long-running Node.js or Python processes
  • Shared CPU and memory, so a busy neighbour can affect you
  • No root access, so server-level software cannot be installed

Migrating into it: The easiest target to migrate into: File Manager plus phpMyAdmin means a straightforward archive-and-import.

Managed WordPress

managed wordpress

WordPress-specific hosting with updates and caching handled for you, administered through a WordPress-focused dashboard rather than a general control panel.

Best for
WordPress sites whose owners do not want to manage the platform
File access
SFTP, Limited file access
Database tool
Restricted
Languages
PHP (managed versions)
Databases
MySQL
Cannot run
Non-WordPress applications
  • Some plugins are disallowed where they conflict with platform caching
  • Less direct database and file access than shared hosting

Migrating into it: Expect fewer tools than the shared product. Plugin-based migration is usually smoother here than manual file and database work.

VPS and Dedicated

vps

Virtual or physical servers with root access and, on these plans, the option of private nameservers.

Best for
Sites that have outgrown shared resources, or need specific server software
File access
SSH, SFTP, File Manager
Database tool
phpMyAdmin
Languages
PHP, Node.js, Python, Anything you install
Databases
MySQL / MariaDB, Others you install
  • You are responsible for server maintenance and security

Migrating into it: The most flexible target, and the only Bluehost tier where private nameservers are available.

Step-by-step

  1. 1At your current provider

    Back up before anything else

    Take a copy of the files and the database and keep it off both hosts. This is not the migration copy — it is what you restore from when the migration copy turns out to be incomplete.

    • Files from your current host's file manager or over FTP
    • Database as a single SQL export
    • Store both somewhere that is neither the old host nor the new one
  2. 2At Bluehost

    Request the Pro Migration

    Purchased as a service from the Bluehost portal

    • Typical duration: Varies
    • Create a dedicated admin account for the migration rather than sharing your own, and remove it afterwards
  3. 3Either side

    Or move it by hand into public_html

    Compress on the server and move one archive. Dragging thousands of small files over FTP is where migrations stall.

    • Turn on hidden files before compressing, or .htaccess is left behind
    • Upload the archive into public_html and extract it there
    • If the archive contained the web root folder itself, move the contents up one level
    • SSH is available on some plans, which makes this considerably faster
  4. 4At Bluehost

    Create the database, then grant the user

    The database and its user are separate objects. A site that loads but reports a connection error is almost always a missing grant rather than a wrong password.

    • Use phpMyAdmin
    • Grant All Privileges on the new database
    • Panels usually prefix both names with your account name — use the full names
  5. 5At Bluehost

    Import the database and update the credentials

    Import into the empty database, then point the application at it. Check the table count against the source; a partial import reports nothing useful.

    wp-config.php
    define( 'DB_NAME', 'the new database name' );
    define( 'DB_USER', 'the new user' );
    define( 'DB_PASSWORD', 'the password you just set' );
    define( 'DB_HOST', 'localhost' );
  6. 6At Bluehost

    Rebuild what the migration left out

    The exclusions again, because this is the step people skip: DNS records, email, the registrar transfer. List them at the old host before you cancel, because afterwards the list is gone.

    • DNS records
    • Email
    • The registrar transfer
  7. 7At Bluehost

    Test before you touch DNS

    This is what separates a calm migration from a bad one. Load the new copy while the old host still serves the public.

    • Use the temporary URL Bluehost provides
    • Better: a hosts file entry so the real domain resolves here for you only, which catches redirect loops a temporary URL hides
    • Click through properly — forms, logins, checkout, an image deep in an old post
    • Match the PHP version to the old host first; upgrade later as a separate change
    hosts file entry (macOS/Linux: /etc/hosts)
    203.0.113.10  example.com www.example.com

Best practice

The habits that make this go smoothly, independent of which providers are involved.

  • Confirm Bluehost runs your application's language and database before anything else — PHP (multiple selectable versions), Static HTML, CSS and JavaScript with MySQL / MariaDB
  • Copy rather than move, and keep the old site running until the new one is verified
  • Test on a temporary URL or via a hosts file entry before changing any DNS
  • Compress on the server and transfer one archive, not thousands of files
  • Match the old PHP version first; treat upgrading as a separate change
  • Stop publishing on the old site once the copy is taken, or that content is lost at cutover
  • Keep the old host active for two weeks after cutover as your rollback
  • Rebuild everything the Pro Migration excludes, and check it off explicitly

What goes wrong

The failures that actually happen when Bluehost is the destination.

  • Bluehost cannot run everything

    Can cause downtime

    It does not support Long-running Node.js or Python services on standard shared plans. If your site depends on any of those, this is not a migration — it is a rebuild or a conversion, and finding that out after you have started is expensive. Confirm what your application actually needs before moving anything.

  • Hidden files are silently skipped

    Can cause downtime

    .htaccess and similar dotfiles do not appear in most file managers until you enable hidden files, and are not included in an archive built from a selection that never showed them. A WordPress site missing .htaccess loads the homepage and 404s everywhere else.

  • Large database imports fail quietly

    Can cause delays

    Above roughly 50 MB the import hits an upload or execution limit. Sometimes it errors, sometimes it stops partway and says nothing useful. Check the table count against the source rather than trusting the absence of an error.

  • Email does not live in the files

    Can cause downtime

    Mailboxes are not in the web root and not in the database. If your old host provided email, that is a separate migration — download it over IMAP before cancelling, or the messages go with the account.

Where are you coming from?

Most of this job depends on the destination. These are the bits that depend on where you are coming from.

Coming from cPanel hosting

A like-for-like move: File Manager, phpMyAdmin and the same public_html layout at both ends. Compress, download, upload, extract, import, update credentials.

Coming from managed WordPress

There is usually no cPanel and no phpMyAdmin to export from, so use a migration plugin that produces a portable archive, or lean on Bluehost's Pro Migration. Do it while the source is still publicly reachable — most tooling, including this one, works by fetching the live site.

Coming from a site builder

Wix, Squarespace and similar do not give you the files at all. There is nothing to migrate in the normal sense; the site has to be rebuilt or exported to static HTML, and content moved across separately.

Know exactly where you are moving from?

Common questions

What languages does Bluehost support?

PHP (multiple selectable versions), Static HTML, CSS and JavaScript, with MySQL / MariaDB. It is intended for wordpress, php applications, static sites. It cannot run Long-running Node.js or Python services on standard shared plans.

Does Bluehost migrate my site for me?

Yes — Pro Migration, as a paid service. Purchased as a service from the Bluehost portal. It covers files and databases but explicitly excludes DNS records, email, the registrar transfer.

Can I move without downtime?

Yes. Copy the site, test it on a temporary URL while the old host still serves the public, and change DNS only once it works. There is no window where nothing answers — the risk is cutting over to an untested copy, not the cutover itself.

What about my email?

It does not come with the files. Mailboxes are a separate system, and MX records are a separate job again. Plan both explicitly rather than assuming a hosting migration covers them.

What happens to my SSL certificate?

Certificates do not transfer. Bluehost issues its own once the domain resolves to it, which means a short period after cutover where HTTPS may warn. Provision it as soon as DNS points here, and check the site still forces HTTPS.

Reference documentation

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

The same job at other providers

Want this done for you?

I move sites onto Bluehost regularly — files, database, DNS and the registrar — with the old provider kept as a rollback until it has settled.

← All migration guides

CallTextMessage