How to Switch ISPs Without Downtime: IP Renumbering, DNS and Cutover Planning

Switching your internet provider sounds like a simple procurement decision until you map every place your public IP addresses actually appear. Your firewall NAT rules, your VPN peers, your DNS records, your customers allowlists, your monitoring probes, and your cloud security groups all contain copies of an address block that belongs to a carrier you are about to leave. Cut the old circuit before you have chased down every copy and some part of your network goes dark, not because the new circuit failed but because the configuration still points at an address that no longer answers.

A downtime free switch is therefore not a single event but a sequence you control. You build the new path alongside the old one, you make DNS and routing converge quickly on the new addresses, you move traffic in stages you can observe, and you keep the old path alive long enough to catch what you missed. When your team does it this way, the cutover itself becomes anticlimactic, which is exactly the outcome you want.

Understand What Changes When You Switch ISPs

A new ISP changes more than the cable in your demarc. You get a new handoff, often a new router interface or VLAN, a new block of public IPs unless you hold portable space, new BGP peering details if you multihome, and new reverse DNS delegation. Every service that was bound to the old provider allocated block now needs a decision: renumber it, re advertise it, or update the reference that points to it.

The inventory you need before you order the new circuit is concrete. List every public IP you currently announce or use, where each one is assigned, which NAT translations depend on it, which firewall and VPN configurations reference it, which DNS records point to it, and which external partners have it on an allowlist. That list is the scope of the migration. Without it you are guessing at the blast radius, and the things you forget to list are the things that will cause the outage you were trying to avoid.

IP Renumbering Versus Keeping Your Addresses

Whether you renumber depends on who owns your public addresses. Most organizations use provider allocated space that the ISP assigned from its own aggregate. That space cannot move with you. When you leave the provider you must return it and renumber every service onto the new provider allocated block. The alternative is provider independent space that your organization holds directly with your own autonomous system number and advertises via BGP. If you have that, you keep the same addresses and simply shift the BGP announcement from the old provider to the new one.

Provider allocated renumbering is the common case and it is where migrations fail. You need to assign the new block to the same roles the old block served, update NAT pools and firewall policies, reconfigure VPN peers that match on IP, update DNS A records, and notify every external party that allowlists your addresses. Build a translation table that maps each old IP to its new counterpart, record it alongside your IP address inventory so nothing is tracked from memory, and validate that no stale reference survives into the cutover window.

If you do hold portable space, the migration is a routing change rather than a renumbering exercise. You bring up BGP with the new ISP, advertise the same prefix, and shift traffic by tuning local preference or prepending until the new path is preferred. Keep both sessions up during the transition and withdraw the old announcement only after you have confirmed traffic flows cleanly on the new provider. Portable space is the strongest insurance against future provider changes, and the organizations that have it switch ISPs with far less operational risk.

DNS Is Your Time Machine

DNS is the control plane for every public service you expose, and its time to live value determines how quickly a cutover actually converges. If your A records carry a TTL of 86400 seconds, resolvers around the internet can serve the old address for a full day after you change it, no matter how perfectly you configured the new circuit. Lower the TTL well before you need it to be short. The rule is to make the change at least twice the previous TTL before the cutover so every cached entry has time to expire and be re fetched with the new short value.

For a renumbering migration, create the new A records in advance where possible and keep both sets resolvable during the parallel period. Public services that must stay reachable should answer on both the old and new IPs until you are confident the new path handles all traffic. VPN peers and site to site tunnels deserve special attention because many implementations cache the peer IP at tunnel establishment and do not re resolve DNS until the tunnel flaps. Plan a controlled rekey or tunnel bounce as part of the cutover rather than waiting for users to discover that a tunnel is still pinned to the old address.

Do not forget reverse DNS. Your new provider must delegate the PTR zone for the new block or host it on your behalf, and any service that validates reverse lookup, including mail servers, will treat a missing PTR as a failure. Confirm delegation and test forward confirmed reverse DNS before you move mail or other PTR sensitive workloads.

