Skip to main content Statsig combines feature flags, experimentation, and product analytics in one platform. Migrating ensures your data, flag, experiments, and decision workflows live in a single source of truth.
This guide outlines the overall migration process. For provider-specific steps (Amplitude, LaunchDarkly, etc.), see our dedicated guides.
Migration Phases 1. Audit & Plan
Identify the datasets, events, and feature flags you want to move
Decide what needs full historical backfill vs. what can start fresh
Document any dashboards or KPIs that need rebuilding in Statsig
2. Set Up Live Data
Implement Statsig SDKs to start streaming new events and feature flag evaluations
Validate critical events are firing with the correct schema
Use Statsig for the newly recorded events and flags
3. Import Historical Data
Export data from your existing tool (S3 or warehouse is preferred)
Transform the schema to Statsig’s event format (event, user, timestamp, metadata)
Import via Statsig’s Event Webhook, S3 ingestion, or warehouse ingestion
4. Validate & Decommission
Compare metrics between your legacy tool and Statsig to ensure parity
Rebuild dashboards and charts in Statsig
Decommission old pipelines once Statsig is your single source of truth
Best Practices
Start small : Run a pilot project or test migration before backfilling all historyAlign IDs early : Ensure userID and stableID mapping is consistent. Identity mismatches are the most common failure pointShard historical imports : Break large datasets into daily partitions for stabilityRebuild insights intentionally : Don’t port all events and flags directly. Use migration as a chance to clean up stale dataPlan change management : Teams need time to adjust workflows, queries, and dashboards so migrate for 1-2 teams before championing in the broader org
Provider-Specific Guides Get Help Our team has helped many customers move off other tools so that everything is in Statsig. For tailored guidance, contact support@statsig.com or join our slack community .