Migrating WordPress is not “move the domain and hope.” It is three synchronized pieces: files (wp-content and the rest of core), a MySQL dump, and a URL search-replace that respects PHP serialized strings. Do those on a preview host first. Change DNS last.

WPHost does not offer a proprietary one-click migrator that pretends the database is optional. You upload a zip (or deploy files), import SQL, fix configuration, test on the preview HTTPS URL, then point the domain. Plugins such as All-in-One WP Migration or Duplicator can package the work — they still move a database; they do not erase that fact.

This article is the technical migration. If your focus is keeping the registrar, MX, and public hostname stable while the origin changes, read transferring WordPress to a new host afterward — same physics, different emphasis.

Inventory before you touch DNS

On the old host, collect:

  • A full file copy: WordPress root including wp-content/uploads.
  • A MySQL dump (mysqldump, phpMyAdmin export, or your backup plugin’s database download).
  • The current DB_* values and $table_prefix from wp-config.php.
  • The live site URL exactly as WordPress knows it (https://www.example.com versus bare apex matters).
  • A list of must-work plugins (especially membership, WooCommerce, multilingual).

Lower TTL on the domain a day ahead if you can. That makes the cutover propagate faster when you are ready — it is not the migration itself.

Confirm your WPHost plan has disk for wp-content (Starter 2 GB, Pro 10 GB, Scale 30 GB, Business 100 GB) and a free site slot. Image-heavy libraries blow past 2 GB quietly; see image-heavy sites.

Step 1: Create the new PHP origin

Create a PHP site on WPHost (PHP 8.4). Provision a fresh MySQL database. Save the new credentials. Keep the old site online. Migration is a copy, not a cut-over until you say so.

Upload your WordPress files as a zip deploy. Prefer a clean tree: wp-config.php, wp-admin, wp-includes, wp-content, index.php at the docroot. If the archive wraps an extra folder, fix it before you chase 404s.

Step 2: Point wp-config at the new database

Edit wp-config.php for the new DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. Keep $table_prefix identical to the dump. Keep salts as they were unless you intentionally want to invalidate sessions after cutover.

Redeploy if you patched the file outside the platform. Opening the preview URL before importing SQL will look broken; that is expected.

Step 3: Import the database

Import the dump into the new MySQL instance with the tool you trust (CLI client, GUI, or a migration plugin’s restore into empty tables). Watch for:

  • Partial imports that time out on huge wp_postmeta tables — split or raise limits as your tooling allows.
  • Wrong prefix — tables named wp_ while config says xyz_.
  • Old host SQL modes or DEFINER clauses that some dumps carry; strip if the import errors on privileges you do not have.

At this moment the database still contains the old site URL in wp_options (siteurl, home) and scattered across post content, widgets, and theme mods.

Step 4: Serialized-safe search-replace

Naïve find-and-replace in a text editor breaks PHP serialized data: string lengths embedded in s:12:"https://..." stop matching after you shorten or lengthen URLs. WordPress then drops options or corrupts widgets.

Use a tool that understands serialization:

  • WP-CLI search-replace (if you run it in an environment that has it),
  • interconnect/it Better Search Replace style plugins on a temporary install,
  • or migration plugins that rewrite URLs during import.

Replace the old scheme+host with the preview HTTPS URL first, not the final domain, if you are testing on preview. Example intent: https://old.example.com → https://preview-host-name. Include or exclude www deliberately; do both variants if the old site mixed them.

Also consider replacing bare http:// old URLs if the site never fully moved to HTTPS historically.

Step 5: Test on preview HTTPS before DNS

On the preview URL, verify:

  • Front page and a deep permalink.
  • wp-admin login.
  • A media attachment from wp-content/uploads.
  • Forms that must not email yet (or point SMTP at a test inbox).
  • WooCommerce or membership flows on staging data if those plugins matter — carts and logged-in pages are where cache plugins lie to you later.

Fix theme path issues and missing PHP extensions now. WPHost is PHP 8.4; ancient plugins that only run on PHP 7.4 will fail here — better on preview than on launch day.

Deploy history can roll back a bad file upload. It will not rewound a botched SQL import. Keep the dump file.

Step 6: DNS cutover and final URL pass

When preview matches production expectations:

  1. Attach the custom domain in WPHost; create the DNS records shown.
  2. Wait for the custom-domain certificate after DNS verifies. Preview cert was never a substitute for the real name.
  3. Run search-replace again: preview URL → https://your-final-domain (or set siteurl/home carefully if you skipped preview URLs and went straight to final — still test).
  4. In Settings → General, confirm WordPress Address and Site Address are both https://… with no trailing inconsistency.
  5. Permalinks → Save once.
  6. Flush any cache plugin; purge CDN if you added one yourself (WPHost has no built-in CDN).

Leave MX records alone unless you intend to move mail. Web A/CNAME changes should not kidnap email.

Backup honesty after migration

You now have files on a new origin and a database that holds your content. Configure an independent backup plugin immediately. WPHost deploy history restores files, not a scheduled WordPress-aware backup of MySQL. UpdraftPlus (or similar) to storage you control is the boring correct answer — expanded in SSL and backups.

Plugin migrators versus hand migration

All-in-one migrators reduce toil. They still fail on giant sites, weird host timeouts, and serialized edge cases. Hand migration teaches you where the bodies are buried. Hybrid approach: use a plugin to package, verify URLs yourself, keep a raw SQL dump anyway.

There is no auto plugin/core update service after you arrive. You update in wp-admin. Cron on Pro+ is available if you want real schedules instead of traffic-driven wp-cron. Staging on Pro+ is a persistent copy — copy the DB if you want production content there.

What not to do

  • Do not lower TTL, flip DNS, and *then* start uploading. You will debug under outage pressure.
  • Do not edit SQL in Notepad with blanket HTTP→HTTPS replaces on serialized rows.
  • Do not assume “transfer” at the registrar moves files. Registrars park DNS; they do not ship wp-content.
  • Do not expect WPHost to offer email, cPanel, or a nonprofit migration coupon. Plans are Starter $9, Pro $30, Scale $65, Business $130. Trial ~1 day.

For first-time installs without an old database, use the host a WordPress website guide instead. For domain/MX choreography with less dump detail, use the transfer guide.

FAQ

Can I migrate without a database dump?

Not if you care about posts, pages, users, or settings. Themes alone are not a site. Always move MySQL (or restore from a backup plugin that includes it).

Why did my widgets break after search-replace?

Almost always unsafe serialized replaces. Re-import the dump and use a serialization-aware tool.

Should I change salts during migration?

Optional. Keeping them preserves login cookies across the cutover (still re-login if URLs change). Rotating salts forces fresh logins — reasonable after a messy shared-hosting past.

Does WPHost provide a staging clone of production for migration rehearsal?

Staging on Pro+ is a persistent environment. You still copy files and database yourself if you want production content. It will not invent a one-click full clone product we do not operate.

What about GitHub-based deploys for the move?

Fine for files if your workflow is git-based. The database still moves separately. GitHub connections are per-person — do not overclaim shared agency credentials.