Browse this section

DNS changes during a migration

DNS changes are not seen everywhere at exactly the same moment. Authoritative records, resolver caches and application caches can affect what a user reaches. Plan a period in which the old and new endpoints may both receive traffic.

Before changing records

  • Identify the authoritative DNS provider and export or record the existing zone.
  • Review website, mail, verification and certificate-validation records; changing nameservers affects more than the website.
  • If using a lower TTL for cutover, change it early enough for the previous TTL to expire.
  • Validate the destination and decide how to avoid writes diverging between old and new systems.

After cutover, check authoritative records, several independent resolvers and the application itself. Keep a documented rollback, and do not delete the previous environment immediately. Coordinate any required DNS updates with your current DNS provider and keep access to the domain account available during the migration.

Was this guide helpful?

Related guides

Preparing a server migration

A migration is a coordinated application and data change. Moving files alone may miss databases, scheduled tasks, certificates, runtime versions or external integrations. Prepare a tested d…

Reporting a slow application or server

Describe the user-visible symptom before assuming that more CPU or RAM is the solution. Slow requests may originate in the application, database, storage, external API or network. Useful me…

Choosing useful monitoring and alerts

Monitoring is useful when an alert identifies an action someone can take. A running server does not necessarily mean that logins, payments or other important application functions work. Agr…

Need help applying this to your service?

Tell us your service reference and what you need to achieve. Never include passwords or private keys in a ticket.

Contact support →
← All knowledgebase topics