Networking
Swapping the WAN cable takes about ten minutes. Everything that breaks afterward is the part nobody warned you about.
A hotel we support was moving to a new internet circuit. Better bandwidth, lower cost, easy decision. The new circuit was installed and lit weeks ahead of the swap. On paper this was a ten minute job: update the firewall WAN config, move the handoff cable, verify, done.
It went fine. But it went fine because we spent more time on the inventory than on the cutover itself, and the inventory is the part that almost nobody plans for. If you are the only IT person at your company and you have a circuit change coming, this is the checklist I wish someone had handed me the first time.
When you change ISPs, you almost always change your public static IP. That IP is not just an address. Over the years it quietly becomes a credential. Systems all over your environment and half your vendor list have been told to trust it, and nobody wrote any of that down.
The morning after a cutover, the failures do not look like network failures. They look like random application problems. A booking integration stops syncing. A vendor portal starts rejecting logins. A payment terminal times out. Nobody connects those to the circuit change, so you burn hours chasing the wrong thing.
The core rule: before you touch anything, find every system that knows your old public IP by heart. That list is longer than you think and no two environments are alike.
Work through these methodically. On the job that prompted this post, we found allowlist entries in four places nobody had thought of.
The practical way to build this list is to stop guessing and go look. Pull your firewall's inbound NAT and rule set, check outbound rules that reference your WAN address, then walk your vendor list and ask each one directly: do you restrict by IP? Most will say no. The ones that say yes are the ones that would have ruined your week.
Here is the scheduling mistake that puts real pressure on a cutover, and it is almost always made before the technical work starts.
Someone in finance or at the vendor files the cancellation on the old circuit as soon as the new one is ordered. That starts a countdown, usually 30 days. Now the cutover has a hard deadline that has nothing to do with technical readiness, and the business is paying for two circuits until it happens, which creates pressure to rush.
Flip the order. Get the new circuit installed, tested, and carrying real traffic first. Only then file the cancellation on the old one. Yes, you overlap and pay for both for a few weeks. That overlap is the cheapest insurance you will ever buy, because it is also your rollback plan.
If you take one thing from this post: never let the old circuit's cancellation clock start before the new circuit has been verified in production. The double billing is not waste. It is the safety net.
A cutover forces you into the edge of the network, so use the trip. First, document what you found. The allowlist inventory you just built is genuinely valuable and it will save you or your successor days the next time. Put it somewhere that is not your inbox.
Second, look honestly at what else lives at the edge. On these jobs we routinely find a door lock controller, a camera recorder, or a building system sitting on the network with default credentials and firmware from several years ago, exposed because someone needed remote access once. The circuit change did not create that problem, but it is a good excuse to fix it.
An ISP cutover is not technically hard. It is an inventory and sequencing problem wearing a networking costume. The teams that get burned are not the ones who lack skill, they are the ones who were given a deadline before anyone counted what depended on the old address.
Count first. Overlap the circuits. Keep the rollback path warm. Then the cable swap really is a ten minute job.
Got a cutover coming and nobody to hand the rollback plan to? That is exactly the kind of thing we cover for internal IT teams. See how co-managed works or talk to an engineer.