Move WordPress to a New Host Without Changing the Domain: Migration, Testing, and DNS Cutover

A studio has used its website for years and wants a different host without reprinting business cards or changing article URLs. A move like this can usually keep the domain and paths; what changes is the hosting environment that serves the site. Test the new site first, then direct traffic to it. That makes problems easier to identify than changing DNS at the outset.

The most underestimated part is often not file size but data that keeps arriving during the move. After the first copy, the old site may receive another comment or inquiry. If the new site is also open, records can be split between them. The process below treats this last data handoff as its own step, so you know both where the site went and where its newest records ended up.

Make a handoff checklist and define the scope

List the old host, new host, domain registrar, and DNS provider. One company may fill all four roles, or each may be separate. Changing only the web host does not necessarily require transferring the domain registration. If you also change nameservers, inspect the entire DNS zone, not just the website IP address.

Record the WordPress, PHP, and database versions, disk usage, and main plugins. List email, scheduled jobs, outbound mail, CDN, and third-party callback URLs separately. Check the migration plugin’s actual version and configuration to see what it carries. One export file does not mean every service in the hosting control panel has been handed over.

1. Confirm who can log in to the old host, new host, DNS, and backup storage.
2. Save the current DNS records and a full site backup, and document how to retrieve them.
3. Choose a cutover window and notify people who update the site or process orders.

Create a testable copy on the new host

Prepare the site space, database, and required software versions on the new host. Then import files and database using the host migration service or chosen tool. If the database connection must change, use values supplied by the new host; do not overwrite them with the old host’s credentials. Check whether custom server rules also apply to the new environment.

For a host move with unchanged URLs, the site’s stored public address should remain the same. UpdraftPlus provides a separate official procedure for this case and warns against arbitrary database URL replacement. A temporary preview URL may change links or login behavior. Ask the hosting provider which preview method preserves the production address.

Restrict access to the copy, and disable real payments, notifications, and other outward writes. In particular, scheduled jobs must not send email from both environments at once. Record the isolation method and which functions must be restored at launch so necessary services are not left disabled.

Confirm that you are actually seeing the new host

Identical browser pages make it easy to mistake the old site for the new one. Use the host’s preview entry point, or ask someone comfortable with computer configuration to temporarily map the domain to the new IP in the local hosts file. This affects only the test computer; it does not change DNS for the world. Remove the test mapping afterwards.

Place a restricted identification marker on the new site, then check the new host’s access logs to confirm requests arrive there. HTTPS certificates also need to work; bypassing a browser warning is not an acceptable launch condition. If the host requires domain verification before issuing a certificate, use its supported verification method.

1. Open the home page, posts, images, downloads, and login page; confirm none bounce back to a temporary URL.
2. Try search, menus, forms, and required functions; verify notices reach a test inbox.
3. Check mobile layout, old post permalinks, and error pages; save a list of problems.

Handle the last difference in data

The first copy is useful for checking functionality, but the production cutover needs a defined data point. For a site with little activity, coordinate a window to pause publishing and interaction, make a final backup and import, then compare the latest content. If transactions continue, have someone familiar with that system design synchronization and deduplication; do not overwrite the whole database.

When pausing functions, give visitors a clear message with an expected return time and contact method. Save record counts, the most recent item time, and relevant identifiers on both sides of the cutover, but keep personal data out of public documents. Verify consistency before re-enabling writes, so testing does not create a fresh difference.

Switch DNS and check what different networks see

Choose a suitable TTL through the DNS service in advance to shorten later adoption of new records. Cached old values do not vanish as soon as you press Save. At cutover, change only the planned web records. Check the apex domain, www, IPv4, and IPv6 for old targets, while preserving mail records still in use.

Before launch, remove the test site’s access restrictions and any indexing block used only for testing, then enable required integrations. Check from home and mobile networks and compare logs on both hosts. Google’s host-move guidance also recommends watching traffic on both sides. One computer working does not prove all visitors have switched.

Define rollback conditions before you retire the old host

Agree before cutover which problems require rollback, such as failure to submit an essential service, missing data, or many broken inner pages. If DNS must point back, inventory and save data created on the new host first; otherwise, content received moments ago may disappear when traffic returns to the old site. Rollback is a data handoff, not merely changing an IP address.

Keep an incident log with discovery time, URL, network used, expected result, and actual result. Give each issue one owner. If several people change DNS, plugins, and host settings at once, a problem that was once easy to locate becomes hard to reproduce.

Only after the new host serves traffic reliably, the old site has no visitors or services needing attention, and a new-environment backup has succeeded should you plan to stop the old host. If the old plan also carries email or DNS, hand off those services first. Stopping renewal and deleting service immediately may have different effects; read the billing page before acting.

Create a restorable website backup first

Understand DNS records and resolution problems

Set up the website HTTPS certificate

• Tutorials
• Apps & software
• Websites & e-commerce
• WordPress