A company-store export is not proof that you can recover the store. Before relying on a backup, restore a small, representative part of the program in a controlled environment and prove that products, permissions, employee balances and order history still agree.
The practical buying question is simple: if someone deletes an assortment or overwrites a configuration tomorrow, what can be brought back, by whom, and without repeating an employee’s order? A folder of spreadsheets is useful evidence. A successful recovery drill is evidence that the program can resume.
Publisher perspective: Brand Sauce publishes this operational framework as a company-store provider. It is a suggested acceptance process, not a claim that Brand Sauce or every platform includes a particular backup service. Recovery coverage, assistance, retention and fees need written confirmation.
Define the failure you need to recover from
Start with an ordinary administrative mistake, not an elaborate disaster scenario. A bulk edit assigns the wrong decoration to several garments. A product import removes size options. A departing administrator deletes a collection. These are different from an entire provider becoming unavailable, and they may require different recovery tools.
For the first drill, choose one narrow scenario: restore an accidentally deleted product family with its correct variants, images and ordering restrictions. Then separately test the records that make the store an employee program: who can shop, what they can spend and which orders already reached production.
Write down the target state before touching anything. “The homepage loads” is not enough. A useful result might be: the approved navy polo appears with the right sizes; only the intended employee group can select it; the test allowance is unchanged; and no historical order is sent to the decorator again.
This is recovery inside the existing operating relationship, not a provider switch. For a planned move, use the separate swag-provider migration checklist. A migration can accept a redesigned assortment; a recovery normally needs a trustworthy previously approved state.
Map what the backup actually contains
Ask the provider to complete a coverage map, not merely answer “yes” to backups. Distinguish downloadable records, restorable records and settings that must be recreated. Also distinguish recovery into the same store from duplication into another store; the permissions and supported methods may differ.
| Program layer | Evidence to retain | Recovery acceptance question |
|---|---|---|
| Assortment | Products, variants, identifiers, approved prices and visibility rules | Does the intended item remain orderable by the correct audience? |
| Creative assets | Image files, approved artwork versions and decoration instructions | Are the correct files available, not just references to missing files? |
| Employee eligibility | Current approved membership source and access rules | Are current recipients admitted and former recipients excluded? |
| Funding | Allowance policy and transaction-level balance evidence | Does recovery avoid restoring money already spent? |
| Orders | Order references and production, payment and shipment state | Can support see history without creating new work? |
| Configuration | Shipping rules, approvals, integrations and operating instructions | Does the reconstructed workflow behave as approved? |
Assign an owner and a supported recovery method to every row. Where an outside application holds a record, name that application and its responsible operator. Do not let “the platform backs up the store” stand in for evidence about an independently managed allowance service or decoration workflow.
Use platform documentation to expose export limits
Shopify provides a concrete example of why export and recovery are different. Its official backup and duplication guidance describes CSV exports and a separate theme download. It also says orders cannot be imported through the admin, issued gift cards cannot be transferred, and settings such as shipping and payments need manual configuration when duplicating a store.
Those are documented Shopify duplication constraints, not universal limitations of every backup application or managed provider. They also do not establish what a provider can restore within the same store. Ask for the precise recovery route that applies to your setup, including any app, API work or specialist assistance.
Shopify’s product CSV documentation identifies another practical dependency: product images are imported from URLs. A spreadsheet does not embed those image files. The documentation also distinguishes omitted columns from blank values during overwrite imports and warns about dependencies between variant-related columns.
For your drill, make the operator show which media files remain available and which import settings will be used. Do not casually “clean up” columns in a recovery spreadsheet. Preserve the original export, work on a copy and compare the intended changes before importing anything.
Set two time targets, not one vague promise
Agree how much recent change you could reconstruct and how long the store could remain unavailable. These are separate decisions. A backup taken last night might be quick to restore but omit this morning’s gift redemptions. A complete history might exist while the person authorized to restore it is unavailable.
Use plain language in the agreement: “We need an identifiable recovery point no older than our agreed interval” and “We need this defined service working within our agreed recovery window.” Ask when the clock starts, what counts as restored and which dependencies are excluded. An acknowledgment from support is not the same as resumed ordering.
Illustrative scenario, not measured performance: a store snapshot is taken at 8 a.m.; an accidental change occurs at noon; twelve orders were placed between those times. Restoring the snapshot alone leaves a four-hour reconciliation gap. The twelve orders are not automatically lost, but their actual status must be established from authoritative records before ordering resumes.
A quieter program may tolerate a longer reconstruction interval than a live recognition launch. Choose the interval around the consequences of missing changes, not a generic claim that daily backups are always enough.
Run a controlled six-step recovery drill
- Name the exercise owner and boundary. Record the scenario, start time, target state and person who can stop the exercise. Use a supported isolated environment or another provider-approved nonproduction method. Do not delete real products merely to prove that a backup exists.
- Prevent real-world side effects. Before importing records, have the operator isolate production fulfillment, payments, recipient notifications and live integrations. Use synthetic employee records and approved test payment methods. Confirm the isolation instead of assuming a copied store is harmless.
- Retrieve the actual recovery material. Use the documented access route and an identified backup version. Record timestamps and included components. A successful drill should not depend on the one administrator who happens to have a spreadsheet on a laptop.
- Restore a representative slice. Include a multi-size garment, a product with multiple images, a restricted item and a retired item that should stay unavailable. Include a synthetic employee with a partly used allowance and an order already marked as sent to production.
- Test behavior as well as appearance. Check selection, eligibility, remaining allowance, shipping choices and approval routing. Confirm that restored historical records do not create new charges, new notifications or new production instructions.
- Record the result and close the test. Compare the recovered state with the expected state, list unresolved gaps and assign fixes. Remove or retain test data according to the agreed policy, and verify that isolated connections have not been accidentally enabled.
Time the real work: locating access, retrieving files, obtaining assistance, restoring components and validating results. Report the full elapsed time and the reason for pauses. A fast import followed by hours of manual reconstruction is not a five-minute recovery.
Do not roll back the real world with the storefront
The hardest part of recovery is often deciding what must not be restored to an earlier state. A shirt already decorated cannot be made undecorated by reverting an order record. A payment already refunded cannot safely be treated as captured merely because an older export says so.
For the interval between the recovery point and the interruption, create a reconciliation list. For each affected order, capture its store reference, production reference, current payment state, shipment state and responsible reviewer. Leave unresolved orders on hold rather than guessing.
Apply the same rule to employee eligibility. An old membership snapshot must not silently restore access for someone who has since left the company. Compare recovered access with the current approved roster before reopening. Likewise, reconcile allowance debits, reversals and adjustments; a historical balance is evidence, not automatic authorization for fresh spending.
If you need to repair missing system updates after the store is recovered, use the order-sync recovery guide. That is a separate task from reconstructing deleted store data, but both need a clear rule against duplicate production.
Choose the recovery arrangement by responsibility
| Arrangement | Where it can fit | Tradeoff to resolve |
|---|---|---|
| Documented manual exports | A small, slowly changing program with someone able to rebuild it | More reconstruction work; confirm gaps and recovery frequency. |
| Dedicated backup application | A store needing versioned recovery of supported objects | Coverage, permissions, retention and restore behavior are app-specific. |
| Managed recovery service | A team that wants an accountable operator for the recovery work | Written scope, response window, evidence and charges remain essential. |
None of these labels proves the result. Ask each prospective operator to demonstrate the same scenario and provide the completed coverage map. App subscriptions, additional storage, specialist work and emergency recovery charges are quote-needed. Do not infer that a managed company store includes unlimited recovery assistance.
CISA’s StopRansomware Guide recommends offline, encrypted backups of critical data and regular testing of backup availability and integrity. Have your IT team apply that principle to the actual service architecture. An unrestricted export folder shared with the whole marketing team is not an appropriate place for employee addresses or active redemption information.
Keep production commitments outside the rollback
On-demand production can reduce advance inventory commitments, but it does not eliminate recovery needs. Product-to-decoration mappings and the point at which an order becomes production work still matter.
Bulk programs need reconciliation against physical stock, reservations and shipments that occurred after the snapshot. A hybrid program needs both checks. A shelf count or fulfillment confirmation may be more current than the restored store quantity. Do not overwrite it simply to make two systems agree.
The right recovery plan preserves legitimate commitments under whichever model the program uses. For a fixed event date, verified bulk stock may provide useful continuity while a store is unavailable. For a rolling gift program, temporarily pausing selection may be more sensible than inventing an emergency manual ordering channel.
Keep a one-page acceptance record
Scenario: [what was lost or changed]
Recovery point: [version and timestamp]
Scope: [included objects and known exclusions]
Operator: [owner and backup contact]
Isolation: [payments, messages and fulfillment controlled]
Expected state: [specific product, access, balance and order checks]
Reconciliation gap: [interval and affected records]
Elapsed time: [retrieval through completed validation]
Result: [pass, qualified pass or fail, with corrective actions]
Next drill trigger: [schedule or material system change]
Keep this alongside the company-store pilot acceptance record. Repeat the relevant checks after changing the backup tool, allowance system, fulfillment connection or administrator access model. The evidence should describe today’s operating arrangement.
Frequently asked questions
Does a product export count as a full store backup?
Not by itself. Establish which data and settings it contains, how it can be restored and what remains elsewhere. A product spreadsheet cannot demonstrate that employee eligibility, balances and order state will recover correctly.
Should HR run the restore?
HR should define the employee-facing acceptance criteria and verify them. The authorized technical operator should perform restoration and isolate integrations. Finance and fulfillment should validate the records they own.
Do we need to copy real employee data into a test store?
Use synthetic records for the workflow drill wherever possible. If a specific recovery test genuinely requires production data, involve the responsible privacy and IT owners to define approved access, environment and retention first.
When is the store ready to reopen?
When the agreed product and access checks pass, financial and production gaps are reconciled or explicitly held, and a named owner approves reopening. A page that looks correct is the beginning of verification, not the end.
