For AI agents: a documentation index is available at /llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
Self-Serve Migration Wizard (Early Access)
Copy an existing Statsig project's configuration into a new Warehouse Native project with the self-serve migration wizard. The wizard copies gates, experiments, segments, and more in dependency order while your source project stays unchanged.
This feature is in Early Access. During this time, aspects of the functionality may still be developed, and this documentation may not always be up to date. If you have any questions, contact Statsig Support.
Statsig enables the wizard per project on request. To try it, raise a support request through your dedicated Slack channel, the Slack community, or support@statsig.com. You can also ask your account team. Include your source project ID and, if you've already created it, your destination Warehouse Native project ID, so Statsig can enable access.
The self-serve migration wizard automates step 4 of the migration guide: instead of recreating your configurations manually or through the Console API, the wizard copies them from your existing project into a separate, pre-created Warehouse Native project for you.
The wizard never modifies your source project. It keeps serving traffic throughout the migration and remains your rollback path and your historical record.
What the wizard copies
| Copied | Notes |
|---|---|
| Feature gates | Rules, targeting, and tags; segment references resolve by name |
| Dynamic configs | Rules and values |
| Segments | Rule-based segments; the wizard flags large ID-list segments for manual handling |
| Layers | Explicit layers with parameters and allocations |
| Experiments | Full setup, groups, and parameters, created unstarted; metrics re-attach by name |
| Holdouts | Including member gates, experiments, and layers |
| Parameter stores | With references remapped to the copied entities |
| Autotunes | Setup only; the wizard flags event-based autotunes, which can't run in a Warehouse Native project |
| Project settings | Relevant non-cutover settings and custom ID types |
What it doesn't copy
- Metrics and metric sources: These are warehouse-specific SQL that you must create in the destination project before migrating. Use the same metric names as the source project so experiments re-attach automatically.
- Historical results, exposures, and decision records: These describe the source project's run history and stay readable there.
- Dashboards, alerts, and large ID-list segments: The wizard flags these in its report for manual recreation.
- SDK keys and environments: The destination project issues its own keys; you switch your SDKs over at cutover time.
Assignment after you switch SDKs
Users keep their assignments when you move your SDKs to the destination project. The wizard copies each entity's bucketing salts, the values Statsig hashes with a unit ID to assign users deterministically, so the same users pass the same gates and land in the same experiment groups and layer allocations as in the source project.
| Entity | Salts the wizard keeps |
|---|---|
| Feature gates, dynamic configs, and segments | The entity salt and every rule's salt, so partial rollouts pass the same users |
| Holdouts | The holdout salt and its rule salts, so the same users stay held out |
| Layers | The layer's universe salt |
| Experiments | The experiment salt and the experiment's allocation within its layer |
| Autotunes | The experiment salt |
The wizard creates experiments unstarted, so users get the default experience in the destination until you start each copy. Start the copies of experiments that are running in the source project before you switch SDK keys.
When the wizard can't keep an assignment, it reports the entity in the step summary instead of failing:
allocation_not_preserved: Another experiment in the destination layer already uses the source experiment's allocation, or the source allocation doesn't match the copy's size. The copy gets a new allocation, so a different set of users enters the experiment.layer_universe_salt_differs: The experiment joined a layer with the same name that you created in the destination before the migration. That layer has its own salt, so users fall into different allocations. Let the wizard create layers to avoid this.holdout_salts_not_preserved: The source holdout's salt changed after Statsig set up its groups, and the source still buckets users on the earlier salt. The copy uses the current salt, so some users can move into or out of the holdout.
The wizard doesn't report two cases:
- Copies from earlier runs: Re-runs skip entities that already exist in the destination, so they don't update salts on existing copies. Copies from a run on or before October 16, 2026 can have new salts. To give them the source salts, delete those copies from the destination project and re-run the wizard.
- Stratified sampling on unstarted experiments: The wizard doesn't copy the stratified sampling salt. Started experiments already bucket on it through the experiment salt, but for an unstarted experiment, run stratified sampling again in the destination before you start it.
Prerequisites
Before running the wizard, fully set up the destination Warehouse Native project:
- Create the new Warehouse Native project.
- Connect and test your warehouse connection.
- Configure the Data tab: assignment sources, metric sources, and metrics that match the source project's metric names.
- Backfill any historical data you want available in your warehouse.
Run the wizard
- Open the wizard in the source project. It appears once Statsig enables early access for your project.
- Pick the destination project. The wizard runs a precheck that validates the destination (warehouse connection and required setup) before it copies anything.
- Start the migration. Steps run in dependency order: segments before gates, layers before experiments, and so on. Each step reports what it created, skipped, or flagged with a warning as it completes.
- Review the report. Warnings, such as entities that need manual handling or references the wizard couldn't resolve, stay visible after the run completes, including across page reloads.
Runs are idempotent: if the wizard stops partway or you re-run it, it skips entities that already exist in the destination (matched by name) rather than duplicating them.
Verify, then cut over
- Spot-check copied entities in the destination project: rules, experiment groups, holdout membership, and parameter store references.
- Compare entity counts against the source project, minus the intentionally skipped items from the report.
- Check the report for assignment warnings, and start the copies of experiments that are running in the source project.
- When you're satisfied, update your SDK initializations to the destination project's keys, environment by environment.
Nothing in this flow modifies the source project, so rolling back is simply continuing to use your existing keys.
FAQ
Do my running experiments stop? No. The source experiments keep running untouched; the wizard creates copies unstarted in the destination.
Do users get the same gate results and experiment groups after I switch SDKs? Yes. The wizard copies bucketing salts, so users keep their assignments once you start the copied experiments. Check the run report for the exceptions in Assignment after you switch SDKs.
Can I re-run the wizard? Yes. Runs are idempotent, and the wizard skips entities that already exist in the destination (by name).
Does this move my data? No. The wizard copies configuration. Exposure and metric data in a Warehouse Native project come from your warehouse, and backfilling historical data is part of the prerequisites.
Was this helpful?