Staging and Rollback Workflow, Vortex IQ Documentation

Every change a merchant makes to a live storefront is a small bet. The change is intended to improve something: a theme refresh for a seasonal campaign, an app install for a new payment method, a config tweak for a checkout step, a bulk catalogue edit before a launch. Most of those bets pay off. Some do not. The merchant either preserved the option to revert the change (so a bad bet costs minutes), or the merchant did not (so a bad bet can cost a day of trading, the integrity of the catalogue, or the trust of the customer base). The staging and rollback workflow is the canonical safety pattern that turns every change into a reversible bet. It runs five steps: stage, preview, deploy, back up, and roll back if needed. The pattern is platform-agnostic conceptually but platform-specific in implementation. BigCommerce merchants use StagingPro plus RollbackPro. Shopify merchants use Vortex Staging plus Vortex Backup. Adobe Commerce merchants use DryRunPro which combines staging and snapshot rollback in one app. The five-step workflow is the same on all three platforms. This page is the conceptual reference for the workflow. It explains what each step is for, what happens when one step is skipped, why the pattern works, and how the per-platform apps map to the conceptual steps. For the per-app UI walkthrough, see the individual StagingPro, Vortex Staging, and DryRunPro pages.

​

Why staging and rollback are non-negotiable

Native ecommerce platforms ship with a “publish” button and not much else. Shopify, BigCommerce, and Adobe Commerce each have a notion of theme preview, but none of them ships a true production-mirror staging environment that includes apps, settings, and data. None of them ships a continuous backup with point-in-time rollback. This is not a feature gap that a merchant can ignore: the cost of one botched theme deploy or one corrupted bulk edit can wipe out a quarter of operational savings the merchant achieved through other tools. The two failures the workflow protects against: Pre-deploy failure: the change is wrong. The merchant deploys directly to production, the change has a bug, customers see broken pages or checkout failures. Time to detect: minutes. Time to revert: until the merchant figures out what changed and reverses it manually, often hours. Post-deploy failure: the change interacts badly with production. The change passed testing in isolation, but on real production traffic it interacts with another app, a real customer behaviour, or an edge case the merchant did not anticipate. Time to detect: hours to days. Time to revert: until the merchant reconstructs the pre-change state from memory, often a full re-keying of settings and data. Staging addresses the pre-deploy failure: the change is tested before customers see it. Rollback addresses the post-deploy failure: the change can be reverted to a known-good snapshot without manual reconstruction. Together they form the temporal safety net that lets a merchant make changes confidently.

​

The five-step workflow

The workflow runs in order. Each step has a specific purpose. Skipping a step compromises the safety net. In practice, step 4 (back up) runs automatically if a continuous backup app is installed. Most workspaces never explicitly trigger step 4; they trust that a fresh snapshot exists and only verify on the rare occasion when the rollback is needed.

​

Step 1, stage

Staging is the production-mirror environment where the change is applied first. The defining property of a true staging environment is that it includes everything: theme, apps, settings, data. A theme-only preview is not a staging environment because it does not catch app or settings interactions. A demo store is not a staging environment because it does not have the production data that the change interacts with. The three apps map staging to platform mechanics differently. StagingPro on BigCommerce. Spins up a separate BigCommerce store as the staging environment. Mirrors theme, apps, settings, and data from the live store. Apps install on staging from the BigCommerce app store. Theme is cloned. Settings are mirrored. Data is replicated. Vortex Staging on Shopify. Uses Shopify’s theme preview surface plus a parallel app sandbox for the staging environment. Theme changes preview cleanly via Shopify’s native preview. Apps and settings preview via the Vortex Staging app sandbox. Data mirrors from the live store. DryRunPro on Adobe Commerce. Uses Adobe Commerce Cloud’s environment-per-branch model to spin up an on-demand staging environment per feature branch. Each environment is a full Adobe Commerce stack: code, config, data. Multi-environment, multi-team support is first-class because Adobe Commerce engineering teams typically have many in-flight branches at once. In all three cases, the staging environment is short-lived by default. Spin up, test, deploy, tear down. Some workspaces keep a long-lived staging environment for more complex change pipelines.

​

Step 2, preview

