Before moving a WordPress site to a new host, prove that the destination can run the site, that you can move both files and data, and that you have a cutover and rollback plan. Copying the site is only one part of a migration. The business risk sits in what changes around it: DNS, HTTPS, email, caching, scheduled jobs, forms, integrations, and the moment traffic switches.
Start with compatibility, not the sales page
Inventory the current environment and the requirements that matter. Check the WordPress and PHP versions, database engine, storage use, HTTPS setup, active theme and plugins, scheduled tasks, outgoing mail path, server-level redirects, and any unusual file permissions or extensions.
Do not assume a higher plan or newer server automatically means compatibility. A plugin may depend on a PHP extension, a large import may hit execution limits, or a background task may depend on a server cron job that is not part of the WordPress database.
Decide what must remain unchanged
Write down the invariants before the move:
- public URLs and permalink behavior;
- forms and their destinations;
- ecommerce, membership, or login flows;
- email records and mail routing;
- analytics and consent behavior;
- redirects and canonical URLs;
- backup and recovery access.
This turns migration testing into a comparison instead of a general impression that the new site "looks right."
Build and test the destination first
Move a current copy into a non-public destination and test it before changing DNS. The WordPress migration documentation explains that WordPress addresses and environment details may need deliberate handling during a move. Search-and-replace work also needs to respect serialized data; a blind text replacement can damage stored settings.
Test representative pages, media, logins, forms, search, redirects, and plugin-specific business flows. Check the browser console and server errors if the supported operating path exposes them. Confirm that HTTPS will cover the intended hostnames.
Treat DNS and email as separate work
The domain registrar, DNS provider, website host, and email provider may be four different companies. Before cutover, export or record the current DNS zone, identify which records belong to the website, and protect the MX, SPF, DKIM, DMARC, verification, and other records that should not change.
Lowering DNS time-to-live can shorten some caching before a planned switch, but it does not replace a rollback plan. Know exactly which record or nameserver will change, who can change it back, and how you will recognize that rollback is needed.
Plan for changes made during the move
If the site receives orders, form entries, comments, registrations, or content edits, define a content-freeze or data-sync window. Otherwise, the new copy may go live without activity that reached the old server after the first migration.
Choose the cutover window based on real business traffic, not only operator convenience. Name the person who will verify the site after the switch and the person authorized to roll it back.
Verify beyond the homepage
After cutover, verify DNS resolution, HTTPS, key pages, admin access, forms, email delivery, redirects, analytics, scheduled work, and a current backup on the new host. Keep the old environment intact until the agreed verification window closes.
The TechDex Hosting page describes the site's current hosting categories without claiming every WordPress move is the same. If you need an environment and migration scope reviewed together, start with an HQ Tech Consultation so the cutover plan reflects the site you actually have.