Migrate from Split to GrowthBook

How to migrate from Split to GrowthBook without losing experiment history

If a renewal, the move of Split into Harness, or a warehouse requirement is pushing you off Split, you can move both flags and experiments to GrowthBook, but flag definitions, metrics and SDK integration each need separate work. Treat them as three workstreams with different owners. The platform team owns the flag export, recreation and environment setup. The data team owns metric definitions and checks that GrowthBook queries against your warehouse. The application teams own swapping Split SDK calls for a GrowthBook SDK and removing the old ones. Experiment history is the part most likely to be lost, because Split's stored results and metric definitions do not come across as data you can import into GrowthBook. The short answer on effort and risk is that flags are the easy part and experiments are the hard part. GrowthBook's documented importers target LaunchDarkly and Statsig, not Split, so a Split move is typically a scripted export of definitions through the Split or Harness Admin API, followed by manual recreation of targeting rules, segments and treatments in GrowthBook. Confirm the current export options with Harness and the current import tooling with GrowthBook before you commit to a schedule, since both products change. Ask your Harness account contact which data you can export in full, and whether historical experiment results are available in a usable form at all.

Plan to run both systems side by side on the same experiments until the numbers agree. For each active experiment, define the primary metric in GrowthBook against the same warehouse tables that feed your current results, then compare assignment counts and metric values over a shared window. Where the figures differ, check the exposure event, the attribution window and the handling of bots and duplicate users first, since these are the usual sources of gaps. Keep the Split experiment running and archive its results as a record before you stop it, because the audit trail is your evidence for past decisions. Two items often delay cutovers. First, GrowthBook's self-hosted Open Source plan allows one project, so confirm whether your structure needs more projects or whether one project with clear naming is enough. Second, SSO, SCIM, approval workflows and holdouts are in the self-hosted Enterprise edition, not the free one, so decide early which of these your governance requires. Ask GrowthBook and your implementation partner to write the cutover checklist, including who signs off each experiment result and how rollback to Split works if an application deploy fails.

Which Split capabilities map to GrowthBook and which need rework

This table compares the main Split and Harness FME constructs with their GrowthBook equivalents and marks each as clean, needs rework or gap. Use it during your inventory to decide which items move across as-is and which need rebuilding. The main takeaway is that flag evaluation and warehouse-based experiments map well, while Split-specific constructs and some governance features need manual work or confirmation.

Split capability	GrowthBook equivalent	Status and notes
Feature flags and treatments	Features with on/off and typed values per environment	Needs rework. Map each treatment to a GrowthBook feature value and confirm variant types in the GrowthBook docs.
Targeting rules and attributes	Feature rules with conditions on attributes	Needs rework. Rebuild rules by hand or with the importer, then check attribute names match what your SDK sends.
Segments and allowlists	Attributes, saved groups and conditions	Needs rework. Confirm how your segments were defined in Split and recreate them as GrowthBook conditions.
Percentage rollouts	Rollout rules with percentage and hash attribute	Clean. Confirm the hashing attribute and seed so existing users keep their assignments.
Environments	Environments per feature with separate enablement	Clean. Self-hosted Open Source allows one project, so check how many projects your Split workspace uses.
Experiments (A/B tests)	Experiments tied to features, analyzed on your warehouse	Needs rework. Metric definitions and experiment settings must be rebuilt and checked against Split results.
Metrics and events	Metrics defined as SQL on your warehouse tables	Gap in practice. You must write metric SQL and own the event pipeline before results can match.
Holdouts, approvals, SSO and SCIM	Available in self-hosted GrowthBook Enterprise only	Gap on the free Open Source plan. Enterprise adds SSO, SCIM, approval workflows, safe rollouts and holdouts.
Dynamic configurations and traffic types	No direct equivalent confirmed for all Split constructs	Confirm during inventory. Check each Split-specific construct against the GrowthBook docs before planning.

What to export from Split and what to rebuild in GrowthBook

Split's flag definitions can be pulled out as structured files, but the rest of the move is manual work. Segments, targeting, metrics and SDK calls each need a decision and a check before you cut over.

Export flag definitions with the Admin API

Split's Admin API and the Python tools Harness documents are the starting point for pulling feature flag definitions, treatments and configurations out of your workspace. The output comes as JSON or YAML, so you can keep a versioned copy before any change in GrowthBook. Confirm with Harness which export tool and version matches your Split or FME account, and check that it captures every environment and traffic type you use, since the export is only as complete as the scope you request.

