This guide introduces the steps for transitioning from a proof of concept (POC) or limited test on Statsig to a full-scale production deployment.

## 1. Check project name/structure

1. **Rename the project if needed**: Most teams continue using the project created during the trial, but it's a good time to rename it if necessary.
2. **Decide if you need multiple projects**: Tools like tags and granular permissions allow you to manage multiple teams within a single project. Create a new project only if you're working on a completely separate product where the definition of a user (and DAU) is distinct, and no metrics need to be shared across projects. To avoid accidental creation of projects, you can restrict this to Admins.

![Project access restriction settings](/images/statsig-warehouse-native/guides/production/184998486-094beff1-f41f-417c-bd36-89700b0c014c.png)

3. **Seed your project**: Set up tags to use consistently across feature gates, experiments, and metrics.
4. **Create Segments**: Identify internal employees or testers by creating [Segments](/segments/overview) so you can easily override them into feature rollouts and experiments.

## 2. Set up SSO for easy onboarding

To streamline user onboarding and deactivation, set up [Single Sign-On (SSO)](/access-management/introduction) with your identity provider. Statsig supports OIDC, a modern protocol compatible with most identity providers. After SSO is set up, Statsig automatically creates accounts for employees verified by your identity provider upon their first login.

You can also make your project **Open** so that new users verified by SSO automatically gain access, or keep it **Closed** and manually approve new access requests.

![SSO project access configuration](/images/statsig-warehouse-native/guides/production/175362892-862d0cf5-012f-484a-8e39-22489011029e.png)

## 3. Define change management policies for production

To ensure safe production changes, Statsig lets you [require reviews](/guides/setting-up-reviews) before implementing changes, similar to code reviews in software development. You can create [Review Groups](/guides/setting-up-reviews#creating-review-groups) to notify key stakeholders and set up granular permissions for specific feature gates and experiments.

For non-production environments such as dev or staging, refer to the [recommended approach](https://blog.statsig.com/environments-on-statsig-6a818805b3c2) for managing environments.

![Environment management configuration](/images/statsig-warehouse-native/guides/production/179292011-5a6bcb75-9bb7-47d4-b876-28c2510315fe.png)
![Review groups setup interface](/images/statsig-warehouse-native/guides/production/179292033-d6e10544-08f6-418a-9fdb-32156487e6da.png)

## 4. Set up key metrics and dimensions

Before starting experiments, ensure you have correctly set up the [metrics](/metrics/introduction) and dimensions you want to experiment on.

Consider the following:

* **[Custom Metrics](/metrics/create)**: Build custom metrics from existing ones (e.g., aggregations, ratios).
* **User Dimensions**: Enable slicing results by Geo, User, etc.
* **[Metric Dimensions](/metrics/introduction#metric-dimensions)**: For example, analyzing "add-to-cart" events by Product Category.
* **[Funnels](/metrics/create-user-funnels)**: Create funnels to track user journeys.
* **[Tag Metrics](/metrics/create-metric-tags)**: Group frequently used metrics for easy experiment integration.

Also, decide whether to export data from Statsig back into your systems and whether to [customize the DAU definition](/metrics/user#definition-of-a-daily-active-user) to reflect your business needs (for example, counting only meaningful events).

![Metrics and dimensions setup dashboard](/images/statsig-warehouse-native/guides/production/178082121-bb258851-29e5-4732-bd2a-af87833f7570.png)

## 5. Determine IDs for experimentation

Most Statsig experiments and feature rollouts target users by **userID**, but Statsig also allows experimentation using other "units of assignment."

Here are your options:

1. **userID**: Identifies individual users.
2. **stableID**: A Statsig SDK-managed ID, typically used to experiment on anonymous users (e.g., unique to devices).
3. **Custom IDs**: You can create arbitrary IDs based on your use case, such as:
   * **organizationID** for B2B customers
   * **vehicleID** for controlling features in vehicles
   * **creatorID** for two-sided marketplaces, controlling features for creators vs. consumers

For more, refer to [Experiment on Custom ID Types](/guides/experiment-on-custom-id-types).

## 6. Set up integrations

If you haven't already, explore the [integrations](/integrations/introduction) available to bring data into Statsig. Additionally, consider setting up these integrations:

* **Data Warehouse Export**: Export assignment data from Statsig to your data warehouse.
* **Change History Exports**: Export change history to Slack, Teams, or Datadog to overlay with operational dashboards.

## 7. Best practices, forums, and training

Create a repository for **best practices** and a forum for experimenters to share insights, get feedback, and seek help. Provide guidance to your teams on when to use Feature Gates versus Experiments.

If you’re on Statsig’s **Enterprise Support**, consider organizing specific training for subject matter experts (SMEs):

* Start with **train-the-trainer** sessions so SMEs can explore key topics in depth.
* Use these sessions to create tailored guidelines for your teams.
* Use the **Slack Support** channel with an SLA for faster assistance.

Some useful topics for engaging teams:
![Team training topics overview](/images/statsig-warehouse-native/guides/production/180329958-315e2719-5951-4698-82c1-0221353ead95.png)

## 8. Plan your migration strategy (if applicable)

If you're migrating from another experimentation platform, decide on a migration strategy. Set a date after which you create new experiments and gates on Statsig. Let any ongoing experiments or ephemeral gates on legacy systems conclude there, and migrate only gates expected to persist long-term.

***