Moving WordPress means moving files and a database, then fixing URLs after HTTPS exists on the new host. It is not “upload the theme folder and hope.” On WPHost you install and configure yourself: no Softaculous one-click, no automatic plugin updates, and deploy history that restores files — not a substitute for a MySQL dump.

This numbered move targets a bakery one-pager with opening hours. Sister articles: where to host a small WordPress site, how to transfer WordPress to a new host, how to migrate WordPress website hosting.

1. Freeze scope and take a real backup on the old host

Before touching DNS:

  • Put the site in a short maintenance window if you can.
  • Export a full backup: files and database (UpdraftPlus, or zip + mysqldump).
  • Note PHP version, active plugins, and whether WooCommerce is involved.
  • Record current home and siteurl.

If you only copy wp-content, you will rebuild an empty shell. Deploy history on the destination will not invent missing posts.

2. Create the destination PHP site and MySQL

On WPHost, create a PHP 8.4 site. Create MySQL. Save credentials. Keep the preview HTTPS URL handy — that is where you validate the move before public DNS.

Plans: $9 / $30 / $65 / $130 depending on how many sites you need. There is no forever-free move target. Email stays at your mail provider; do not assume mailboxes migrate with web files. No built-in CDN to “flip” either.

3. Deploy files without nesting junk

Upload a zip of the WordPress tree so the document root contains wp-config.php, wp-content, and friends. Do not zip a parent folder that nests everything one level deeper.

If you use a build step for a theme asset pipeline, upload what WordPress needs to run — not developer debris. (See the failure section on node_modules.)

4. Import the database and point wp-config at it

Import the dump into the new MySQL. Update DB_NAME, DB_USER, DB_PASSWORD, DB_HOST in wp-config.php. Keep salts unless you have a reason to rotate (rotation logs everyone out).

Open the preview URL. If you still see the old domain in redirects, do not panic-edit Settings yet — wait until you understand URL replacement. For a first smoke test, you may temporarily set home/siteurl to the preview HTTPS URL via the database so wp-admin loads.

5. Search-replace URLs carefully

Serialized PHP data in WordPress breaks if you naive-replace strings with different lengths. Prefer a serialization-aware tool (WP-CLI search-replace, Better Search Replace carefully, or your backup plugin’s restore helpers).

Replace the old public URL with the preview URL for testing, then with the final HTTPS domain after the custom cert exists. Mixed http:// leftovers cause padlock warnings.

6. Worked example: bakery one-pager with opening hours

Content that must survive the move:

  • Home page with today’s hours block (often a reusable block or a small plugin).
  • Menu PDF in the Media Library.
  • Contact form notifications to the shop email (SMTP credentials may need re-entry).
  • Google Maps embed or static map image.
  • Local Business schema if you had it.

After import on preview: confirm hours render, PDF downloads, form sends, images are HTTPS. Install/verify UpdraftPlus and take a fresh full backup on the new host. Remember WPHost does not auto-update plugins — check for updates yourself after the move.

On Pro+, use staging for theme tweaks after cutover; copy the DB so staging hours match production.

7. DNS cutover last

When preview is correct: attach the custom domain, wait for the certificate, set WordPress Address and Site Address to https://bakery-domain, purge any leftover caches, keep MX untouched. Lower TTL a day ahead if your DNS host allows it.

WooCommerce note: if the bakery sells online, the shop can run; WPHost offers no PCI product and no checkout SLA. Re-test payments in a low-risk window.

What to skip during a move

Skip Softaculous “restore” myths on a host that has no one-click installer. Skip pointing DNS before preview works. Skip trusting file deploy history as the only backup. Skip migrating unused plugins “for later.” Skip changing mail DNS while you only meant to move the website.

What “done” looks like

Done means: public HTTPS on the brand domain, hours and PDF correct, forms delivering, wp-admin login works, full backup exists on the new side, and old host is retained briefly as a rollback until you are confident.

Failure: uploading node_modules instead of dist/

Developers sometimes zip the theme repo including node_modules, source SCSS, and test fixtures, then wonder why deploys are huge and slow — or why production references /dist/app.css that was never built. WordPress needs the runtime assets the theme actually enqueues, not the entire Node toolchain.

Before zipping for a move: run the production build, confirm dist/ (or the theme’s equivalent) exists, exclude node_modules and .git from the archive, and spot-check that CSS/JS URLs resolve on preview. Uploading node_modules wastes storage (Starter is only 2 GB) and still leaves the site broken if the built files are missing. Build locally or in CI; deploy artifacts WordPress can serve.

FAQ

Can WPHost import my old host’s cPanel backup with one click?

No. There is no one-click installer/migrator. Upload files, import MySQL, fix config and URLs.

Will deploy history restore my posts if the import fails?

No. Deploy history is file releases. Restore posts from your database dump or UpdraftPlus package.

Do plugins keep updating themselves after I move?

No. You update in wp-admin. Schedule that after cutover.

Is email included when I move hosting?

No. Keep MX at your mail provider. Moving web DNS should not hijack mail.