Rebuild segments and targeting by hand

Split segments and targeting rules rarely map one to one onto GrowthBook targeting conditions. Treat each rule as a specification to re-enter and test, not as a file to import. Illustratively, a rule that matches a Split segment of beta customers may need an attribute condition on your own user record. List every segment referenced by a flag before you start, and record which ones depend on keys or attributes that your application must start sending.

Recreate metrics on your warehouse

GrowthBook analyzes experiments with read-only SELECT queries against your own data source, including Snowflake, BigQuery, Redshift, Databricks and others listed in its data source documentation. Split's hosted metrics do not carry over automatically, so each success metric needs a definition in SQL that matches what your team trusted before. Confirm which warehouse holds your exposure events, and agree the definitions with the analysts who own them before any experiment is read.

Replace Split SDK calls in application code

Every place that calls the Split SDK to request a treatment must change to a GrowthBook SDK call, and the change is in your code, not in the flag service. Keep the call sites small and wrap them so that a future vendor change touches one module. Consider OpenFeature as a neutral API layer if you expect to change providers again. Confirm which GrowthBook SDK fits each service language, and test the default value returned when the SDK cannot reach its source.

Check for a Split importer before assuming one

GrowthBook documents importers for LaunchDarkly and Statsig, and the Statsig importer shows how such a tool can be structured, reading environments, segments and experiments through an API key. Do not assume an equivalent Split importer exists. Ask GrowthBook and Harness directly whether one is available for your Split plan, and if not, plan for a scripted export and manual entry based on the Admin API output.

Map permissions and approvals

Split's roles, workspaces and change approval practices do not translate one for one into GrowthBook's permissions model. Free self-hosted GrowthBook does not include approval workflows, advanced permissioning or SSO and SCIM, which the paid self-hosted Enterprise edition adds. Write down who can change flags in production today and decide which of those controls you need before cutover, so the audit trail for flag changes is not weaker after the move.

Migration sequence from inventory to decommission

The sequence moves Split flags and experiments into GrowthBook in controlled stages, so each cutover is backed by evidence that the new setup behaves like the old one. Each step ends with a named output that the next step depends on, and decommissioning happens only after sign-off.

Inventory flags, experiments and metrics
Export flag definitions, treatments, segments and experiment configurations from Split or Harness FME using the Admin API and the documented export tooling, then list every application that calls the Split SDK. Record each flag's owner, environment, default treatment, targeting rules and whether it is a release flag or an experiment, because the Split export will not carry all of this into GrowthBook automatically. Mark which metrics are computed by Split and which already exist in your warehouse. The output is a written inventory with one row per flag, experiment and metric, and a list of SDK integration points per application. You know it is done when the product owners and the platform team have signed off that the inventory is complete.
Recreate metrics on the warehouse
Before any experiment can be compared, the metrics it depends on must exist in GrowthBook as definitions that query your own data source. GrowthBook runs read-only SELECT queries against supported warehouses and transmits only aggregated statistics, so the analytics team confirms the event tables, identity keys and metric logic that match each Split metric. Expect Split metric definitions to need manual translation, since the inventory will show where they differ. The output is a metric catalog in GrowthBook, with each metric linked to its source table and a note on any Split definition that could not be matched exactly. Done means each metric in scope has been run once against real data without errors.
Pilot one low-risk flag and one experiment
Choose one release flag with a narrow audience and one experiment that is already concluded in Split, so the expected result is known. Recreate both in GrowthBook, either through the importer or by hand, and check the carried-over fallback values, targeting rules and rollout percentages against the inventory. Switch one non-critical service to the GrowthBook SDK for these two items only, since the GrowthBook documentation notes the application must change SDKs after import and advanced setups can contain scenarios the importer does not handle. The output is a pilot report covering what imported cleanly, what was rebuilt by hand, and any mismatches found. Done means the pilot report has been reviewed and each mismatch has an owner and a fix or an accepted explanation.
Run Split and GrowthBook in parallel
Keep Split active while GrowthBook evaluates the same flags for the same users, and compare assignments and outcomes. Assignment checks confirm that a user receives the same treatment in both systems wherever the rules are meant to match, and results checks confirm that the warehouse-computed metrics agree with Split's figures within the tolerance your analysts agree on before the run starts. Investigate differences in identity keys, time windows, bot filtering and metric definitions first, because these account for most gaps. The output is a reconciliation record listing each flag and experiment, the agreement status and the explanation for every difference. Done means the record is signed off by the analytics lead and the owners of the affected products.
Cut over each application
Move applications one at a time, starting with the lowest-risk, and change them from the Split SDK to a GrowthBook SDK in code, with the flag keys and fallback values taken from the reconciled inventory. Confirm which environments and projects each application uses in GrowthBook and check that access controls match your existing permissions. Keep a rollback path that re-enables the Split SDK for that application until its monitoring is clean. The output is a cutover checklist per application, with the release date, the owner, the verified flag keys, the monitoring checks and the rollback step. Done means each checklist is marked complete and the application has run on GrowthBook under normal load without incidents traced to the flag system.
Decommission Split SDKs and data after sign-off
After every application has been cut over and the final experiment results have been reviewed, remove the Split SDK from each codebase and deactivate the Split integrations. Retain the exported definitions, the reconciliation record and the experiment results under your records retention policy, and confirm with your compliance team what must be kept for audit purposes. Confirm with Harness what happens to your Split data and account on your contract terms before you request deletion. The output is a decommission record listing the removed SDKs, the archived exports, the retention decision and the date of account closure. Done means the record has been approved by the platform owner and the security or compliance owner.

