WordPress
Move WordPress hosting with minimal DNS downtime
Lower DNS TTL, copy twice, freeze writes and verify the target before changing records.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Build and test the target first, lower DNS TTL in advance, then control the final write window: freeze changes or synchronize the database immediately before cutover. Keep the old host available until traffic and data consistency are verified.
What this means in plain English
Build the new copy before changing DNS. Test it through a temporary address or local hosts-file entry, then plan a final period when content, forms or orders stop changing on the old copy while the newest database is moved.
Lower the DNS time-to-live in advance and keep the old host working while caches change. DNS updates are not instant for every visitor. Retain the previous records and hosting until the new site is proven.
How do you avoid losing late orders or form entries?
| Preparation | Target tested by hosts-file or temporary URL |
|---|---|
| Write control | Short freeze or explicit final database sync |
| Rollback | Old service and previous DNS values retained |
A simple example
A shop copies files and database two days early for testing. At cutover it pauses orders, makes one final database copy, changes the web record and tests checkout. The old host remains available for rollback while DNS answers settle.
What to do, step by step
1. Inventory domains, mail, cron and integrations.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on preparation: target tested by hosts-file or temporary url. Write the result down so you can compare it later.
2. Copy files and database to staging.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Run a final synchronized cutover.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Check logs, forms, login and TLS from multiple networks.
Finish by checking the result against rollback: old service and previous dns values retained. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
List email DNS records separately. Moving the website does not mean MX, SPF, DKIM and DMARC should be replaced.
Common mistakes and how to avoid them
Changing DNS before testing.
This gives a misleading or unsafe result because it leaves out preparation. A better approach is to inventory domains, mail, cron and integrations, then check the result before making the change permanent.
Editing content on both copies.
This gives a misleading or unsafe result because it leaves out write control. A better approach is to copy files and database to staging, then check the result before making the change permanent.
Cancelling the old host immediately.
This gives a misleading or unsafe result because it leaves out rollback. A better approach is to run a final synchronized cutover, then check the result before making the change permanent.
Words explained
- WordPress
- A content management system that lets people edit pages and posts through an administration screen.
- staging
- A private copy of a website used to test updates before changing the live site.
Quick checklist
- Inventory domains, mail, cron and integrations.
- Copy files and database to staging.
- Run a final synchronized cutover.
- Check logs, forms, login and TLS from multiple networks.
Common questions
What is the simple answer?
Build and test the target first, lower DNS TTL in advance, then control the final write window: freeze changes or synchronize the database immediately before cutover. Keep the old host available until traffic and data consistency are verified.
What should I check first?
Start with preparation: target tested by hosts-file or temporary url. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Inventory domains, mail, cron and integrations. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Changing DNS before testing. Avoiding that one mistake makes the rest of the comparison much more trustworthy.