Shopify doesn’t have a built-in default staging environment like other platforms. You need to understand how to combine development stores, theme preview links, and a disciplined release process to provide a safe space to test changes and new features without breaking your store.
This guide covers every method available, how to handle data safely, and the release process we use to go live without incident for merchants of all sizes.
Shopify staging tools: what's available?
Shopify offers four staging tools you can use either standalone or in combination, depending on your store's setup and the changes you want to test.
Click any card to expand details
Unpublished Themes
Duplicate your live theme, make changes safely, publish only when ready. The go-to for most day-to-day work.
GitHub Integration
Connect GitHub branches directly to themes. Commits auto-deploy. Built for teams using version control and code review.
Development Stores
A fully separate Shopify store instance for high-risk changes — app testing, checkout customization, and safe contractor access.
Staging Apps
Apps like Rewind Staging and Duplify clone your entire store in a few clicks — products, settings, and app configs included.
Unpublished Themes
Duplicate your live theme, make changes safely, publish only when ready. The go-to for most day-to-day work.
GitHub Integration
Connect GitHub branches directly to themes. Commits auto-deploy. Built for teams using version control and code review.
Development Stores
A fully separate Shopify store instance for high-risk changes — app testing, checkout customization, and safe contractor access.
Staging Apps
Apps like Rewind Staging and Duplify clone your entire store in a few clicks — products, settings, and app configs included.
1. Unpublished themes
Shopify allows you to store multiple unpublished themes in your theme library. Simply duplicate the theme and use it as your staging environment.
Best for: Visual and code changes, layout tweaks, section updates, Liquid edits, and JavaScript modifications. Use this for anything that lives in the theme layer and doesn't touch apps, data, or store configuration.

2. GitHub Integration
Shopify has a native GitHub integration that connects a GitHub branch directly to a theme in your Theme Library. Every time a commit is pushed to that branch, the connected theme updates automatically
Best for: The same changes as an unpublished theme, but with version control. Use this when multiple developers are working on the theme simultaneously, and you need code review, pull requests, and a full commit history before anything goes live.

If your team uses Bitbucket, you don't need to switch to GitHub.
Bitbucket Pipelines gives you the same branch-based deployment workflow. It runs on two permanent branches:
-
develop— merging here auto-deploys to your Shopify staging theme -
master— merging here auto-deploys to the live store
Developers work on feature branches locally, open a pull request 'to develop,' and Pipelines handles the deployment automatically. Once staging is approved, 'develop' merges into 'master' and the live store updates.
The main advantage over the native GitHub integration is control. Pipelines lets you add build steps, run theme linting, and trigger Lighthouse audits in the same workflow, useful for agencies managing multiple stores.
3. Development Stores
Development store is a completely separate Shopify store created through a Partner account. A dev store has its own admin, its own data, and no connection to your live store. This makes it the right environment for changes that go beyond the theme layer.
Best for: High-risk or structural changes, new app installs, checkout customizations, metafield schema changes, or navigation restructuring.
Development stores are empty shells. After creating one, use it as a staging environment by importing the theme, apps, and data from your Shopify store.
Step 1. Export theme and data from your Shopify Store

Step 2. Import theme and data to your Dev Store

Step 3. Reinstall and configure your apps
Always test apps in your dev store before installing them in the live store.
- Open the app configuration document or screenshots you took in Step 1
- Go to the Shopify App Store and reinstall each app one by one
- Configure each app to match your live store settings using your documentation
- Enable test mode in Settings> Payments, so you can simulate transactions
- Place a test order to confirm apps that trigger on purchase are firing correctly
Most apps offer a free trial period or detect development store environments, unlocking full features at no cost.
Different levels of Dev store
Plus, merchants and agencies have access to more advanced features.

The practical difference:
- Standard dev store: free, basic Shopify plan, good for theme and app testing
- Shopify Plus org dev store: created by the merchant through their org admin, tied to their account
- Partner sandbox org: created and owned by the agency, up to 5 Plus stores per Shopify organization, not transferable to a merchant or upgradeable to a paid plan

4. Staging Apps
Staging apps let you get a full replica of your store without much hassle. It’s a valid option for a team that lacks the technical skills, but it adds avoidable costs when a dev is included.
Best for: Teams without a developer who need a full store replica quickly. Use this when the manual export/import process of a dev store isn't realistic for your team, and the monthly cost is worth the time saved.
What staging method works best for you?
The goal is to find a staging method that works based on what you need. Our tool will help you find that.
Fill in the form below and get a quick answer on what to set up next.
How to handle data in a Shopify staging environment?
Most of the work in creating a staging environment in Shopify is handling and transferring the data.
As a rule, transfer only data relevant to the website's functionality. For example, you will need your products to test checkout, but you do not need a history of real customer records; not only are they not useful, but you're risking violating Shopify's GDPR compliance guidelines.
What to export?
- Products: Export titles, descriptions, variants, prices, SKUs, images from Products > Export > All products > CSV
- Theme files: All Liquid, CSS, JS, section configurations from Online Store > Themes > Actions > Download theme file
- Smart collections: Collection rules and conditions. Data included in the products CSV export

