Restore or fix forward: deciding during a Shopify sale
Last updated 29 August 2026
When something breaks mid-sale, restoring is not automatically the right move. Roll back when the damage is wide, mechanical and priced in money per minute - wrong prices, flattened variants, deleted records. Fix forward when the data keeps moving while you work, which is stock levels, orders and anything a customer has already paid for. StoreVault is a versioned backup app for Shopify, so this page is written by people with an obvious interest in the word “restore”: that is exactly why half the rows below say fix forward instead.
The incident this page is written for
Three days before Black Friday 2025 a merchant posted that a discount change meant for a duplicate theme “somehow affected my current published theme” - hit the live storefront, and that on some items the cart “goes back to the original price” - showed the pre-discount price. This is a merchant’s public account of what happened to them, not Shopify confirming a cause. It is here because the shape is typical: the change was made carefully, on a copy, and the live store was affected anyway - at the worst possible hour of the year.
The decision, by class of damage
| What happened | Call | Why |
|---|---|---|
| Wrong prices are live on many products | Roll back | Every minute is money at the wrong number, and forward-fixing hundreds of prices by hand introduces a second error. Shopify’s own migration runbook treats this exact case as a rollback trigger, not as a live reconciliation task: “Major product categories or pricing are incorrect/missing.” - listed under ROLL BACK |
| Products were deleted | Restore from a backup, or rebuild | There is no forward fix and no native undo: “Deleted products can’t be restored.” - Shopify Help A versioned backup recreates the record from the version before the deletion, under a new product ID because the platform does not reuse the old one. Links, reports and integrations pointing at the old ID do not follow. |
| A CSV import flattened variants | Roll back the affected products only | The mechanism is documented: “a new default variant is created and existing variants are deleted” - Shopify Help Fixing forward means re-entering option values one product at a time and hoping the sale does not need those SKUs meanwhile. Restore the named records instead of the whole catalogue, so nothing else moves. |
| Theme code change broke the storefront | Fix forward if the file is small, roll back the file otherwise | The code editor keeps a per-file history, but know its edges before you rely on it: “It doesn’t restore an entire theme” - not whole-theme, it “can’t recover deleted theme files” - cannot recover deleted files, and “images, CSS, JavaScript, and fonts in the assets folder, don’t have Timeline history.” - assets have no history |
| Checkout is misconfigured | Publish the previous configuration back | This is the one place where the platform gives you a clean two-way switch: “Your active configuration becomes a draft configuration.” - Shopify Help The checkout you replaced is still sitting there as a draft. |
| Stock counts are wrong | Fix forward, then reconcile after the weekend | Stock moves with every order during a sale, so a snapshot from this morning is already historical fiction by the afternoon; writing it back oversells. Correct the counts forward against the physical shelf. Admin shows “only the last 180 days of inventory adjustment history” - 180 days of adjustments, one record at a time, to help you find where it drifted. |
| Orders or customer records look wrong | Fix forward, always | No backup app writes orders back into a store as they were: the financial record, the timeline and the payment state cannot be reconstructed from outside. An app offering to “restore” orders is creating new ones that look similar. Correct the order in the admin, refund or re-issue, and use the archive to know what it used to say. |
Platform behaviour read from Shopify’s own documentation on 29 August 2026.
Three questions that settle most of it
- Is the data still moving? Stock and orders change while you deliberate, so writing yesterday’s values over them creates a second incident. Catalogue fields - titles, descriptions, prices, options, metafields - do not move on their own, which is what makes them safe to roll back.
- How many records? Under a dozen, forward-fixing is usually faster than any tool. Over a hundred, hand-editing during a sale is how the second error gets in.
- Do you know the previous value? If nothing outside the store kept a copy, the question answers itself and the only path is forward. This is the part that is decided weeks earlier - see what to freeze before BFCM.
If you do roll back, what a good restore looks like
A restore that helps during a sale has four properties, and it is fair to demand all four from any vendor, us included: it shows a plan before it writes anything; it writes record by record so you can restore the eleven products that broke rather than the whole catalogue; it can be undone; and it has been proved to open, not just to store.
We publish the proof rather than the adjective. A live store of ours is damaged on purpose - products deleted, fields overwritten, collections removed - restored, and every public claim is checked against what the store actually returned, field by field. The report, including the parts that came back and the parts that by design did not, is the restore drill report.
Boundaries that apply whichever vendor you pick: deleted records come back under a new ID, media files are not re-attached, and manual collection membership is not written back. The full list is on what backup apps can and cannot restore, and the vendors are compared on the backup app guide.
A backup app covers you from the day it is installed, not from the day you need it. That is true of all of them, ours included.
StoreVault on the Shopify App Store - versioned backups of products, collections, content and themes, plus inventory levels on paid plans, with a plan shown before any restore writes.