Preview is where the merchant or the team validates that the change does what was intended. The preview surface combines visual inspection, customer journey simulation, and KPI sampling on the staged environment. Visual review. The merchant or designer walks the staged storefront and looks for visual regressions, broken layouts, missing assets, font issues, mobile responsiveness problems. Customer journey test. The Customer Journey Test action runs Ask Viq through end-to-end flows on the staged environment. Add to cart, checkout, payment, confirmation. Friction points report as findings. KPI sampling on staging. Nerve Centre cards can be configured to sample from the staging environment. Compare staged checkout-conversion KPIs to production. Compare staged site speed (Core Web Vitals) to production. Audit on staging. Run Full Store Audit can target the staging environment. Findings on staging predict findings on production after the deploy. Stakeholder review. Share the staging URL with stakeholders for sign-off. The link is short-lived and authentication-gated. The preview step is the highest-value step in the workflow because it catches the largest class of pre-deploy failures. A change that passes preview review usually deploys successfully.

​

Step 3, deploy

Deploy is the promotion of the staged change to the production environment. The mechanics are platform-specific. StagingPro deploy copies theme, apps, settings, and (optionally) data deltas from the staging store to the production store. Selective promotion is supported: deploy only theme, only settings, only specific changes. Vortex Staging deploy publishes the staged Shopify theme and applies the staged settings deltas. Apps are not promoted automatically because Shopify apps are workspace-scoped; the merchant installs the app on production explicitly. DryRunPro deploy merges the feature branch into the production branch on Adobe Commerce Cloud, triggering the standard Adobe Commerce deploy pipeline. Configuration deltas apply via Adobe Commerce’s standard config-deploy mechanism. The deploy step itself is fast (seconds to minutes). The earlier steps (stage and preview) are what make the deploy a smart bet.

​

Step 4, back up

Back up is the step that creates the post-deploy safety net. A continuous backup app is the typical implementation: it captures a production snapshot continuously (every few minutes for high-velocity stores, every few hours for steady-state stores), maintains a version history, and exposes one-click restore. The three apps map backup to platform mechanics differently. RollbackPro on BigCommerce. Continuous backup of the BigCommerce production store with point-in-time rollback. Snapshots cover theme, apps, settings, and catalogue data. Vortex Backup on Shopify. Continuous backup of the Shopify production store with full-store rollback. Snapshots cover theme, apps, settings, products, collections, content pages, and metafields. DryRunPro on Adobe Commerce. Snapshot rollback is built into the staging environment workflow. Each deploy produces a snapshot; rolling back is reverting to a previous snapshot. The defining property of the backup step is that it runs without merchant intervention. The merchant does not have to remember to take a snapshot before deploy; the continuous backup app already has a fresh snapshot. The merchant verifies on the rollback path, not on the happy path.

​

Step 5, roll back if needed

Roll back is the step that closes the loop on a post-deploy failure. Most deploys do not need this step. When it is needed, it is needed urgently. The rollback path on each app: RollbackPro. One-click revert to the last known-good snapshot. Or point-in-time rollback to a specific timestamp. Theme, apps, settings, and catalogue data restore. Time to revert: 2 to 5 minutes for typical stores. Vortex Backup. Full-store rollback or scoped rollback (theme only, products only, content pages only). Point-in-time selector with a calendar picker. Time to revert: 3 to 8 minutes for typical stores. DryRunPro. Revert to the previous snapshot via the Adobe Commerce Cloud environment management surface. Time to revert: 5 to 15 minutes depending on environment size. The rollback step writes a record to Vortex Memory with the rollback target, the rollback reason, and the period covered. Future audits can correlate rollback frequency to deploy quality and surface trends in the workspace’s deploy hygiene.

​

Mapping apps to steps

The pattern across all three platforms: The BigCommerce and Shopify patterns are two-app: one app for staging, one app for backup and rollback. The Adobe Commerce pattern is one-app: DryRunPro covers all five steps because Adobe Commerce Cloud’s environment model lends itself to a combined product. Functionally the patterns are equivalent.

​

Common variations

