# Self-Serve Migration Wizard (Early Access)

{% callout type="note" %}
Statsig enables the wizard per project on request. To try it, raise a
[support request](https://docs.statsig.com/support-options) through your dedicated Slack channel, the
[Slack community](https://statsig.com/slack), 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.
{% /callout %}

The self-serve migration wizard automates step 4 of the [migration guide](https://docs.statsig.com/statsig-warehouse-native/guides/migrate-to-whn): 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.

## 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](https://docs.statsig.com/statsig-warehouse-native/guides/connect).
3. Configure the Data tab: assignment sources, [metric sources](https://docs.statsig.com/statsig-warehouse-native/configuration/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.

{% callout type="note" %}
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.
{% /callout %}

## 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.