Change Management Rollback: What to Do After a Failed Change Implementation

Quick Answer

Executing the rollback plan and then scheduling a post-implementation review is the correct response because the rollback plan was already built into the original change request and approved by the CAB as part of that same package; it's a pre-authorized contingency, not a new action that requires fresh approval before it can be used. When unforeseen performance issues appear after implementation, the priority is restoring service stability as quickly as possible, and executing a plan that's already been reviewed and approved is the fastest safe path to that outcome, since re-submitting a new change request for the rollback itself would introduce delay while the problem is actively affecting the system. Once stability is restored, scheduling a post-implementation review captures what went wrong, why the pre-implementation testing didn't catch the issue, and what should change about the process going forward, closing the loop and feeding lessons learned back into future change planning, which is a core part of ITIL-aligned change management. Treating rollback as something that needs a brand-new approval cycle would misunderstand how contingency planning works within change management: the contingency is decided in advance precisely so it can be executed without delay when needed. When a question describes a failed change with a pre-approved rollback plan, look for the answer that executes that plan immediately and follows up with a review, rather than one that seeks new approval first.