A friend of mine had to move some websites configured as vhosts on a certain ip to another hoster/ip and wanted this to happen without users noticing. The common approach is to lower the TTL a few days before switching to the new ip and maintain the old server up for an overlapping period. This is necessary because of broken dns cachers that won't honor the TTL and serve the cached ip.
A stale copy of the website and/or a message about the relocation can be displayed, altho there are cases where data between new and old site can be shared to achieve seamless relocations. Unfortunately none of this was either possible or good enough for my friend.

To further complicate things other domains were configured on that ip so redirecting the entire web traffic via iptables or similar wasn't an option. With apache running as webserver he thought of using mod_proxy but then bumped into another limitation: ProxyPass /path newsite/path would required newsite to be a different vhost pointing to the new ip, and a vhost had to be used since an ip would resulted in several domains being served with the same docroot. While doable and a good solution, using a different domain to refer to the new ip would meant additional configuration on the new host, which he once again didn't like the sound of.

But he wasn't far away from the solution. What I suggested at this point was to use the same url and force the old server to use the new ip address for those domains by either static entries in /etc/hosts or an up to date nameserver in /etc/resolv.conf. This way, when a request comes in and the proxy rule is applied, a new request is generated for the same domain, but this time it's resolved on the server itself rather than on the broken client, resulting in the request to be sent to the new box. Game!

As a matter of facts, for reasons still unknown to both of us, mod_proxy breaks some flash control panel thingie he's got . Replacing mod_proxy with mod_rewrite and P flag did the trick.