The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →You can move a WordPress site from Bluehost without deleting the live site: copy the complete WordPress files, export and import the matching MySQL database, update wp-config.php with the destination database details, test the copy, refresh permalinks, and only then change DNS. Website files and the database are the core migration; existing email is a separate asset that normally requires its own mailbox or message migration.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What a Bluehost-to-another-host migration actually moves
A WordPress installation has two essential payloads. The first is the file tree: WordPress core files, the wp-content directory, themes, plugins, uploaded media, and configuration files. The second is the MySQL database, which stores posts, pages, settings, users, comments, menus, widget data, and much of the information created by plugins.
As an Amazon Associate I earn from qualifying purchases.
Copying only the files produces an incomplete site. Importing only the database leaves the destination without themes, plugins, uploads, and other required files. A reliable move transfers both, then connects them with the destination host’s database credentials.
Email is not contained in the WordPress files and database. Mailboxes, messages, forwarding rules, and mail-routing records therefore need a separate continuity plan. Keep Bluehost active until the website and any required mail service work from the new environment.
Prepare the move before touching the live site
Start with an inventory. Record the information below in a private, recoverable document so you can compare the old and new environments and restore settings if needed.
- The domain name and whether the site uses
httporhttps. - WordPress administrator access.
- Bluehost control-panel access, including FTP or File Manager and phpMyAdmin access.
- The database name listed as
DB_NAMEin the currentwp-config.php. - The active theme, plugins, custom code, and any licenses or API keys those components require.
- The PHP and other runtime requirements your current WordPress version, theme, and plugins need.
- Cron jobs, scheduled tasks, external webhooks, analytics settings, cache settings, and security rules that live outside the WordPress dashboard.
- Every mailbox, alias, forwarder, autoresponder, and other email function using the domain.
Choose a low-traffic maintenance window if you expect people to publish during the copy. You can keep the Bluehost site live while preparing the destination, but a site that changes continuously can have new posts, orders, comments, or uploads after the database export. Plan a final synchronization or a brief content freeze for those cases.
Choose a migration method
There are two practical paths. The manual route gives you direct control over every file, database import, URL change, and test. A guided route reduces the amount of command-line or database work but depends on the destination and the migration service supporting your particular site.
| Decision point | Manual migration | Guided migration |
|---|---|---|
| Technical skill | Requires FTP or File Manager, phpMyAdmin, database setup, configuration editing, and troubleshooting. | Uses a guided interface and is intended to reduce hands-on database and file operations. |
| Control | Full control over the files, SQL export, database credentials, URL replacement, and recovery choices. | Less direct control over how the service copies data and handles edge cases. |
| URL and serialized data | You can choose a migration-safe search-and-replace process and inspect the results. | Handling depends on the tool’s supported workflow and limits. |
| Testing and downtime | You decide how to use a preview URL, staging copy, hosts-file override, or temporary content freeze. | The tool may provide a guided destination preview, but the available options vary. |
| Support | You troubleshoot the source and destination or use support supplied by the new host. | The destination host or migration service may provide assistance; confirm the scope before starting. |
Manual migration
Use the manual method when you need maximum control, have unusual plugins or a large customized installation, or want a complete local backup that is independent of a migration service. Bluehost’s documented manual procedure uses a file copy, a phpMyAdmin SQL export and import, new database credentials, a wp-config.php update, and a permalink refresh.
Guided migration
Bluehost documents a self-service migration tool powered by InstaWP. It is designed to transfer files, the database, and content through a guided interface. Availability, supported source and destination hosts, site-size limits, and any exclusions can change, so inspect the options in your account and read the tool’s confirmation screens before relying on it for a production move. Even with a guided transfer, make your own backup and perform the same front-end, dashboard, email, and DNS checks described below.
Make a complete Bluehost backup
Do not cancel Bluehost or delete the old site before the destination has passed testing. Create a fresh backup immediately before the move and download it somewhere you control.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteBack up the files
- Open Bluehost’s FTP access or File Manager.
- Identify the site’s document root. This is the directory containing
wp-admin,wp-includes,wp-content, and the root WordPress files. - Download the entire installation, not just
wp-content. Include the activewp-config.php, rewrite configuration such as.htaccesswhen present, plugins, themes, uploads, and any custom files used by the site. - Keep the downloaded copy unchanged. If you create a compressed archive, also retain a way to inspect or extract it before the migration.
Back up the database
- Open the current
wp-config.phpand note the value ofDB_NAME. Export that database, not a similarly named database belonging to another installation. - Open phpMyAdmin in Bluehost and select the database identified by
DB_NAME. - Use the export function to create a complete SQL file and download it. Keep the file with the file backup and record the export time.
A complete backup gives you a rollback option if the import fails, a plugin behaves differently, or a late change is missing from the destination.
Manual migration: move the files and database
1. Prepare the destination account
Create the destination hosting account, attach the domain or a temporary preview address, and confirm the PHP/runtime requirements for your WordPress version, theme, and plugins. Create a new MySQL database and a database user at the destination. Record the exact database name, username, password, and database host supplied by the new host. The database host is not always the same value used on Bluehost.
2. Upload the WordPress files
Use the destination host’s FTP, SFTP, or File Manager to upload the complete document-root copy. Preserve the WordPress directory structure. In particular, verify that wp-content/uploads, the active theme, all required plugins, and root files such as index.php and wp-config.php are present. A transfer that omits uploads can make the site appear functional while images and downloadable files return errors.
3. Import the SQL database
Open the destination host’s database tool, select the newly created database, and import the SQL file exported from Bluehost. Wait for the import to finish and check for an explicit success message. If the tool reports a size or timeout limit, use the destination host’s documented alternative import process rather than repeatedly submitting a partial file.
4. Update wp-config.php
Edit the destination copy of wp-config.php so its database constants match the new database. Replace the old values with the exact values supplied by the destination host:
define('DB_NAME', 'new_database_name');
define('DB_USER', 'new_database_user');
define('DB_PASSWORD', 'new_database_password');
define('DB_HOST', 'new_database_host');Keep the rest of the configuration intact unless the destination host specifically requires a change. A wrong database name, user, password, or host commonly produces a database connection error even when the SQL import itself succeeded. Protect the file because it contains credentials.
Rank #3
5. Confirm the site’s stored URLs
If the domain and protocol are unchanged, the imported database can usually continue using the same site and home URLs. If the domain changes, or if the site moves between http and https, update the stored URLs with a migration-safe search-and-replace method that understands serialized data. A plain text replacement can corrupt serialized options and widget or plugin settings because those values include length information.
After the replacement, inspect the front end, dashboard, media library, internal links, redirects, canonical tags, XML sitemap, forms, and plugin settings for the old hostname. Search for both the old domain and the old protocol when both changed.
6. Refresh WordPress rewrite rules
Log in to the copied WordPress dashboard and open Settings → Permalinks. Click Save Changes without changing the selected structure. This rebuilds WordPress rewrite rules and resolves many post, page, category, and custom-post-type 404 errors after a move.
Test the copied site before DNS changes
Do not point the public domain to the new host until you can test the copy independently. Use one of the destination host’s preview or staging options, a temporary URL, or a hosts-file override that sends your computer to the new IP while other visitors still reach Bluehost. A preview method must let you test both the front end and the administrator area.
Front-end and content checks
- Open the home page, representative posts, pages, category archives, author pages, search results, and any custom post types.
- Open several old and recent media files, image galleries, downloads, and embedded content.
- Follow internal links and confirm that redirects, canonical URLs, and the XML sitemap use the intended hostname and protocol.
- Submit every important form, including contact, newsletter, account, checkout, and membership forms, and verify delivery or transaction results.
- Check robots.txt, analytics, caching, security, cookie, and consent settings.
Dashboard and operational checks
- Sign in and confirm that users, roles, posts, pages, comments, menus, widgets, plugin settings, and theme customizations are present.
- Check scheduled publishing, backups, cleanup jobs, cron tasks, webhooks, and integrations that depend on server paths or credentials.
- Verify SSL on the destination and test both the preferred URL and any expected HTTP-to-HTTPS redirect.
- Review error logs and browser developer-console errors while loading key pages.
- Test the site’s real business flow, such as a purchase, membership login, file delivery, or appointment request, in the safest available way.
Compare the destination with the live Bluehost site while the old copy remains available. If a check fails, fix the destination and repeat the test; do not use DNS as a debugging tool.
Plan the domain and DNS cutover
When the copied site passes testing, change the domain’s A record or nameservers to the destination host, following the destination provider’s exact values. Bluehost explains DNS this way: “DNS, short for Domain Name System, translates domain names to IP addresses, allowing browsers to load your website.” The change tells visitors which server should answer for the domain.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
DNS caches do not update everywhere at once. Bluehost’s current migration guidance says propagation can take up to 48 hours. Treat that as a possible window, not a guarantee or a promise that every resolver will switch at the same time. Keep the Bluehost hosting active throughout propagation, and avoid making content changes on only one copy after the cutover begins.
During the window, verify the site from more than one network or DNS resolver. Some visitors may still reach Bluehost while others reach the destination. If both copies accept comments, orders, registrations, or uploads, those actions can diverge; a planned content freeze or final synchronization prevents that split.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Move email separately
Changing web hosting does not normally copy mailboxes or historical messages. Before changing DNS, list every mailbox, alias, forwarder, autoresponder, and application that sends mail from the domain.
If email stays with the existing provider
Confirm which mail-routing records and service settings must remain unchanged while the website’s A record or nameservers move. Test sending and receiving from each important address and check that website forms still deliver mail.
Free tools Windows power users keep installed
One-click scans. No signup required.
If email moves to a new provider
- Create the destination mailboxes, aliases, and forwarding rules before cutover.
- Preserve existing messages by exporting or synchronizing each mailbox using the providers’ supported process.
- Record the destination provider’s required mail-routing and authentication records.
- Test login, inbound mail, outbound mail, aliases, forwarding, and any application credentials.
- Only then change the relevant DNS records, and keep the old service available until messages are arriving reliably.
Do not assume that a successful WordPress migration proves email is safe. Website content and mailbox data are separate systems.
Common failure modes and fixes
| Symptom | Likely cause | What to check or fix |
|---|---|---|
| Database connection error | A database constant is wrong or the destination user lacks access. | Compare DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST with the destination host’s values, then confirm the user is assigned to the database. |
| Pages or posts return 404 while the home page works | Rewrite rules were not rebuilt. | Open Settings → Permalinks and click Save Changes; then retest representative URLs. |
| Images are missing or return 404 | The upload tree was not copied or URLs still point to the old host. | Compare wp-content/uploads with the backup and inspect stored media URLs and protocol. |
| Styles or scripts load from Bluehost | Old absolute URLs remain in theme, plugin, or database settings. | Use a serialized-data-aware replacement process and inspect page source and plugin settings for the old hostname. |
| Forms submit but messages do not arrive | Mail routing, sender authentication, or a plugin setting changed. | Test the destination form, review its configured sender and recipient, and verify the domain’s email service separately. |
| Some visitors see the old site | DNS caches are still resolving the Bluehost address. | Keep both environments available during propagation, which may take up to 48 hours, and test from another network before declaring the cutover complete. |
| Scheduled actions stopped | Cron jobs, server tasks, paths, or permissions were not recreated. | Compare the inventory made before migration with the destination’s scheduled-task configuration and plugin status. |
After the cutover
Continue checking logs, forms, analytics, search visibility, scheduled jobs, and mail delivery for several days. Confirm that the canonical URL, sitemap, robots.txt, SSL certificate, cache, and redirects remain correct when accessed through the public domain rather than the preview address.
Keep the Bluehost files, database export, and hosting account until you have verified the destination and no longer need a rollback. When you are certain the site and email services are stable, remove the old environment deliberately and retain the backup according to your normal retention policy. Canceling the old account first removes your easiest recovery path.
Quick Recap
A concise migration checklist
- Inventory domains, access, runtime requirements, plugins, theme, cron jobs, and mailboxes.
- Download the complete Bluehost file tree and export the database named in
DB_NAME. - Create the destination database and user, then record its exact credentials and host.
- Upload every WordPress file and import the SQL database.
- Update the destination
wp-config.php. - Handle domain or protocol changes with serialized-data-safe URL replacement.
- Save Settings → Permalinks.
- Test the copied site through a preview, staging URL, or hosts-file override.
- Prepare or separately migrate mailboxes and messages.
- Change the DNS A record or nameservers only after testing, and keep Bluehost active during propagation.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →
