Inventory the current service
Before changing DNS, record A, AAAA, CNAME, NS, MX, TXT, CAA, TTLs, redirects, certificates, mail providers, third-party senders and monitoring checks. Save the old configuration and identify who can roll it back. A migration plan that ignores email or certificates is incomplete even when the website itself looks simple.
Build and test the new service first
Prepare the new website, application, database, storage, certificates, redirects and mail service while the old system remains live. Test the new origin directly only through an authorized path, verify application data and permissions, and do not publish DNS until the new service can handle real traffic.
Prepare DNS and TTL deliberately
Identify exactly which records will change and lower their TTL while the old service is healthy. Existing cached answers cannot be shortened after the fact, so allow the previous longer TTL window to pass before cutover. Do not change unrelated records in the same operation; keeping the change set small makes rollback and diagnosis possible.
Switch web records with a checklist
Change the relevant A, AAAA or CNAME records, then check IPv4 and IPv6 separately. Verify the certificate covers the hostname, redirects lead to the intended canonical URL, cookies and sessions work, static assets load and the application reaches its database. A DNS answer showing the new IP is only the start of verification.
Protect email continuity
Keep MX records pointing to a working mail service until the new service is ready. Recreate SPF, DKIM selector and DMARC records, include every legitimate sender and send test messages from each provider. Check Authentication-Results at the receiving mailbox; website migration does not automatically migrate inbound or outbound email.
Verify from multiple viewpoints
Compare authoritative and recursive DNS answers from more than one resolver or network. Use Website Diagnostics for HTTPS status, response time, final URL, redirects and headers, and use IP Lookup to confirm the new network when relevant. Expect old and new answers to coexist while caches expire.
Keep an overlap window
Do not shut down the old website, mail service or database immediately after changing DNS. Keep the old path healthy for the relevant cache window and monitor requests, error rates, mail queues, certificate warnings and application logs. This catches clients and services that still use stale records.
Rollback without making the incident worse
If the new service fails, restore the recorded old values, keep the old service available and monitor convergence. Rollback is not instant when resolvers hold the new answer. Avoid repeated back-and-forth DNS changes; they create multiple cached states and make the incident harder to reason about.
Finish, document and raise TTL
After the website and mail flow are stable across networks, restore sensible TTL values. Document final DNS records, certificate renewal ownership, mail authentication settings, monitoring URLs, old-service retirement time and the exact rollback procedure. A migration is complete only when another operator can understand and reproduce the final state.
Check real data now
Use the live IIPP tool to inspect the domain or IP address you are working with.
DNS Record Lookup →