Direct answer: For a migration cutover needing both low-latency connectivity and fast rollback, favor a dedicated, low-latency link (Direct Connect/ExpressRoute-class) over a VPN for the connectivity itself, paired with a DNS/routing strategy (split-horizon DNS with a short TTL and weighted routing) designed so rollback is a routing change, not a re-provisioning event.
Structured elaboration. VPN vs Direct Connect/ExpressRoute: a VPN (over the public internet, IPsec-encrypted) is faster to provision and lower cost, but has less predictable latency and throughput (subject to internet path variability); Direct Connect/ExpressRoute (a dedicated, private connection to the cloud provider) gives predictable low latency and higher throughput, at higher cost and longer provisioning lead time, and is the better choice when "low latency connectivity during cutover" is a stated hard requirement, as here. Bandwidth planning: size the dedicated connection for peak cutover-window traffic (which may exceed steady-state, if the cutover window itself involves data-sync catch-up traffic on top of normal application traffic), not just average load. Split-horizon DNS: serve different DNS answers depending on whether the query originates from inside the migration's private network path versus the public internet, useful for testing the new environment via the private/internal path before it's exposed to public DNS at all, decoupling internal validation from the actual public cutover moment. TTL changes: lower TTL well ahead of the cutover so any previously-cached, higher-TTL answer has fully expired before the actual change, so the public DNS change itself propagates quickly once executed. Weighted routing: use weighted DNS or a load-balancer-level traffic split to shift traffic gradually rather than all-at-once, which directly serves the "ability to rollback quickly" requirement, since a weighted shift can be reversed by adjusting the weight back, faster and less disruptive than reversing a full DNS cutover. Sample DNS cutover sequence ensuring minimal packet loss and fast rollback: (1) validate the new environment over the private/dedicated link using split-horizon DNS, invisible to public traffic; (2) lower public TTL and wait for propagation; (3) begin a weighted public traffic shift (small percentage first); (4) monitor for packet loss/latency/error-rate regressions at each weight increment; (5) increase weight progressively to 100% only once each increment holds clean; (6) keep the old path's weight available (even at a small non-zero value, or simply not yet decommissioned) for fast reversal if a regression appears even late in the shift.
Worked example. A migration with a strict cutover-latency requirement: provision a dedicated low-latency link ahead of the migration window, validate the new environment fully over that private path (using split-horizon DNS so this validation traffic never touches public routing), then execute the public cutover as a weighted shift starting at 10%, holding 15 minutes at each step, watching packet loss and latency percentiles, reaching 100% over roughly an hour if all steps hold clean; rollback at any point is simply resetting the weight, typically effective within seconds to low minutes rather than requiring a full DNS re-propagation cycle.
Trade-offs & pitfalls. Relying on a VPN for a migration with an explicit low-latency requirement, purely because it's faster to provision, risks the connectivity itself becoming the latency bottleneck the migration was trying to avoid; the provisioning-lead-time cost of a dedicated connection needs to be planned into the migration timeline early enough that it isn't a forced compromise later.
