Backout plan template for network changes

Published 23 September 2026

A backout plan isn't "reverse the steps". It's three decisions made before the window opens, while everyone is awake: when do we stop, how do we get back, and how do we know we got back. Most backout plans answer the second and skip the other two, and the other two decide whether a failed change costs twenty minutes or the whole weekend.

Download the backout plan template (.docx)

A two-page Word document with seven sections and guidance in grey. The worked example below fills in every section.

What a backout plan is

A backout plan is the part of a change that says how to return the system to its state before the change, and when to do it. It's written before the change is approved and it belongs to that one change, usually as a section of the method of procedure.

Backout plan or rollback plan? Same thing. Change forms and network teams tend to say backout (or back-out); software teams tend to say rollback plan. ITIL uses the broader word remediation, which also covers fixing forward. What matters is the content, not the name.

"Restore from backup" is not a backout plan. It names a tool, not a procedure. It doesn't say which backup, restored how, by whom, in how long, or how you'd know it worked. It also quietly assumes that whatever you'd restore to is still reachable, which is often exactly what the change broke.

The backout decision time is arithmetic, not a feeling

Windows overrun because at 03:40 someone is ten minutes from finishing and reasonably believes it. The fix is a clock time, agreed in advance, when you stop trying to finish and start backing out. Work it out backwards from the end of the window:

	Example
Window ends	05:00
minus backout duration (measured)	35 min
minus verifying the backout	15 min
minus margin	15 min
Backout decision time	03:55

The duration has to be measured: timed in a lab, or taken from the last time this backout was run. A guessed duration makes the decision time fiction, and guesses are always optimistic, because nobody guesses in the time spent waiting for a console to respond.

If the decision time comes out earlier than the point where you'd know whether the change worked, the window is too short. That's worth finding out on Tuesday afternoon, not at 03:55 on Saturday.

The seven sections of the backout plan template

The template follows this order, and each section answers one question.

Triggers. The conditions that start a backout: the decision time arriving, a verification check that fails and stays failed, impact beyond what was approved. Written so nobody has to make a judgement call at 3 a.m. Plus one name for who decides.
Point of no return. The step after which these backout steps stop working: old hardware de-racked, a number ported, data written to the new system, a circuit released. Name it, or write "none". Most failed backouts crossed one that nobody had written down.
Before the change starts. What must be true before step one: backups read back, not just written; console access tested from outside the site; old hardware still in place; and a capture of the "before" state.
Backout steps. Exact commands and physical moves, each with the result you should see, who does it and how long it takes. Someone other than the author should be able to run it.
Verify the backout. The same checks as the change's own verification, compared against the "before" capture. The backout is finished when these pass, not when the steps run out.
Communication. Who hears that a backout has started, and who hears it's finished, with the message written in advance.
After a backout. Keep the evidence, record actual times, and find the cause before rescheduling.

A backout plan example: replacing a firewall pair

A worked example for a common, high-impact change: swapping the headquarters firewall pair for new hardware. The new pair is racked and configured beside the old one, and the change moves the cables and the traffic across.

BACKOUT PLAN   CHG-2026-0412
Replace HQ firewall pair: FW-OLD-A/B to FW-NEW-A/B

Owner:     [name]          Approver: [name]
Window:    Sat 17 Oct 2026, 01:00-05:00 CT
Duration:  35 min, timed in the lab run on 8 Oct,
           including the ISP call in B4 (worst case)
Decision:  03:55  (05:00 - 35 backout - 15 verify - 15 margin)

1  TRIGGERS: back out if any of these is true
   - 03:55 arrives and the site-to-site VPN step isn't done
   - A section 5 check fails and isn't fixed in 20 min
   - Any branch loses internet or VPN beyond the approved
     10-minute cutover outage
   Decides: change owner. Tell first: service desk lead.

2  POINT OF NO RETURN
   None in this window. The old pair stays racked, powered
   and cabled to its own patch ports until the Monday review.
   Decommissioning it is a separate change.