Three workflow variations appear in different merchant contexts. Skip staging for very-low-risk changes. A meta-description regeneration on 50 products via Bulk Content Edit is reversible (the previous values are in the snapshot) and low risk. Some workspaces skip the staging step for changes the recipe declares low_friction reversibility and low risk_tier, going straight to deploy with backup. This is supported by the auto-apply path in Automation rules model. Long-lived staging environments. Some workspaces maintain a permanent staging environment for stakeholder previews of in-flight work. The staging environment refreshes from production weekly or on-demand. Theme-team workflows often run this way. Multi-step deploy for large changes. A theme migration to a new framework runs through staging, then a beta production environment with reduced traffic (gradual rollout), then full production. Each step has its own backup and rollback path.

​

Where it surfaces

The workflow is visible across five surfaces.

• Each app’s main page. StagingPro, RollbackPro, Vortex Staging, Vortex Backup, DryRunPro.
• When to use which Vortex App. The decision guide that points merchants at the right app for their platform.
• Multi-app workflows. The pairing patterns that combine staging and backup.
• Actions Kanban Board. Cards for theme, app, and settings changes typically reference a staging environment URL.
• Vortex Memory. The deploy and rollback history archive.

​

How it relates to other modules

The workflow is the safety net for any operation that modifies the live store. Actions recipes that target storefront changes (theme code, app config, settings) typically require a staging step in the recipe definition. Vortex Mind findings that surface deploy regressions or rollback opportunities feed cards into Actions for resolution. Nerve Centre KPIs are sampled on staging for pre-deploy validation. Vortex Memory records every deploy and rollback for retroactive analysis.

​

FAQ

Do I need both a staging app and a backup app? For most merchants, yes. Staging catches pre-deploy failures. Backup catches post-deploy failures. They cover different failure modes. A change can pass staging review and still cause a problem in production (interaction with traffic, real customer behaviour, edge data) that only the backup tool can fix. The Adobe Commerce DryRunPro is the exception because it combines both into one app. Can I use a generic backup tool instead of RollbackPro or Vortex Backup? You can use a generic platform export tool (Shopify CSV export, BigCommerce export) but the recovery experience is much worse. Generic exports do not capture theme, app, or settings state, so a rollback from a generic export only restores data, not the storefront configuration. RollbackPro and Vortex Backup capture the full storefront state. How long does a snapshot retain history? Default retention is 30 days for most snapshots, with longer retention for explicitly-tagged snapshots (pre-launch, pre-Black-Friday). Workspaces can extend retention up to 365 days. Each app’s settings page covers the retention model in detail. Does the workflow work for multi-storefront setups (multi-region, multi-brand)? Yes. Each storefront is treated as a separate environment for staging and backup purposes. The merchant configures one staging-and-rollback workflow per storefront. Multi-storefront workspaces typically run the workflow per storefront and use Automation rules model to coordinate releases across storefronts. What is the cost of a rollback (in lost data)? The rollback restores to the snapshot timestamp, so any changes made between the snapshot and the rollback are lost. Continuous-backup apps capture snapshots frequently (every 5 to 15 minutes for active stores), so the loss is typically minutes of new orders or customer accounts. The lost data appears in the rollback report so the merchant can manually re-key critical entries. Does the workflow handle changes I made through Shopify or BigCommerce admin directly (outside Vortex IQ)? Yes. The continuous backup runs against the production storefront, regardless of how a change was introduced. A merchant who edits a product directly in Shopify admin will find that product captured in the next Vortex Backup snapshot, and a rollback can revert that change. Can I selectively roll back only theme changes without rolling back data? Yes on RollbackPro and Vortex Backup, both of which support scoped rollback by entity type (theme only, products only, content pages only). DryRunPro snapshots are environment-scoped so partial rollback works at the environment level rather than the entity level.

​

Cross-links

• Concept: When to use which Vortex App
• Concept: Multi-app workflows
• Concept: Comparison matrix
• Concept: Multi-tenancy and team models
• App: StagingPro
• App: RollbackPro
• App: Vortex Staging
• App: Vortex Backup
• App: DryRunPro
• Module: Actions
• Concept: The Action Loop
• Concept: Automation rules model
• Module: Vortex Mind
• Module: Vortex Memory
• Module: Nerve Centre