Record what the domain currently serves
List the DNS provider and the records used by the website, email and other business services. Include relevant subdomains and verification records. Do not assume an unfamiliar TXT or MX record is unnecessary. Ask the responsible provider or account owner before removing it, especially when a website migration is being handled separately from business email.
Define the exact change and rollback
Write down which records must change, their approved new values and who supplied them. Preserve the previous values securely enough to support recovery. Decide who can make the change and who verifies each affected service. A rollback plan should be practical, while recognising that DNS caching can prevent an immediate reversal for every visitor.
Allow for caching and dependencies
Record the existing time-to-live values and understand that changes may be observed at different times by different resolvers. Lowering a TTL shortly before a switch does not erase previously cached answers. Coordinate certificate, hosting and application readiness before directing traffic to the new target. Avoid promising one universal propagation time.
Verify from outside the hosting account
Check DNS responses, the public website, important subdomains and actual email delivery as relevant. Follow a nested URL and confirm HTTPS behaviour, not just the homepage. Keep monitoring during the agreed change window and document any discrepancies. Close the change only after the people responsible for web and mail confirm their services work.
Your practical checklist
- Inventory web, mail and verification records
- Record approved changes and previous values
- Coordinate caching, certificates and target readiness
- Verify affected services externally
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK