Transferring WordPress to a new host is mostly an origin change. The brand URL readers type can stay exactly where it is: at the registrar. Mail can stay exactly where it is: MX at Google Workspace, Microsoft 365, Fastmail, or whoever actually runs IMAP. You are swapping the server that answers on the web hostname — not “moving the domain” as a mystical object.
This guide focuses on DNS, registrars, email continuity, and cutover timing. The dump-and-search-replace mechanics live in how to migrate WordPress to new hosting. Read both if you are mid-transfer; do not conflate them. Migration is files + database. Transfer is “keep the public name, change the backend, don’t break mail.”
What stays put
Registrar account. Renewals, WHOIS/privacy, and nameserver settings usually remain. You do not need to transfer the domain registration to WPHost — and WPHost is not a domain registrar product in this story.
Nameservers (often). Many people keep registrar nameservers and only change A/AAAA or CNAME records for the site. Others use Cloudflare nameservers. Either is fine. Changing nameservers wholesale is optional drama; changing the web records is the actual requirement.
MX and TXT for mail. If web and mail share a zone, edit carefully. Update the records that point web traffic. Leave MX alone unless mail is moving too (it usually is not).
WordPress identity. Same posts, same users, same licenses for themes/plugins once URLs match. The CMS does not care that the PHP process moved, as long as siteurl / home and asset URLs are consistent.
What actually moves
- PHP files and
wp-content - MySQL data
- Cron expectations (traffic-driven
wp-cronversus real schedules on Pro+) - TLS termination (preview HTTPS first on WPHost; custom-domain cert after DNS)
WPHost runs PHP 8.4 and optional MySQL. There is no cPanel, no inbox, no built-in CDN, no one-click installer. You upload a zip of the site (or deploy files), import the database, then point DNS when preview looks right.
A transfer timeline that avoids panic
T-minus a few days
- Inventory the live site: plugins that must work, storage size of uploads, PHP version assumptions.
- Lower DNS TTL on the apex and
wwwif you control them (300–600 seconds). Skip this if you cannot; transfers still work, they just linger in caches longer. - Export files + database. Store the artifacts somewhere durable — not only on the old VPS you are about to cancel.
- Create a PHP site on WPHost, provision MySQL, import, run serialized-safe URL rewrite toward the preview URL, and test. Details in the migration guide.
Cutover day
- Put a short maintenance note on the old site if edits must freeze (optional but sane for stores).
- Re-export a fresh DB dump if content changed since rehearsal; re-import and re-run search-replace as needed.
- In WPHost, attach the custom domain and create the DNS records the UI specifies.
- Change only the web records at the DNS host: typically A/AAAA for apex, CNAME for
www, or whatever pair WPHost documents for your case. - Do not delete MX, SPF, DKIM, or DMARC records while you are there.
- Wait for DNS to show the new origin and for the custom-domain certificate to issue.
- Set WordPress Address and Site Address to
https://your-domain(both). Avoid redirect loops — see custom domain hosting. - Log into wp-admin on the public hostname. Place a unique string in a draft post and view it on the front end to prove you are not staring at a cached old origin.
T-plus a day or two
Keep the old host billed and online until you are sure. DNS caches and colleague laptops lie. Only then cancel the old plan. Export one more backup from the new origin with UpdraftPlus or similar — deploy history on WPHost restores files, not a full scheduled WordPress backup.
Registrar versus DNS host versus mail host
People say “my domain is at GoDaddy” when they mean three different vendors. Split the checklist:
| Concern | Who | Transfer action |
|---|---|---|
| Paying for the name | Registrar | Usually none |
| A/CNAME for www | DNS host (may be registrar) | Point to WPHost |
| Certificate | WPHost after DNS | Wait for issue |
| Email delivery | Mail host via MX | Do not touch |
| WordPress app | You | Files + DB on WPHost |
If someone “transfers WordPress” by initiating a domain registration transfer between registrars, they added a 5–7 day distraction that does not move PHP files. Skip it unless you already hated the registrar.
Email footguns
Contact Form 7 (or any mail() based plugin) may have “worked” on shared cPanel because the old host silently offered sendmail. WPHost does not include email hosting. After transfer, configure SMTP toward your mail provider. Otherwise “transfers broke contact forms” tickets appear — they are mail transport tickets, not DNS tickets.
Newsletter DNS (DKIM CNAMEs) should remain. Only web records change.
www versus apex
Pick a canonical host before cutover. If production has always been https://www.example.com, keep that in WordPress settings and redirect apex → www at DNS or the edge. Flipping canonical host mid-transfer doubles search-replace work and invites split-brain SEO for a week. One hostname, HTTPS, consistent siteurl/home.
Agency and freelancer transfers
If you transfer a client site, document who owns the registrar login. Agencies on Business get team seats and up to 30 sites; Pro covers 3. GitHub connections are per-person — useful for file workflows, irrelevant to MX. Do not promise “we moved your Google mail onto WordPress hosting.” You did not. See agencies and freelancers.
Staging on Pro+ helps rehearse theme updates after the transfer; copy the database yourself if you need production posts on staging.
Pricing reality during a move
You may briefly pay old host + WPHost. That overlap is cheaper than an outage. Plans: Starter $9/mo (1 site, 2 GB), Pro $30 (3 sites, 10 GB, staging), Scale $65 (10 sites, 30 GB), Business $130 (30 sites, 100 GB, teams). Short trial ~1 day, then paid. No nonprofit coupon. No auto plugin updates after you arrive — you update in wp-admin.
When a transfer is the wrong framing
If you are renaming the brand URL, that is a migration plus a URL strategy, redirects, and Search Console work — not a quiet origin swap. If you are fleeing WordPress entirely, stop reading hosting transfer guides and pick a CMS exit plan. If you only need a brochure site and already have static HTML, a static host may be simpler than transferring WordPress at all — portfolio hosting discusses that fork.
FAQ
Do I need to unlock the domain or get an EPP code?
Only for changing registrars. Pointing DNS at a new web host does not require an auth code.
Will changing A records break email?
Not if MX records remain correct. Edit carefully. Take a screenshot of the zone before you touch it.
Can I keep the old host as a fallback?
Yes, and you should for a short window. Just avoid writing new posts to two databases. Freeze content or treat old as read-only after cutover.
Why does the site show the old design after DNS?
Cache: browser, DNS, or a CDN you forgot you had. Confirm the origin IP. Hit a unique preview path. Disable stale CDN cache for HTML if you operate one (WPHost does not bundle a CDN).
Is this different from migrating?
Yes in emphasis. Migration articles dwell on dumps and serialized replace. Transfer articles dwell on registrar, MX, TTL, and not confusing “move domain” with “move hosting.” You usually need both skill sets for a real cutover.