Quick answer
A reversible hosting move needs a tested destination, a recoverable copy of the source, a plan for writes and a way to reach both hosts. Change DNS only after those are ready. Returning DNS to the old address does not undo new database transactions.
Treat the move as an application change
This plan covers a hosting move that keeps public URLs unchanged. Include files, databases, uploads, jobs, forms, certificates and external integrations. If the domain or paths also change, add a URL mapping and redirect plan.
Identify the application owner, old and new hosts, authoritative DNS operator, rollback decision-maker and permitted maintenance window. A managed service may require its operator for database, server or DNS actions; do not assume customer root access. Record a success threshold before switching traffic.
Create a recoverable starting point
Inventory application version, runtime, files, databases, uploads, environment secrets, outbound mail, background workers, payment or webhook endpoints, redirects, TLS and search-verification files. Record public DNS A, AAAA, CNAME, MX and relevant TXT values with TTLs; an MX target or SPF mechanism can depend on a changed web address. Capture a restorable backup and test its restoration or integrity. A snapshot that has never been checked is a weak rollback.
Plan how writes will be handled during overlap. For a database-backed site, old and new copies can diverge if both accept orders or comments; consider an authorised freeze or synchronisation design. Keep the old service running and its credentials available through the observation period.
Prove the candidate site before public traffic
Deploy the candidate with the intended hostname and test pages, assets, login, forms, checkout and jobs using an approved preview route. Check HTTPS, redirects and the public entry directory. If a temporary public preview hostname exists, keep appropriate access restrictions or noindex there; remove any temporary crawl block from the canonical live destination at cutover, not from an exposed preview. Google’s hosting-change guide recommends testing the copy, monitoring both hosts and retaining the old host until traffic has moved.
Lower a relevant DNS TTL ahead of time if the DNS provider supports it, remembering previous cached answers keep their old TTL. Decide what specific health or conversion failure will trigger rollback and who can authorise it.
Switch once and observe both sides
At the agreed window, complete the final data sync or write freeze, then change only the verified public web record at the actual authoritative DNS provider. Record the time and old value. Query authoritative and recursive answers, test the site from outside, and observe old and new server logs. Verify real application tasks and outbound mail, not just a homepage. Users can reach either host while caches differ, so monitor for split writes and keep both environments prepared.
Do not cancel the old account after the first successful browser test. Let the pre-agreed observation criteria, TTL overlap and application owner decide when it is safe to retire.
Example: an order arrives during the switch
Suppose DNS changes at 10:00, but one customer’s resolver still returns the old host at 10:05. If both sites accept orders, their databases may diverge. A controlled write pause or a tested shared-data/synchronisation design prevents the two copies from becoming competing sources. Record orders on either side before any rollback.
If the new application passes page checks but loses a transaction, pause writes under the agreed incident plan and reconcile the data before retiring or rolling back either host. A healthy homepage is not the cutover acceptance criterion.
Roll back using evidence
If the agreed failure threshold is met, stop writes where the application plan requires, restore the previous web record, and account for users who may still hold the new answer. A DNS rollback alone cannot reconcile data written to two databases. Apply the prepared data reconciliation or restore plan with the application owner, then verify user-visible functions and mail. If the issue is isolated to a new certificate or one form, a targeted repair may be safer than full rollback; use the pre-agreed decision rule.
Record final DNS answers, application health and the state of both hosts. Retire the old infrastructure only after traffic and dependencies have moved and a usable new backup exists.
Common questions
Can I roll back by changing DNS alone? Only if application data and dependencies remain compatible.
Why keep the old host? Cached DNS and delayed clients can continue reaching it.
Does this move email? Not by default; check mail dependencies separately.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.