After a migration the old site keeps appearing. Before waiting any longer, find out which of the three it is: the change has not propagated, something local is caching, or the record you edited is not the one being used.

Ask the authoritative server directly

dig +short yourdomain.com @8.8.8.8\ndig +short yourdomain.com @ns1.yourprovider.com    # the authority itself

If the authority already returns the new IP, the change is done and everything else is caching. If it returns the old one, the record was not saved, or it was saved at a provider that is no longer running your DNS.

Which nameservers are actually in charge

dig +short NS yourdomain.com\nwhois yourdomain.com | grep -i "name server"
This is the fault people lose a day to: the zone was edited at the old host while the registrar points the domain at a different provider. The record is perfect and nothing is reading it.

If it is caching

# your own machine\nsudo systemd-resolve --flush-caches || sudo resolvectl flush-caches\n# then check what the TTL was\ndig yourdomain.com | grep -A1 "ANSWER SECTION"

The TTL is how long resolvers were told to keep the old answer. A TTL of 86400 means up to a day, and nothing you do speeds that up for someone else. Lower the TTL to 300 a day BEFORE a planned move.

And the records that were forgotten

  • www as well as the bare domain.
  • The AAAA record, if IPv6 exists - see IPv6 on a VPS.
  • A CNAME that still points at the old host.
  • A CDN, which has its own idea of your origin regardless of DNS.
Test the new server before moving anything, with a hosts-file entry on your own machine. Then the DNS change is the last step and not the experiment - see migrating with no downtime.