What needs special caution?
- Manual collections: Product assignments are lost during CSV exports. Rebuild manually in the dev store or use Matrixify for a full transfer.
- Navigation menus: No native export exists. Screenshot your main and footer menu structure and rebuild manually.
- Metafield values: The schema transfers, but the values populated on individual products don't. Recreate the schema in Settings > Custom data, and use Matrixify if the actual values are critical to your testing.
- Customer records: These contain PII, including names, email addresses, and addresses. Strip all identifying fields before importing anything.
- App configurations: Apps must be reinstalled from scratch; settings don't transfer. Screenshot every app's configuration before you start, so you know exactly what to rebuild.
What not to export?
- Orders: Order history has no staging purpose and contains customer PIIs. Leave it on the live store.
- Full customer records: Moving real PII to a dev store poses GDPR and CCPA risks. Create test accounts manually in the dev store instead.
- Shopify Flow automations: No export tool exists. Recreate them manually in the dev store only if your testing specifically requires them.
- Live API keys: Never reuse production API keys in a staging environment. Generate new ones for the dev store.
How to safely release from your Shopify staging environment?
Moving from the staging environment to the live store is where most incidents happen. To avoid the unexpected, follow the steps below. It’s the standard procedure we apply for all the stores we work with.
Step 1. Establish a fallback safe point
Duplicate your theme and rename it with today's date before touching anything. This is your fallback point. Skipping this step means your only recovery option is memory, trying to manually undo changes on a live store while customers are shopping.
Step 2. Sign off on the changes
Generate a preview link for the unpublished theme where you tested the changes, and send it to whoever is in charge. In our scenario, the Q&A provides final sign-off, and the process Tech Lead is present throughout.
It’s not enough for the site to be loading correctly. Hidden issues usually cause the most turmoil. If you don't have a QA function, the rule is simple: the person approving the change should not be the same person who built it, and must always check the following:
- The site has been tested on mobile (375px) and desktop
- Full checkout completed end-to-end using a test order on both mobile and desktop
- New Liquid sections tested with empty or missing data
- No JavaScript errors in browser DevTools on key pages
- Lighthouse score checked, a drop of more than 10 points warrants investigation

Send a preview to team members before any final release is signed off
Step 3. Publish on a safe day/time
A Friday release that breaks checkout can cost a store its entire weekend revenue before anyone is back online on Monday to fix it. We've seen it happen on changes as minor as a banner update.
Aim to release updates during low-traffic times and days when your team is available, unless you have a Shopify support service team working for you.
How to manage access to your Shopify staging environment?
Giving the wrong people access to the wrong environments is one of the most common causes of accidental changes to live stores. Also, depending on how you're working, in-house dev team or a partner agency, managing access becomes crucial.
Here are some of the best practices we follow in every store we work with.
- Keep live store access separate from dev store access
Your development store should be the default working environment for anyone building or testing. Contractors, new developers, and agency staff should get access to the dev store first, not the live store. They only get live store access when the work is ready to ship, and someone with full context is supervising.
- Use collaborator accounts for external access
Shopify's collaborator account system lets you grant access through the Partner dashboard with specific permission scopes. Unlike staff accounts, collaborator accounts don't count toward your staff account limit and can be revoked cleanly when the engagement ends.

- Set permissions by role, not by person
A developer working on theme code doesn't need access to customer data or order history. A content editor doesn't need access to theme code or app settings. Assign the minimum permissions required for each role; this limits the damage if credentials are ever compromised or shared.
- Always enable password protection on dev stores
This keeps the dev store invisible to search engines and unreachable by anyone without the password. Share the password only with people actively working on the project.

- Revoke access when work is complete
When a contractor finishes an engagement or a project closes, remove their collaborator access the same day. It takes 30 seconds and eliminates an entire category of risk that most teams don't think about until something goes wrong.
Before pushing to live: our Shopify safe release checklist
Every incident we've seen on a live Shopify store had one thing in common: someone skipped a step they thought didn't apply to them.
This checklist exists so that doesn't happen to you. Use it for every release, font change, a new app, a full theme overhaul.
Download the Shopify Release Checklist
Size and complexity dictate the staging environment
The difference between teams that ship confidently and teams that dread releases usually comes down to one thing: a repeatable process.
Start simple. Duplicate your theme before every change and archive it with a date. That single habit prevents most incidents. Build from there, add preview links for stakeholder sign-off, set up a dev store for high-risk work, and adopt the release checklist as your team grows.
If you are running complex processes or a high-volume store, discover how we approach making changes safely via a call with one of our solution architects.