Shopify Staging Environment: The Complete Guide for 2026
Quick answer: Shopify has no built-in staging environment. For a theme-only change, a duplicate theme and a preview link are enough. For anything that touches products, metafields, collections, navigation or apps, you need a second Shopify store holding a copy of your live data, filled by hand or by a staging app, and a release step that moves tested changes to live with an undo point ready.
Most broken Shopify stores were not broken by a bad idea. They were broken by a good change made straight on the live store: an app install that clashed with another app, a theme update that moved a block, a bulk edit with one wrong column. This guide covers the practical ways to test first, what each one copies, and how to move a tested change to production without surprises.
Does Shopify have a staging environment?
Quick answer: no, on any plan, Shopify Plus included. Shopify gives you four building blocks instead: development stores, theme duplication, theme preview links and CSV export. Each covers part of the job. Development stores start empty, and theme duplication and preview only cover the theme, so apps, product data, metafields, navigation, discounts and checkout stay live while you test.
| Native option | What it covers | Where it stops |
|---|---|---|
| Development store | A free, empty store to build in, created through Shopify Partners | It is not a copy of your live store, and there is no supported way to push it back into production |
| Theme duplication | A second copy of your theme to edit without touching the published one | Theme layer only; apps, product data, metafields, navigation, discounts and checkout are still live |
| Theme preview link | A shareable URL to review an unpublished theme against real store data | Previewing is not testing; data edits made to make the preview meaningful change the live store too |
| CSV export and import | Moving some product and customer records between stores by hand | It carries records, not a store; navigation, theme settings, app configuration and the links between records do not come with it |
Is a duplicate theme or a development store good enough for testing?
Quick answer: a duplicate theme is good enough for layout, CSS and section changes, because it runs against your real data. A development store is good enough for building a new theme or app from scratch. Neither is good enough for testing a change to products, metafields, collections, apps or settings, because the duplicate theme shares your live data and the development store has none of it.
| Option | Runs against | Good enough for | Not good enough for |
|---|---|---|---|
| Duplicate theme and preview | Your live data | Layout, CSS, sections, copy in the theme | Data edits, app installs, checkout and settings changes |
| Development store or Plus sandbox store | Empty or sample data | Building a theme or app from scratch | Anything that depends on your real catalogue, metafields or app setup |
| Development store filled by hand | A one-off copy, out of date the moment live changes | Occasional larger tests if you have the hours | Repeated testing; every refill is a manual step that can go wrong |
| Staging app | A synced copy of your live data in a second store | Data changes, app trials, redesigns and seasonal launches | Proving that live will behave the same after release; check after every deploy |
What does a Shopify staging app copy?
Quick answer: it depends on the app, so check the documentation field by field before you rely on it. The common gaps are inventory, metafields outside products, smart collection rules and customers. Also check which direction the sync runs: a one-way copy is fine for testing, but work done in staging then has to be repeated on live by hand.
| What gets copied | Vortex Staging | Rewind Staging |
|---|---|---|
| Core product fields, images and SEO fields | Yes | Core fields yes; SEO fields not documented |
| Inventory, per location | Yes | No ("We do NOT copy Product Inventory") |
| Product and variant metafields | Yes | Product metafields only |
| Page metafields and metafield definitions | Yes | No |
| Metaobjects | Yes | Yes |
| Smart collections | The rule set, so collections rebuild | Products only if manually sorted |
| Pages, blogs, themes and redirects | Yes | Yes |
| Customers | On request, with an anonymised mode | No |
| Direction of sync | Both ways: live to staging and staging back to live | One way, live to staging |
| Check that the copy is correct | Field-by-field comparison after each run | Not documented |
Apps are installed per store, so expect to install and set up each app on the staging store and check how it behaves there. App and checkout coverage depends on the app and the workflow. The full 30-row comparison, with Rewind's sources, is on Vortex Staging vs Rewind Staging.
How do you set up a Shopify staging environment?
Quick answer: create a second Shopify store to act as staging (a development store from Shopify Partners, or a sandbox store on Plus), copy your live data into it, install the apps you use, and sync it again before each test session. A staging app does the copy and the sync for you; by hand, budget a few hours per refill.
With a staging app:
- Create the staging store: a free development store through Shopify Partners, or a sandbox store in your Plus organisation.
- Install the staging app on your live store and connect the staging store.
- Run the first copy, then check the result: product counts, a few metafields, collections, navigation and redirects.
- Install and set up the apps you want to test on the staging store.
- Sync again before each test session, so staging matches what customers see today.
By hand:
- Create a development store through Shopify Partners.
- Export products and customers from the live admin as CSV and import them, or use a bulk tool such as Matrixify.
- Download the live theme and upload it to the development store.
- Recreate navigation, redirects and the settings your test depends on.
- Install the apps you need and set each one up again.
The manual route is free but stale the moment live changes, and it carries records rather than relationships, so test results can mislead. It suits an occasional large test, not a weekly release.
How do you move changes from staging to production on Shopify?
Quick answer: treat a release as three separate lanes. Theme code goes through Git or the Shopify CLI. Store data goes back through a staging app that syncs both ways, or through a reviewed import of only the changed records. Apps and settings are changed by hand on live from a written checklist. Take a restore point first, release at a quiet hour and check live afterwards.
Theme code
Connect the live theme and the staging theme to branches with Shopify's GitHub integration, or use the Shopify CLI (shopify theme pull, shopify theme push, shopify theme dev). The trap is drift: the GitHub integration commits theme editor changes back to the branch, so a merchandiser editing the live theme while a developer works in staging creates a conflict in the JSON templates and settings_data.json. Pull before you push, and review the diff of those files every time.
Store data
Products, collections, metafields and pages edited in staging need a route back. A staging app that syncs both ways can push only the reviewed changes. Without one, export only the changed records and import them with a tool that shows you the rows first. Never re-import the whole catalogue to move ten edits.
Apps and settings
Apps, payment and shipping settings, markets and most store settings do not travel between stores. Write down every change you made in staging as a checklist, make the same changes on live by hand, and have a second person tick the list.
Release and undo
Before release, take a restore point or a backup you have tested. Release at your quietest hour, keep the previous theme unpublished as the fallback (republishing it is the theme-level undo), and check the pages that earn money straight after: home, a collection, a product, the cart and checkout. Vortex IQ's approach is the same in every crew: It proposes. Your team approves. Nothing goes live without your say-so.
How do Shopify Plus brands preview a redesign or Black Friday changes?
Quick answer: Plus does not add a staging environment, but it gives you more room to build one: sandbox stores for a synced copy, preview links for the redesign, and scheduled discounts and product publishing for the launch itself. Freeze other changes in the run-up, rehearse the launch on staging, and keep the old theme ready to republish.
- Six weeks out: build the redesign or campaign theme as a duplicate theme, and the data changes (new collections, metafields, landing pages) on a synced staging store.
- Four weeks out: share preview links for sign-off and test the full journey on staging, including discounts, bundles and the apps that change price or cart.
- Two weeks out: freeze unrelated changes. Schedule discounts with start and end dates, and schedule product publishing to the Online Store where you can.
- Launch: publish the theme at a quiet hour, push the reviewed data changes, then check the pages that earn money.
- After: keep the previous theme unpublished until the peak has passed, and record what changed in case you need to undo it.
What should you test in a Shopify staging environment?
Quick answer: test whatever the change touches, then the paths that make money, whatever the change was: home, collection, product, cart and checkout, on mobile and desktop. A theme change can break an app block; an app install can slow every page.
- Theme: templates and sections you changed, product and variant display, collection filtering, cart and mini-cart, page speed before and after.
- Apps: a new app with your existing apps switched on, an app update, and an app removal (look for leftover code).
- Checkout: discount codes, shipping rates, tax by region, payment in test mode, post-purchase offers, confirmation emails.
- Content and SEO: new URLs, redirects, meta titles and descriptions, structured data.
- Tracking and integrations: GA4 and ad pixels, email platform sync, inventory and ERP connections.
How much does a Shopify staging environment cost?
Quick answer: the native routes are free but cost time; a staging app costs from nothing to about $100 a month for regular use. The bigger cost is a broken release in a busy week, so price the option against how often you change the store, not against zero.
| Route | Price | Time and limits |
|---|---|---|
| Duplicate theme and preview | Free | Minutes; theme changes only |
| Development store or Plus sandbox store | Free | Starts empty |
| Development store filled by hand | Free | A few hours per refill; out of date at once |
| Vortex Staging | Free plan with one full store copy a month; Staging plan $99 a month for up to three, with a 15-day free trial; usage charges apply | Minutes per sync; both directions |
| Rewind Staging | See Rewind's pricing page | One-way sync; up to 100,000 products |
Vortex Staging is also included in Vortex IQ plans on the website, from Foundation at $499 a month. See Vortex IQ pricing.
Common Shopify staging mistakes
Quick answer: the usual mistakes are testing on a stale copy, testing without your other apps switched on, forgetting the changes that do not travel (apps and settings), and releasing without an undo ready. Each one makes a passed test mean less than it looks.
- Testing on live because it is "just a small change". Small changes break checkouts too.
- A stale staging copy. Sync before each test session, not once a quarter.
- Testing an app on its own. Conflicts appear when your other apps are running too.
- Forgetting the manual lane. Apps and settings changed in staging have to be changed on live by hand.
- No undo plan. Take a restore point before release and keep the previous theme ready to republish.
Shopify staging for agencies and teams
Quick answer: staging is where client approval belongs. Share a preview link or the staging store for sign-off, keep a record of who approved what, and release only what was approved. With several developers, give each change its own branch and theme so work does not collide.
A simple release path for agencies: build, stage, client review, approve, release, check. Vortex Staging supports shared staging access, deployment history and change tracking, so everyone can see what is about to go live and what shipped.
Frequently asked questions
Does Shopify have a built-in staging environment?
No. No Shopify plan includes a staging environment, Plus included. You can preview unpublished themes and create development stores, but neither tests a change against a copy of your live data.
Can I use a Shopify development store as a staging site?
Yes, if you fill it with a copy of your live data and keep that copy current. Empty, it is a place to build, not to test. A staging app can do the copying and syncing for you.
What is the difference between a staging environment and theme preview?
Theme preview shows an unpublished theme against your live data, so it tests layout only. A staging environment is a separate store holding a copy of your data, where you can change products, metafields, collections and apps without touching live.
Will changes in my staging store affect my live store?
No. A staging store is a separate Shopify store, so nothing changes on live until you deploy. The exception is a duplicate theme in your live store: it shares live data, so data edits made while previewing are live.
How often should I sync my staging environment?
Before each test session. If live changes daily, sync on each day you test, because a test on old data can pass and still fail on live.
Is Rewind a staging tool or a backup tool?
Both, as separate apps: Rewind Backups restores data after something goes wrong, and Rewind Staging creates a one-way copy for testing. A backup helps after a mistake; staging helps you avoid it. Most stores that change often need both.
Does Shopify Plus include a staging environment?
No. Plus gives you more development and sandbox stores, but they start empty, and there is no supported way to push one back into production. Plus stores usually run more apps and customisation, so untested changes have more to break.
