
Shopify Rollouts lets you prepare and distribute storefront changes as a launch, a temporary event or an experiment. On September 22, 2026, Shopify made the setup more explicit: a single rollout can combine theme changes with a different checkout and customer account configuration, define when those changes become active, control how much eligible traffic they reach and surface conflicts before scheduling the release.
The feature matters because it moves part of the release process into Shopify instead of relying on theme copies, manual reminders and last-minute admin changes. But it is not a universal deployment pipeline: there are precise limits, especially when the work involves Liquid code.
What a Shopify rollout is
A rollout is a scheduled set of changes that can affect the online store theme, checkout and customer account configuration, or both. You manage rollouts from Markets > Rollouts in Shopify Admin.
The updated setup distinguishes three intents:
- Launch: applies the changes and keeps them. It can reach all eligible traffic or be introduced gradually.
- Event: applies changes for a defined period and rolls them back when the event ends.
- Experiment: compares a control version with a treatment version by splitting traffic between them.
These are not just labels. Duration, traffic behavior and available analytics change with the rollout type. A Launch fits a release that should become the new state, an Event fits a seasonal or time-bounded change, and an Experiment fits a change you want to measure against the current version before rolling it out more broadly.
Shopify plans: Rollouts from Basic, experiments from Grow
Shopify states that Rollouts is available on the Basic plan and higher. Running an Experiment requires Grow or higher.
That distinction matters. A merchant on Basic can use Rollouts to organize a Launch or an Event, but should not expect control-versus-treatment experimentation. If the goal is a true traffic-split test, the plan requirement starts at Grow.
Users also need permissions that match the resources being changed. Theme work requires theme permissions, while replacing a checkout and account configuration requires the relevant checkout and customer account permissions.
Which changes can live in the same rollout
Shopify lets you add one change for each of the two supported resource areas:
- edit the main theme or replace it with another theme;
- replace the current checkout and customer account configuration.
Both changes can be combined in one rollout. That is useful when a campaign needs the storefront and the final purchasing experience to move together, such as a seasonal theme paired with a different checkout and account configuration.
For a broader redesign, however, Rollouts does not replace theme architecture work. If the problem is deciding whether the current theme has become a technical constraint, the guide to Shopify redesign and theme limits is the more relevant starting point. Rollouts changes how a release is distributed, not the quality of the release itself.
The biggest limitation: it is not a Liquid code deployment system
Shopify's documentation explicitly states that Liquid templates can't be changed as part of a rollout. Rollouts should therefore not be treated as a replacement for Git, a development workflow or theme version control.
You can prepare changes that belong in the theme editor or replace the main theme with another theme already available in the store, but work that requires code changes still needs its own development, testing and release process.
The same principle applies to checkout. Rollouts can switch to a checkout and account configuration that has already been prepared, but it does not remove the constraints that apply to checkout extensions. Development considerations remain separate; see the guide to Shopify Checkout Extensibility.
Scheduling, markets and traffic percentage
A rollout can have a start date and time and, when needed, an end date. Timing follows the store timezone. You can also target specific markets and define what percentage of eligible traffic receives the rollout.
The distinction between traffic allocation and, for experiments, traffic split is important. Traffic allocation determines how many eligible visitors enter the rollout. In an Experiment, the traffic split then divides that group between control and treatment.
Shopify defaults a new Experiment to 50% control and 50% treatment, with an initial end date 90 days after the experiment starts. Both settings can be changed before saving.
An Experiment is more than “two themes online”
An Experiment compares only the changes included in that rollout. The control displays the resource in its current state; the treatment displays the changed state. If a resource is not changed, control and treatment show the same version of that resource.
This makes the test easier to reason about, but it does not automatically make the result statistically useful. Experiment quality still depends on the question you are testing, traffic volume, duration and whether the treatment is changed while the test is running.
Shopify starts collecting rollout analytics after launch. The available metrics vary with rollout type and the resources involved, and they are not customizable. Shopify also notes that identical changes can produce metrics that are not directly identical between a Launch and an Experiment because those rollout types use different calculation pipelines.
If you are interpreting conversion rate and sessions during a test, also account for Shopify's recent Analytics measurement change, covered in the guide to Shopify sessions and conversion rate from September 2026.
Check rollout conflicts before launch
The updated setup surfaces conflicts while you configure the rollout. Some conflicts must be resolved before the rollout can be saved; others are warnings that explain how an existing rollout can reduce the visibility of the new one.
With several rollouts active at the same time, the configured percentage does not always equal the effective percentage of visitors that will see the change. Shopify recalculates effective traffic when multiple rollouts target the same resource. For Experiments, each visitor is assigned to one view for that resource.
This is operationally important: when multiple Experiments overlap, or a Launch and an Experiment run at the same time, review effective traffic instead of relying only on the percentage entered in each rollout.
When to use Launch, Event or Experiment
The choice can be practical:
- Launch: a new homepage, visual configuration or theme change that should become the new baseline once reviewed.
- Event: Black Friday, a product launch, a seasonal campaign or another change that should exist only between defined dates.
- Experiment: a comparison between two experiences when there is a measurable question, such as a different visual hierarchy or an alternative checkout configuration.
I would not turn every release into an experiment. If there is no real hypothesis to test, a scheduled Launch is often simpler. Likewise, an Event should not be used to hide a structural change that really belongs in the maintained theme.
A practical checklist before activating Rollouts
- Decide whether the change should stay, expire or be compared with a control.
- Check the plan: Basic supports Rollouts; Grow or higher is required for Experiments.
- Confirm that the change is supported: theme editor/theme replacement or checkout and account configuration. Do not assume Liquid code is part of the rollout.
- Prepare the replacement theme or checkout/account configuration in advance.
- Set markets, date, time and traffic allocation.
- For an Experiment, review traffic split, duration and the hypothesis being measured.
- Resolve or understand every conflict warning Shopify shows.
- Review effective traffic when rollouts overlap.
- After launch, read rollout metrics in context and do not treat a measurement difference as proof of improvement.
Where Rollouts actually improves the process
The value of Rollouts is not “making changes risk-free”. Risk remains if the configuration is wrong, the theme was not tested or the experiment was poorly designed.
The practical benefit is different: preparation, scheduling, distribution and measurement become more clearly separated. A launch no longer has to depend on someone opening Shopify Admin at an exact time to manually switch a theme or checkout configuration.
For a simple store, this removes manual steps. For a more structured store, it adds a useful native release layer between development and go-live. The technical rule remains the same: prepare and verify the change first, then decide how to distribute it.
Official Shopify sources
The features and limits in this guide were checked on September 23, 2026 against Shopify's official documentation:
- Shopify Changelog — Plan launches, events, and tests with clearer and more granular controls in Rollouts;
- Shopify Help Center — Requirements and considerations for using rollouts;
- Shopify Help Center — Types of rollouts and changes;
- Shopify Help Center — Creating a rollout;
- Shopify Help Center — Rollout analytics;
- Shopify Help Center — Managing rollouts.
Sources cited in this article
Official documentation and external references linked in the text. Shopify features change: always check against the current version.
- Shopify Changelog — Plan launches, events, and tests with clearer and more granular controls in Rollouts Shopify · changelog.shopify.com
- Shopify Help Center — Requirements and considerations for using rollouts Shopify · help.shopify.com
- Shopify Help Center — Types of rollouts and changes Shopify · help.shopify.com
- Shopify Help Center — Creating a rollout Shopify · help.shopify.com
- Shopify Help Center — Rollout analytics Shopify · help.shopify.com
- Shopify Help Center — Managing rollouts Shopify · help.shopify.com



