A database schema migration has converted production tables to a new format, and the old format cannot be restored without losing transactions entered since go-live. A defect appears shortly after the change. Which approach is the team MOST likely to take?
Select an answer to reveal the explanation.
Short Explanation
Sometimes you can't put the toothpaste back in the tube. When rolling back would wipe out real transactions, you push ahead and fix it in place. That's fail forward, and the trap is reaching for the backup out of habit.
Full Explanation
Fail forward means resolving a problem by moving ahead with a corrective fix rather than reverting to the previous state. It is chosen when rollback is impractical or more harmful than the defect, as with a schema migration that has already accepted new transactions in the new format. Developing, testing, and deploying a targeted fix preserves data while correcting the defect, ideally through an expedited change process. Restoring last night's backup would revert the schema but discard every transaction entered since the migration, causing data loss that is usually worse than the defect being fixed. Closing the change as successful and accepting the defect ignores a known problem in production, bypasses risk owner decisions, and misrepresents the change outcome. Reverting only the application code while keeping the new schema would create a mismatch between code and data structures, likely breaking the application further. Exam caveat: backout planning and fail forward are both change management concepts; backout returns to the prior state, while fail forward is a deliberate decision when the prior state cannot be safely restored. Operational check: document the fail forward decision in the change record, run the fix through accelerated testing, verify transaction integrity after deployment, and review why the original change lacked a viable rollback path.