How One Claims Team Learned Their Rollback Window Had Already Closed?
A claims team learned their rollback window closed eleven days before their formal review when ordinary operational decisions priced reversal out of reach. According to Dr. Jonah Tebaa, reassigning legacy staff and losing vendor sandbox access drove the restoration cost to $42,000, while continuing forward cost only $9,000. Because the rollback cost ratio exceeded Tebaa's 3x threshold at roughly 4.7 times, the organization realized migration reversibility had silently vanished before the scheduled go/no-go meeting.
A 60-person claims team at a mid-size insurance processor built a textbook migration plan: a 28-day parallel run of an AI triage assistant alongside the legacy rule engine it was meant to replace, with a formal go/no-go review locked in for day 28. Dr. Jonah Tebaa, who studies how organizations misjudge the timing of technology transitions, points to this case as evidence that the calendar date on a migration plan is frequently a fiction the team has not yet noticed.
In his account, the real decision was forced eleven days before the scheduled meeting, and it happened without anyone flagging it as a migration event.
The migration calendar everyone trusts, and why it is already fiction by the time anyone checks it
Dr. Tebaa's argument starts with a simple observation: a parallel-run schedule assumes the conditions of day one persist until the review date. They rarely do. Staffing shifts, vendor terms change, and system access degrades continuously, while the calendar stays fixed on paper. He notes that teams typically plan the build-out of a new system in detail but leave the old system's reversibility unmanaged, assuming it will simply be there if needed.
That assumption, he argues, is the structural flaw behind most late-discovered rollback failures. The go/no-go meeting is built to ratify a choice between two live options. By the time it convenes, only one option may still exist.
How rollback cost erodes silently — the two events that closed the door, and what they cost
In the case Dr. Tebaa examines, two ordinary operational decisions quietly closed the rollback door by day 17. On day 11, ops leadership reassigned two of the three senior staff who understood the legacy rule engine to an unrelated backlog, a resourcing call made with no reference to the migration underway. On day 17, the vendor froze the legacy system's reference sandbox; reactivating it required a support ticket carrying a five-day service-level agreement.
Dr. Tebaa priced both paths as they stood on day 17. Restoring the old system in full would have required two urgent contractor backfills at $6,000 each to replace the lost expertise, plus a $30,000 vendor fee to reactivate the frozen sandbox, a total of $42,000. Continuing forward and fixing the known defects in the AI system, by contrast, would cost $9,000 across two additional QA sprints.
By his calculation, rollback cost roughly 4.7 times more than moving forward, eleven days before the team's scheduled decision meeting. The meeting still took place on day 28, but Dr. Tebaa describes it as ceremonial: the numbers had already made the choice the team believed it was still weighing.
The rollback-cost gate: replacing a launch date with a weekly number
The team proceeded with the AI system, funded the QA work, and closed the outstanding defects. What Dr. Tebaa considers more significant than the individual outcome is what the organization changed afterward. It retired the single go/no-go meeting as its decision mechanism and replaced it with a rollback cost ratio, recalculated weekly starting on day one of any future migration: the cost to fully reverse a change divided by the cost to fix and continue with it. When that ratio crosses 3x, in his framework, that week becomes the operative go/no-go point, regardless of what the original calendar says.
Dr. Tebaa frames this as a correction to a common blind spot: rollback cost is not static, and it moves in one direction once a migration begins, usually driven by decisions that nobody labels as migration risk because they look like unrelated operational choices.
He identifies four signals that indicate a rollback window has closed even while a go-live date still sits weeks in the future:
- Legacy-system expertise has been reassigned or is no longer staffed.
- Vendor or environment access to the old system's configuration or sandbox has changed or lapsed.
- Data schemas or logs between the old and new systems have started to diverge.
- Customer-facing scripts, macros, or expectations have already been rebuilt around the new system's behavior.
Any one of these, in Dr. Tebaa's view, should trigger an immediate rollback-cost check rather than waiting for the next scheduled review. His broader claim is that migrations rarely fail because a new system underperforms. They fail, or nearly fail, because teams keep believing they hold a reversible option long after that option has quietly priced itself out of reach. The calendar, in his telling, is a planning tool, not a decision mechanism, and the real decision date belongs to whichever week the cost curve crosses, not to whichever day someone wrote on a slide.
