Most cutover plans describe how traffic moves to the new cloud in careful steps. The rollback section is usually one line: revert if something goes wrong. That line hides the hardest part. By the time a cutover starts, DNS records have changed, routes have been withdrawn in one place and announced in another, connections are open on paths that did not exist an hour earlier, and some data has already been written on the new side. Reversing a cutover is not the forward plan played backwards. It is its own network design, and it needs to be written, timed, and tested before the window opens.
1. Name the point of no return before you start
Every cutover has a moment after which a simple rollback stops being possible. It might be the first write accepted only on the new side, the moment an old queue is drained and deleted, or the step where a shared database changes format. Write that moment down as a specific, observable event, not a feeling.
Before that moment, rollback means restoring the previous routing and DNS state. After it, rollback means a second migration, with its own data reconciliation. Teams get into trouble when they treat a post point of no return failure as if the first kind of rollback still applied. The runbook should have two separate sections, with different owners, different time estimates, and a clear rule for who declares which situation the team is in.
A useful test: if the decision maker cannot say, in one sentence, what has already changed irreversibly, the cutover is not ready to start.
2. Lower TTLs early, and raise them back on purpose
DNS is often the steering wheel for a cutover, and also the slowest part to reverse. If records still carry a one hour TTL when the window opens, a rollback decision taken at minute ten may not reach every resolver for most of an hour. Some clients will keep arriving at the new side long after the team believes traffic has returned.
Lower the TTLs for every record involved at least one full old TTL period before the window, and verify the shorter value is actually being served from public resolvers, not just present in the zone file. Record the original values in the runbook so the rollback restores the record and, later, the original TTL. Leaving production records at a five minute TTL for weeks after a cutover is a quiet cost: more query traffic, more dependence on DNS availability, and a resolver behaviour change nobody chose deliberately.
Also plan for the clients that ignore TTLs altogether. A small share of resolvers and pinned clients will keep using the old answer past its expiry. Rollback is complete only when connection counts on the new path fall to near zero, not when the record change returns a success message.
3. Reverse routes in the opposite order to data
Forward cutovers usually move data first, then shift read traffic, then shift write traffic, then withdraw the old routes. Rollback tempts teams to withdraw the new routes first, because that feels like undoing the change. That order can strand traffic: clients still steered to the new side arrive to find no return path, and stateful firewalls drop the replies even when a forward path exists.
A safer rollback order is:
- Stop new work starting on the new side, while keeping its paths up.
- Steer clients back with DNS or load balancer changes, and watch connection counts move.
- Drain and reconcile writes made on the new side since the cutover began.
- Confirm the old side is serving normally under real traffic, not just health checks.
- Withdraw the new routes and close the temporary firewall openings last.
Keeping the new path alive during the return is counterintuitive and essential. The path you are abandoning is still carrying the sessions you need to bring home.
4. Track every temporary opening as rollback debt
Cutovers accumulate temporary state: a firewall rule opened for a migration tool, a route added for one subnet, a security group widened for a single night, an exception in an egress policy. In a forward success those items are cleaned up in a calm follow up. In a rollback they are confusing. Nobody is sure which openings the old configuration still needs, so everything is left in place, and the estate ends the night less secure than it started.
Keep a single rollback ledger from the first change: each temporary item, why it exists, what depends on it, and the exact step that removes it in both the success and the rollback path. Assign the ledger to one person whose only job in the window is that list. If an item is not in the ledger, it does not get created during the window.
5. Decide the rollback triggers in advance, in numbers
In the middle of a failing cutover, every signal looks ambiguous. Error rates are up, but perhaps they are settling. Latency is worse, but perhaps the caches are cold. Without pre agreed triggers, the rollback decision becomes a debate held at the worst possible time, and teams press on past the point where returning was cheap.
Set triggers while everyone is calm: for example, a defined error rate sustained for a defined number of minutes, a data replication lag above a set threshold, or a failure of a named critical transaction tested from a named location. Also set a latest decision time. If the cutover has not reached a named milestone by that time, rollback starts automatically, because the remaining window is too short to finish and still leave room to return.
Writing the triggers down also protects the person who calls the rollback. Returning on a pre agreed trigger is following the plan, not giving up.
6. Rehearse the return, not just the arrival
Game days for migrations usually rehearse the forward path. Add a rehearsal where the team stops halfway and comes back. That exercise finds the missing pieces quickly: the old side certificate that expired during the project, the route that was already withdrawn in preparation, the dashboard that only shows the new path, the access that was moved and not duplicated. Each of those is a small fix in rehearsal and a long delay at 2 a.m.
A rollback that has been practised once is a procedure. A rollback that exists only as a paragraph is a hope.
Teams that design private multi-cloud connectivity as a managed estate, rather than as a set of one off cutover fixes, work through patterns like these as part of the platform itself. That is the approach taken by CloudVerg, where VergMesh handles multi-cloud networking and VergRail and VergShield cover the connectivity and zero trust side, so the return path is planned with the same care as the arrival.
