On this page

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.

Early Access

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

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.

Prerequisites

Before running the wizard, fully set up the destination Warehouse Native project:

  1. Create the new Warehouse Native project.
  2. Connect and test your warehouse connection.
  3. Configure the Data tab: assignment sources, metric sources, and metrics that match the source project's metric names.
  4. Backfill any historical data you want available in your warehouse.

Run the wizard

  1. Open the wizard in the source project. It appears once Statsig enables early access for your project.
  2. Pick the destination project. The wizard runs a precheck that validates the destination (warehouse connection and required setup) before it copies anything.
  3. 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.
  4. 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

  1. Spot-check copied entities in the destination project: rules, experiment groups, holdout membership, and parameter store references.
  2. Compare entity counts against the source project, minus the intentionally skipped items from the report.
  3. When you're satisfied, update your SDK initializations to the destination project's keys, environment by environment. The wizard copies experiments unstarted, so you decide when to launch them in the new project.

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.

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?