Build the Parallel Path Before You Cut Anything

The only architecture that delivers a hitless provider switch is two live circuits at the same time. Order the new ISP circuit early enough that it is fully provisioned, tested, and carrying lab traffic before you schedule the cutover. Terminate it on separate physical infrastructure from the old circuit where you can, with its own handoff, its own router interface, and ideally a separate entry point into the building.

With both circuits live, validate the new path under realistic conditions. Shift a small portion of outbound traffic onto it, run your synthetic monitoring over the new source IPs, test NAT and firewall behavior with the new addresses, and exercise every VPN peer that will need to re establish. If you use BGP with portable space, bring up the new session, advertise the prefix, and observe path selection before you make it preferred. If you are renumbering, confirm that inbound traffic on the new block reaches the correct internal hosts and that outbound traffic that egresses the new provider returns via the same path or is handled correctly when it does not.

This parallel period is also when you discover the hardcoded references that no inventory captures perfectly. Application configs that embed a public IP, SaaS IP allowlists that were set up years ago, and monitoring checks that target a specific address all surface when you route test traffic through the new IPs and watch what breaks. Finding them while the old path still works is a minor fix. Finding them after you decommissioned the old circuit is an outage.

The Cutover Sequence That Avoids Downtime

When the parallel path is proven, the cutover is a controlled traffic shift rather than a flash cut. Lower DNS TTLs already, then update A records to the new addresses or shift BGP preference to the new provider. Move outbound NAT to prefer the new egress, and handle inbound services in priority order starting with the least critical so you can observe behavior before you move the services that cannot afford a retry.

Migrate VPNs deliberately. For each site to site peer, update the peer address on both ends during a maintenance window you control, then bounce the tunnel and verify that traffic flows and that failover between multiple peers still works. For remote access VPN, publish the new portal address via DNS and keep the old portal answering until client caches have turned over. For any service with an external allowlist, notify the counterparty well before the cutover and confirm the new IPs are whitelisted before you withdraw the old ones. An allowlist update that happens after the cutover is an outage with an email trail that proves it was preventable.

Throughout the shift, keep the old circuit forwarding. Dual egress with policy routing or a temporary preference for the new path lets you move traffic back in seconds if monitoring shows errors. The ability to revert a route or a DNS record without waiting for a carrier dispatch is what makes the whole sequence safe. A cutover without a one command rollback is not a plan, it is a hope.

Validate Everything Before You Decommission

Validation starts the moment the new path carries production load. Watch your edge routers for asymmetric routing or unexpected next hops, your firewall logs for denies against the new NAT pool, and your application logs for failures that correlate with the egress change. Run synthetic checks from outside your network against every public DNS name and every VPN endpoint, confirming that new addresses answer and that certificates and reverse lookups are correct. Compare throughput and latency on the new provider against the baseline you captured on the old one so you catch MTU or carrier shaping issues while both paths are still available.

Hold the parallel run for at least 48 hours after the last service has moved, longer if your TTL was high or if you have global users behind resolvers that honor TTL loosely. That window is when the last cached DNS entries expire, the last hardcoded peer is discovered, and the last partner allowlist gap surfaces. Track every finding as a punch list and do not close the migration until the list is empty. Only then should you withdraw the old BGP announcement or release the old provider allocated block, update your circuit inventory to reflect the new provider and handoff, and archive the old circuit record with its decommission date.

The final step is the one most teams skip: tell the organization the migration is done. Update the network documentation that the next engineer will rely on, publish the new address assignments and circuit details where your team can find them, and confirm that monitoring, backups, and carrier contacts all point to the new provider. A migration that is technically complete but undocumented is a migration that the next incident will undo, because the person on call will follow the old diagram that nobody updated.

For teams that maintain their network records centrally, keeping circuits, public subnets, and DNS references in one place makes this entire sequence observable. In Obelinf, recording the new provider block, the NAT mappings, and the cutover date alongside the circuit record turns a provider switch from tribal knowledge into an auditable change that the next migration can build on.