What drives migration cost and duration

This table lists the inputs that change the effort of moving from Split to GrowthBook and separates one-time migration work from recurring operating cost. Use it to scope your own inventory before asking for a quote, since most of the variation comes from how many flags, experiments and warehouse sources you run.

Driver or cost item	Why it changes cost or effort	One-time or recurring
Number of flags and treatments	Each flag and treatment needs review, mapping and testing in GrowthBook, and the importer does not cover every setup, so count them before scoping	One-time
Segments and targeting rules	Complex segments and nested rules often need manual recreation, which is where most rebuild hours go	One-time
Experiments and metrics defined in Split	Each experiment's metrics must be rebuilt on your warehouse as GrowthBook metric definitions and checked against Split results	One-time
Warehouse data sources	Each source needs a connection, read-only credentials and validation queries, and experiments add query load against it	One-time setup, recurring query cost
Applications and SDK integrations	Every service that calls Split needs its SDK swapped and retested, and GrowthBook documents that the application must switch SDKs after import	One-time
Parallel run period	Running Split and GrowthBook side by side until results match adds engineering and analysis time before cutover	One-time
Self-hosted infrastructure and MongoDB or compatible database	Hosting the GrowthBook image, a managed MongoDB-compatible service and backups continue after launch and are paid to your cloud provider or data center	Recurring
Paid GrowthBook Enterprise features	SSO, SCIM, advanced permissioning and approval workflows are not in the free self-hosted Open Source plan and are custom priced, so request a quote	Recurring if required

What usually goes wrong when moving experiments from Split

Most failed experiment migrations break in the same few places: metric definitions, bucketing, targeting, SDK wiring, edition limits and warehouse spend. Each card below names one risk, why it matters when moving from Split or Harness FME to GrowthBook, and the check that prevents it.

Metric definition drift

Split's hosted metrics and GrowthBook's warehouse SQL are not the same object. A conversion event filtered by a different window, deduplication rule or user identifier will produce a different number even when both tools read the same events. Before any parallel run, write each metric definition down in plain language, then compare the SQL against it with a sample of users. Ask Harness to confirm how its metric windows and counting units behave, since those details are rarely visible in exports.

Bucketing mismatch during parallel runs

Running Split and GrowthBook side by side only works if each user lands in the same variant in both tools, or if you accept that the two systems compare different populations. Hash keys, salts, traffic percentages and attribute types often differ, so a user may be counted in one experiment arm in Split and another in GrowthBook. Check sample ratios in both systems from the first day, and flag any arm that drifts from its intended split before reading results.

Targeting rules that do not translate

Split segments, attribute comparisons and treatment-level rules are exported as definitions, but some conditions have no one-to-one equivalent in GrowthBook. Rules that depend on segment membership updated by file upload, or on evaluation order across several rules, are common sources of silent change. Build a table that maps every Split rule to its GrowthBook rule, then evaluate both against a fixed set of test user attributes and compare outcomes before switching traffic.

SDK switches missed in some services

