No, well yes, but in reality no.
Set your DNS TTL really low before the migration (like 5 minutes), this tells clients to only cache the DNS for 5 minutes then refresh. In theory, after you change the IP over in your DNS it should only take 5 minutes for the clients to start hitting the new server IP.
Unfortunately, the theory isn't reality. Some ISPs and DNS providers cache records longer than the TTL set (I've seen some ISPs cache TTLs of 5 minutes for 48 hours) and, in short, there's absolutely nothing you can do from a technical perspective to stop them doing this, even though they shouldn't. And alas persuading all your users to move to OpenDNS might not be the best idea.
When I've moved larger sites before this is generally the process I follow;
Set up synchronization between the two (new and old) database servers.
If the database your using supports master-master replication (I.E. writes to ether node will be propagated to the other), run both the old server and the new server along side each other until all the clients have updated. This means clients can hit ether server and the site will be fully functional.
If the database only supports master-slave/log shipping etc. your only real option to keep the site up is to have the old server running a "read only" copy of the database, it would still have the latest data but only to read, not write/update. Depending on your site this might not be too much of an issue.
Another option, and probably the easiest to achieve, is put a proxy on the old server that forwards any requests to the new server. Users on the old server will experience some latency due to the extra hops in the proxy but with a clever caching configuration you can probably minimize that.
With any of the above options, monitor the old server and when all/most of the clients have gone decommission it as you would normally.
Of course, all of this could be avoided if everyone followed the standards they were supposed to.