Rollback

Rollback reverts every change a deployed release made, restoring each entity to its state just before the deploy. Whether something went wrong or a promotion has ended, it's a clean way to undo a release.

How rollback works

When a release deploys, MageDrop captures a rollback snapshot: the current value of every field that's about to change. The snapshot is taken at deploy time, not when the change was staged.

When you roll back, MageDrop:

1. Reads the rollback snapshot for every entity in the release.
2. Applies the snapshot values through the MageDrop module on your store, one call per entity and store view. Where a field had no store-view override before the deploy, the override is removed again rather than replaced with a copy of the default.
3. Marks the release Rolled back.

Why deploy time, not staging time?

Consider this scenario:

1. On Monday, you stage a CMS page title change from "Welcome" to "Summer Sale".
2. On Wednesday, someone changes the title to "Spring Collection" in the Magento admin.
3. On Friday, the release deploys. MageDrop captures "Spring Collection" as the current value.
4. If you roll back, the title returns to "Spring Collection" (the deploy-time value), not "Welcome" (the staging-time value).

Rollback restores the actual state of the store immediately before the release went live, including any changes made in the meantime.

Rolling back by hand

1. In the MageDrop dashboard, open the release. It must be Live, or Failed with changes still applied.
2. Click Rollback and confirm.
3. MageDrop restores every entity to its pre-deploy values and marks the release Rolled back.

Automatic rollback

If the release has a Roll back at time, the rollback happens on its own:

• MageDrop checks every minute for live releases whose rollback time has passed.
• When it arrives, the rollback runs exactly as a manual one would.
• No one needs to be at a keyboard.

See Scheduling releases to set it up.

What gets rolled back

Rollback restores every field the release changed. If a release changed the title and content of a CMS page, both are restored. Fields that weren't part of the release are not touched.

Changes made after the deploy

What if someone edits an entity after the release deployed, and you then roll back?

1. The release changes a CMS page's title from "Spring Collection" to "Summer Sale".
2. After the deploy, someone changes the page's meta description in the Magento admin.
3. You roll back the release.
4. The title goes back to "Spring Collection", because the release changed it.
5. The meta description keeps the manual edit, because the release didn't change it.

Rollback only touches fields that were part of the release. But if someone changed one of those fields after the deploy, the rollback overwrites their edit with the snapshot value.

If a rollback fails

• The release is marked Failed.
• The activity log shows which entity failed and why.
• Entities that were already rolled back stay rolled back.
• Fix the underlying issue (often a network or permission problem) and click Rollback again to finish the job.

An automatic rollback that fails because the store couldn't be reached stays Live and is retried on the store's retry schedule, carrying on from where it stopped. See Automatic retries.

Deploying again

A rolled-back release keeps its staged changes. Click Redeploy to push the same changes live again; MageDrop takes a fresh rollback snapshot first, so you can roll back again afterwards.

Best practices

• Set a rollback time for promotions. If you know when a promotion ends, set it when you schedule, so nobody has to remember.
• Review before rolling back. The release page shows exactly which fields will be reverted.
• Check the timeline afterwards to confirm every entity was restored.
• Rollback isn't an undo for everything. It restores deploy-time values. If a lot has changed by hand since, review the current state first, or restore single entities from revisions instead.