The importer moves definitions, but the application still has to switch from the Split SDK to a GrowthBook SDK. In a larger estate, one service, batch job, mobile build or internal tool often keeps calling Split after the others have moved, and it then reports different exposure data. Keep an inventory of every service that calls Split, including scheduled jobs and older releases, and confirm each one is either migrated or intentionally frozen before you stop Split evaluations.

One-project limit on the free edition

The self-hosted Open Source plan allows one project, so separate Split workspaces, product areas or environments that were split into projects will not all fit. Teams often discover this only when the import begins. Decide before the migration whether the rollout needs one project with naming conventions, or whether the Enterprise self-hosted edition is required, and ask for a written quote covering that choice before the cutover date is set.

Warehouse costs from experiment queries

GrowthBook runs SELECT queries against your warehouse to compute results, and those queries are billed by your warehouse provider, not by GrowthBook. Many concurrent experiments, long lookback windows or frequent refreshes can raise the bill in ways that did not exist when Split computed metrics on its own platform. Set refresh schedules, limit lookback windows, and review query cost per experiment during the parallel run so you have a baseline before cutover.

How the migration differs by starting point

Teams that bought Split mainly for experimentation usually have the most work in front of them, because the metrics are the hard part, not the flags. Split's hosted metric definitions, event ingestion and statistical results have to be rebuilt as GrowthBook metrics that query your own warehouse. GrowthBook runs read-only SELECT queries against sources such as Snowflake, BigQuery or Databricks and transmits only aggregated statistics, so the event tables, identity joins and metric SQL must already be sound before the first analysis is trusted.

Scope: Plan a metric inventory first, listing each Split metric, its event source, its aggregation and its attribution window, then map each one to a GrowthBook metric and a data source.
Sequence: Stand up the warehouse data source and verify a handful of core metrics before migrating any experiment, since flags are the cheap part of the move.
Parallel run: Keep Split running for live experiments and run the same test in GrowthBook on the same population until the reported lifts and confidence intervals agree within the tolerance your analysts accept.
Governance: Decide who owns metric definitions and whether the Open Source plan's single project limit is enough for your experiment catalog.
Cost driver: Warehouse compute for experiment queries recurs and grows with traffic and metric count, so ask your data team to estimate it before cutover.

Confirm with your analysts which Split results are used for decisions, because those are the numbers the parallel run must reproduce.

Questions teams ask before moving from Split to GrowthBook

How much effort and cost should we expect when moving from Split to GrowthBook?

The cost has four parts: the GrowthBook platform, the warehouse queries your experiments run, the people who rebuild flags and metrics, and ongoing operations. The platform itself can be free to start, since the self-hosted Open Source plan has no per-user fee, but the self-hosted Enterprise features (SSO and SCIM, advanced permissioning, approval workflows, holdouts and safe rollouts) are paid and need a quote. Harness FME is quoted as part of a Harness Enterprise plan, so ask Harness what it would cost to keep your current scope. Effort rises with the number of flags, targeting rules, segments and metrics you must rebuild by hand, and with how many experiments are still running. Ask any vendor or partner for a quote built from your written scope, with one-time and recurring items listed separately.

How long does a migration from Split to GrowthBook take?

The timeline depends mainly on how many flags, experiments and metrics you have, how complex the targeting is, and how long you need both tools running side by side. Export and recreation work is usually the longest part, because some Split targeting rules and segments may have to be rebuilt manually. Metric rebuilding depends on how clean your warehouse tables and event definitions already are. Parallel running should last until the results match across a full experiment cycle, which your own release calendar will set. The GrowthBook documentation does not give a general duration for this kind of move, so ask for a timeline in the written scope and check its assumptions against your own inventory.

What does the internal team need to provide during the migration?

You need owners for three things: the flag and experiment inventory, the warehouse data your metrics depend on, and the application code that calls the Split SDK. Your data team should confirm which warehouse tables hold exposure and conversion events, and which read-only credentials GrowthBook can use. Engineers must replace Split SDK calls with GrowthBook SDK calls, because the LaunchDarkly importer documentation makes clear that the application still has to switch SDKs after an import, and the same applies here. Product and experiment owners should sign off on each recreated metric and targeting rule. Name these people before work starts so decisions do not stall.

Can our own team migrate from Split to GrowthBook without outside help?