3  BEFORE STARTING (don't start if any of these fails)
   - FW-OLD-A/B running configs exported, opened and read
   - Old pair's inside/outside interfaces shut, not powered off
   - Patch leads labelled OLD-OUT, OLD-IN, NEW-OUT, NEW-IN
   - Console to both pairs via the OOB router, tested off-site
   - ISP ticket pre-opened for an ARP clear (see B4)
   - Before capture: ISP gateway reachable, 38 site-to-site
     tunnels up, web + VoIP registration + payroll SaaS test

4  BACKOUT STEPS                                          min
   B1  FW-NEW: shut outside and inside interfaces           2
       Expect: HQ loses internet. Expected, keep going.
   B2  Move outside lead NEW-OUT to OLD-OUT,
       inside lead NEW-IN to OLD-IN                         5
   B3  FW-OLD: enable outside and inside interfaces         2
       Expect: HA forms, FW-OLD-A active
   B4  From outside: can we reach the public /29?           3
       If not, call the ISP on the pre-opened ticket to
       clear ARP for the /29 on their router             (+10)
   B5  Wait for 38 tunnels to re-establish                 13
   B6  Run section 5                                    (15)

5  VERIFY THE BACKOUT (against the before capture)
   - ISP gateway reachable from FW-OLD-A
   - 38 of 38 tunnels up
   - Web, VoIP registration, payroll SaaS: pass
   - 10 minutes with no new drops in the firewall logs

6  COMMUNICATION
   Start:  "CHG-2026-0412 is being backed out. HQ internet
            and VPN back by 04:45."
   Done:   "Service restored at HH:MM. The change will be
            rescheduled after review."

7  AFTER
   Keep FW-NEW logs and the session capture. Record actual
   times. Don't reschedule until the cause is known.

Three details in that example do most of the work.

The old pair is shut, not powered off. Powering it off turns the backout into a cold boot of hardware nobody has watched come up in years. Shut interfaces mean the backout starts from a known-good, running box.

Step B4 exists because of ARP. When the public addresses move back to the old firewall's MAC address, the ISP's router may still have the new one cached. On Cisco IOS the default ARP timeout is four hours. The old firewall will usually announce itself with a gratuitous ARP, and usually is not a plan. Opening the ISP ticket before the window turns a four-hour outage into a ten-minute phone call.

The point of no return is pushed out of the window entirely. Decommissioning is a separate change with its own approval. Most "we couldn't back out" stories are really "we removed the old thing in the same window".

Five ways a backout plan fails

It depends on what the change broke. The rollback config is on a file server reached through the firewall being replaced, or the only way into the switch is over the uplink you just moved. Stage rollback files locally and test out-of-band access before the window.
The duration was guessed. The decision time comes from it, so a guessed duration makes the decision time wrong too.
There's no trigger, only steps. Everyone agrees the backout exists and nobody agrees when to start it. The window runs out while people discuss it.
An unlisted point of no return. A DHCP scope moved, a database migrated, a carrier asked to cease the old circuit "while we're at it". The steps are still written down; they just don't work any more.
The backout isn't verified. The steps are reversed, the window closes, and on Monday morning a branch is still down because its tunnel never came back. A backout needs checking just as much as the change did.

Who calls the backout

One named person, decided in advance. The person heads-down in the console is the worst-placed to make that call, so on a small team it usually belongs to whoever owns the window, often the manager. If that person might be asleep at 1 a.m., the plan says in writing when the call passes to the engineer. That's the row that matters in a RACI matrix for small teams: who signs off, and who needs telling.

After a successful change, or a successful backout, record what's actually running now. That's the as-built, and it overrides the plan. If the change is one site of many, keep the status in the rollout tracker as well: the free Excel project tracker has a Cut over stage before Accepted, so a site you might still need to back out isn't counted as done.

Sources

Cisco IOS command reference, arp timeout: the default is 14,400 seconds (four hours)
ITIL, for change types and remediation planning

Section names vary between organisations and change tools. The seven here are a working set, not a standard. Whatever your form calls them, the test is whether it records when you stop, how you get back and how you check.