Every DNS record is published with a TTL. When a recursive resolver fetches the record, it keeps it in its cache and answers later queries from there, counting the TTL down. Only when it reaches zero does the resolver go back to the authoritative nameserver. Caching is what keeps DNS fast and keeps the load on authoritative servers low.
The trade-off is control versus efficiency. A long TTL (hours or a day) means fewer queries and more resilience if your DNS provider has an outage, but a change takes that long to be seen everywhere. A short TTL (a few minutes) makes changes take effect quickly at the cost of more queries.
The practical routine for a planned migration: lower the TTL well in advance (at least one old-TTL period before the change), make the change, confirm it works, then raise the TTL again. Lowering the TTL at the same moment as the change does not help, because resolvers still hold the old answer with the old TTL.
Example
example.com. 300 IN A 192.0.2.10 ; cacheable for 300 seconds