A capable team can do it alone if it has time, warehouse skills and engineers available for SDK changes. The main risks are missed targeting rules, metrics defined differently from your Split setup, and running a self-hosted MongoDB-backed deployment without operational experience. Teams with a small number of flags and one or two experiments often manage this in-house. Teams with many active experiments, regulated audit trails or a tight renewal date often bring in help. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, usually under a fixed-scope agreement, and quotes from written scope. Decide which parts you own before comparing options.

Does GrowthBook have an importer for Split?

GrowthBook documents an importer for Statsig and a separate importer for LaunchDarkly, but the supplied documentation for this topic does not confirm a general Split importer. The Statsig importer reads environments, tags, segments, feature gates, dynamic configs and experiments through an API key, with metric sources and metrics still in beta and limited to warehouse-native Statsig metrics. Because the Split importer question is open, plan on exporting your Split definitions with the Admin API and recreating them in GrowthBook, and confirm current importer coverage directly with GrowthBook before you rely on one. Check the GrowthBook migration guide for LaunchDarkly to see how an importer handles advanced setups it may not cover.

Can GrowthBook run in our own cloud account or data center?

Yes. GrowthBook's self-hosting documentation describes a single Docker image that bundles the Next.js front end, Express API and Python statistics engine, with metadata stored in MongoDB or a compatible database. GrowthBook also maintains an official Helm chart for Kubernetes and supports local, Amazon S3 or Google Cloud Storage for file uploads, so you can place it in your own cloud or on-premises cluster. For experiments, GrowthBook queries your existing warehouse with read-only SELECT statements and receives only aggregated statistics. Confirm with GrowthBook which deployment options and database versions your security team accepts, and check how the self-hosted Enterprise license applies to your use.

How do we confirm GrowthBook results match Split before cutover?

Run both systems side by side on the same traffic and compare assignment and metric outcomes for each experiment. First confirm that the same users receive the same variants in both tools, since a difference in bucketing or targeting shifts every downstream number. Then recreate each metric from its original definition and compare the calculated values over an agreed window, documenting every gap and its cause. Set acceptance criteria in writing before you start, and have the product owner sign off on each one. Keep Split active until the comparison passes and no experiment is still reading from it. Your data and compliance teams can keep the evidence, though DeployOpen prepares controls and evidence for assessments without issuing audit reports, which independent auditors provide.

What should we ask for in a written scope for this migration?

Ask for a scope that lists every flag, experiment, segment and metric to be moved, plus the ones to retire. Each item should name its owner, its source system and its acceptance test. Include the SDK changes for each application, the warehouse connections and credentials, the self-hosted deployment target, backup and upgrade responsibilities, and the parallel-run period with its exit criteria. Require a list of Enterprise features you intend to use, such as SSO or approval workflows, so licensing is priced honestly. State which items are one-time and which recur, such as hosting, maintenance and support retainers. Fixed-scope agreements with written deliverables make comparison straightforward across proposals.

How DeployOpen scopes and runs a Split to GrowthBook migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so GrowthBook would run in your cloud account or data center. We begin with a written scope that covers the flags, experiments, metrics and warehouse connections involved in moving off Split or Harness FME.

How we scope

Inventory every Split feature, treatment, segment and experiment that must move, and mark which ones are still in use.
Confirm the warehouse, SDK languages and environments GrowthBook will need to read from and serve to.
Agree in writing which items are imported, which are rebuilt by hand and which are retired before work starts.
Document the parallel-run period, acceptance checks and cutover conditions as part of the fixed-scope agreement.

How we build

Deploy GrowthBook in your environment, including its MongoDB-compatible metadata store and the storage option you select.
Export Split definitions through the Admin API tooling and map targeting rules and segments into GrowthBook features.
Rebuild experiment metrics as SQL queries against your existing warehouse, with read-only access and reviewed query logic.
Swap application code from the Split SDK to the GrowthBook SDK and run both systems side by side until results match.

How we hand over

Deliver a runbook covering deployment, configuration, backups, upgrades and rollback steps for the GrowthBook installation.
Document each migrated flag and experiment with its owner, targeting logic and the metric definitions behind its results.
Record the parallel-run comparisons, including any differences found and how each one was resolved.
Walk your platform, data and product teams through the handover and confirm which edition features your team will use.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Scope any follow-on work, such as Enterprise-edition features or additional warehouse sources, as a separate written scope.
Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
Confirm with GrowthBook which self-hosted edition features your planned use requires before committing to a scope.