Most auth migrations ship with a rollback plan that exists as a paragraph in a runbook. On paper it is clear: flip the feature flag, point DNS back, restore the previous session store, tell support what to say. In practice that paragraph is rarely exercised under load, with real users, while the new path is already partially live. Rollback day is the rehearsal that closes that gap before the cutover you hope never needs reversing.
I treat rollback as a product behavior, not a recovery note. When you change how people sign in, you are changing the path that keeps every other product behavior reachable. A half-finished cutover that cannot reverse cleanly leaves accounts in mixed states, sessions that validate on one stack and fail on another, and a support queue that cannot tell which world a ticket belongs to. The rehearsal exists to find those seams while you still control the clock.
What you are actually rehearsing
A useful rollback day is not a tabletop. It is a controlled cut that you reverse on purpose. You pick a cohort, move them onto the new auth path for a short window, then pull them back through the documented rollback path and measure what breaks. The goal is not to prove the new stack works. The goal is to prove that the old stack can still accept people who briefly lived on the new one.
That distinction matters. Forward migration usually gets the engineering attention. Reverse migration inherits assumptions that rarely hold. Session cookies written by the new issuer may not parse on the old one. Password hashes, passkey credentials, or MFA enrollments created during the window may not exist in the legacy store. Email verification tokens may point at endpoints you already decommissioned in staging. None of that shows up if you only practice the forward path.
I start by writing down the state that must remain valid after a reverse. Active sessions. Refresh tokens. Device trust. Pending invites. Password reset links already in flight. Magic links still in someone's inbox. SSO assertions that arrived mid-flip. Then I ask which of those the rollback path actually restores, invalidates, or leaves ambiguous. Ambiguous is the expensive answer. Ambiguous is what produces intermittent 401s for two days after you "rolled back successfully."
A cohort small enough to hurt
Pick a cohort that is real enough to stress the seams and small enough that you can still help every person in it by hand if something goes wrong. Internal volunteers are useful for the first pass. A second pass with a thin slice of production traffic is better, because production users do not follow your happy path. They open three tabs. They finish a password reset on a phone while a laptop still holds an old cookie. They click a magic link from yesterday after you have already flipped them twice.
Keep the window short. An hour is often enough to force session renewal, token refresh, and at least one recovery flow. Longer windows feel safer and usually hide timing bugs. You want the rollback to happen while some users still have warm sessions from the new stack and some still have cold ones from the old. That overlap is where most cutover failures live.
During the window, watch four signals more closely than the dashboard green lights: login success rate by cohort, token refresh failures, password reset completion, and support contacts that mention sign-in. Aggregates across the whole site will average away a cohort problem. Slice the metrics the same way you sliced the traffic.
The rollback path has to be boring
The rehearsal only counts if the reverse uses the same controls you would use at 2 a.m. on a Friday. If rollback day relies on a senior engineer SSHing into a box and editing a config by hand, you have practiced heroics, not a procedure. Prefer a single flag, a known DNS record, or a traffic weight you already trust in other releases. Prefer a documented order of operations with owners named, not a group chat that "will figure it out."
Order of operations is where dry runbooks go soft. Turning the flag off before draining new-stack sessions can strand people mid-request. Draining sessions before stopping new credential writes can leave the legacy store missing enrollments that the new stack already accepted. Restoring a database snapshot after users have already changed passwords on the new path is a different kind of damage. Write the sequence as if someone who did not design the system will execute it under stress, because that is who will execute it.
I also rehearse the customer-facing sentence. Support needs one clear statement: what happened, what the user should do next, and whether they need to sign in again. Vague language about "temporary authentication issues" produces duplicate tickets and password reset storms. Precise language reduces both.
State you must decide in advance
Three decisions should be made before rollback day, not during it.
First, credentials created on the new stack during the window. Do they sync back, get discarded, or force a reset on return? Discarding without a reset leaves people locked out with a password that only existed on a stack you just turned off. Syncing without a conflict policy leaves duplicate factors and confusing MFA prompts.
Second, sessions. Invalidate broadly and accept a wave of reauthentication, or attempt to remap. Broad invalidation is ugly and usually safer. Remapping looks elegant until a claim set differs between issuers and a permission check fails in a corner of the app nobody tested.
Third, in-flight recovery messages. Magic links, reset emails, and invite links minted during the window need a known fate. Either they keep working against a stable endpoint, or they fail with a message that tells the user to request a new one. Silent failure is what turns a one-hour rehearsal into a week of distrust.
Write those decisions into the runbook as outcomes, not options. Options invite debate at the worst moment.
What success looks like
A successful rollback day ends with three artifacts you can point to later. A timed log of what you flipped and when. A short list of defects found in reverse, ranked by whether they would have blocked a real cutover. An updated runbook that removes the steps you discovered were fiction.
You should also leave with a clearer definition of "done" for the eventual migration. If reverse migration cannot preserve a particular state, that state becomes a hard prerequisite for the forward cut: migrate it first, or accept that rollback means forcing users through recovery. Teams that skip this conversation usually discover it while customers are already angry.
I do not expect rollback day to feel dramatic. The useful ones feel slightly awkward and slightly slow. Someone notices a cookie domain mismatch. Someone else finds that the old session store rejects a refresh token format introduced two weeks earlier "for the new stack only." Support reads the script aloud and realizes one sentence is wrong. You fix those things while the blast radius is still a cohort with a Slack channel.
The cutover you hope you never reverse still deserves a reverse that has been practiced once under controlled conditions. Auth is the door to the product. If you cannot open the old door again on purpose, you should not close it for good until you can.