Quick answer
A selective rollback reverses the specific change causing a problem while preserving unrelated current work. It can reduce recovery risk when a full site or database restore would remove newer activity.
Before you begin
Identify the last known working version and the exact files, settings, or records changed. Keep a copy of the current state before attempting recovery.
What to do
- Compare the failure with the release record. Determine whether the issue began after a theme edit, plugin update, configuration change, or data migration.
- List dependencies. A changed template may rely on a new setting, while an update may have modified database structures that older code cannot read.
- Select the smallest coherent recovery unit. Do not restore one file from an incompatible version simply because its filename matches.
- Prepare explicit recovery steps and acceptance checks. Include a way to stop and escalate if the result differs from expectations.
- Apply the approved rollback and verify the affected journey plus nearby functions. Preserve unrelated content, orders, and configuration changes.
How to check the result
The original symptom should be resolved without creating a version mismatch or losing newer work. Record what was reversed, what remains, and which backup or commit supplied the recovery material.
If you need help
If the change includes database migrations or several dependent services, a small rollback may not be safe. Ask for a coordinated recovery plan and provide the release identifiers, timestamps, and observed failure rather than repeatedly restoring different combinations.
Related help
- Create a recoverable checkpoint before an AI website deployment
- Preserve new orders and inquiries when planning a restore
- Update a WordPress plugin with a clear rollback plan
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
