Split vs GrowthBook

Split, now Harness FME, and GrowthBook both cover flags and A/B tests, but they differ on where experiment analysis runs, how pricing is set and who controls the data. This page helps you decide which fits your team at renewal.

On this page

Split vs GrowthBook: when each fits an experimentation team

If your team bought Split mainly to run experiments, the Harness-era renewal forces a choice between two different models. Harness Feature Management and Experimentation (FME) fits organizations that already standardize on the Harness platform and are willing to buy FME as a quoted module of a broader Harness Enterprise plan. Self-hosted GrowthBook fits teams that want experiment statistics computed against their own data warehouse, with the flag system and the analysis both running in infrastructure they control. Neither answer is correct in general. The right one depends on where your event data already lives and who in the organization owns the experiment platform.

Start with where analysis must run. GrowthBook analyzes experiments against your own data source, running only SELECT queries and sending back aggregated statistics, so raw events stay in the warehouse. Ask your data team which warehouse holds the exposure and conversion events you need, and confirm that the GrowthBook data source list covers it. Next, check the governance requirements. The free self-hosted Open Source plan does not include SSO and SCIM, advanced permissioning, approval workflows, holdouts, or safe rollouts. If your audit or change process needs any of these, you are pricing the self-hosted Enterprise edition, so the comparison is no longer free against paid. Confirm which controls your compliance and release owners require before you compare totals.

Close the comparison with total cost of running the system, not license price alone. Harness FME is priced by quotation, so ask for the quote to name the modules, seat or usage units, and what renews. For GrowthBook, the recurring costs are your hosting, the MongoDB-compatible database, warehouse query load from experiments, and the engineers who operate the Docker image or Helm chart and handle upgrades. Those costs are one-time and recurring in different measures, and they rise with experiment volume and metric count. Write down the decision drivers before the renewal date: where analysis must run, which governance features are mandatory, and the full annual cost of each path, including migration work.

Which option fits which buying scenario

This table matches common buying scenarios for Split (now Harness FME) to the better fit between Split and self-hosted GrowthBook. Read each row for the deciding factor, then confirm the fact named in the last column before choosing.

ScenarioBetter fitWhy and what to confirm
Existing Harness contractSplit (Harness FME) for nowStaying inside an existing Harness agreement keeps procurement simple, but confirm with Harness whether FME is in your contract scope, its renewal date and what migration support it includes.
Warehouse-first data policyGrowthBookGrowthBook queries your own warehouse with read-only SELECT statements and sends back only aggregated statistics. Confirm that your warehouse (such as Snowflake, BigQuery or Postgres) is on GrowthBook's supported list and that your data team can own metric definitions.
Need for SSO and approval workflowsDepends on editionSelf-hosted GrowthBook's free Open Source plan does not include SSO, SCIM, approval workflows or advanced permissioning, which the self-hosted Enterprise plan adds. Confirm which of these controls you need on day one and get the Enterprise quote in writing.
Small team running a few experimentsGrowthBook Open Source (illustrative fit)The free self-hosted plan allows unlimited users but one project, so a single product area can run on it. Confirm that one project is enough for your flags and experiments, and budget for the operations work of running MongoDB and the GrowthBook image yourself.
Many teams or products needing separate projectsSplit or a paid GrowthBook tierThe free self-hosted plan's single-project limit can force a paid tier or a second instance. Confirm how many projects, environments and users you need before you compare costs.
Regulated environment requiring data in your own cloudSelf-hosted GrowthBookGrowthBook can run inside your own cloud account, with file storage on local disk, Amazon S3 or Google Cloud Storage and a Helm chart for Kubernetes. Confirm with your compliance team which evidence assessors expect for hosting, access and backups, because DeployOpen prepares that evidence but does not issue attestations.
Heavy use of flags for releases, not experimentsNeither by default (evaluate Unleash)GrowthBook is built around experiments, so a flag-first team may find a release-focused tool a better match. Confirm which flag features your team uses daily before you commit to either path.

How the move into Harness changes the decision for Split customers

Harness acquired Split Software, and the acquisition was announced on May 30, 2024. Split is now sold as Harness Feature Management and Experimentation (FME), and it is offered as part of a quoted Harness Enterprise plan rather than as a standalone subscription. For a Split customer that bought the product for experimentation, the practical effect is that the renewal is no longer a self-contained decision about one tool. Feature management and experimentation now sit inside a broader platform contract, so the price, term and exit conditions may be negotiated across modules you do not use.

Pricing for FME is by quotation, so there is no published list price to compare against GrowthBook or Unleash. Before you decide to stay or leave, ask Harness for the written scope of the FME module, the seat, project and environment counts it covers, the term length and any auto-renewal clause, and whether SSO, approvals and experiment analysis are included or priced separately. Also ask what the Enterprise plan does to your existing contract if you remove FME at renewal, and whether a shorter bridge term is available if you plan a parallel run.

Treat the data export as a contractual item, not a technical afterthought. Ask Harness to state in writing how you can retrieve flag definitions, targeting rules, experiment history and metric configurations, in what format, within what time window and at what cost after the term ends. Confirm whether an export is possible while the contract is still active, since a migration to self-hosted GrowthBook depends on it. Your own team should then check which of those assets must be rebuilt by hand, and set the decision date early enough that a side-by-side period is possible before the current contract expires.

What the free self-hosted GrowthBook edition limits

The self-hosted Open Source plan is free and runs the core GrowthBook application in your own infrastructure. Its limits are one project, unlimited users and unlimited API requests, so the constraint is how many separate experiment programs you run, not how many people sign in.

  • One project: All flags and experiments on this plan share a single project. Separate programs, such as checkout, search and pricing, each need their own project, so a team running several of them will reach the limit first.
  • Unlimited users: Seat count does not trigger a limit on this plan, so product, engineering and analytics staff can all work in the tool.
  • Unlimited API requests: The plan does not cap requests from your applications to the GrowthBook endpoints.
  • Self-managed operations: Your team runs the Docker image or the official Helm chart, the metadata database, backups and upgrades.

Illustrative example: a company with three active programs would need three projects, so it would need either a paid tier or a separate deployment for each program. Confirm the current project limit on the GrowthBook pricing page before you size the deployment.

Where experiment data lives and who controls it

Moving from Split to GrowthBook changes where flag definitions, assignment logs and experiment metrics live, and who can administer them. The cards below cover the decisions that follow from that change, from hosting and identity to the evidence an assessor will ask for.

Flag definitions and metadata

GrowthBook stores feature definitions, experiment configuration and user metadata in MongoDB or a compatible database that you run. Confirm which database service holds those records, who holds administrative credentials, and whether backups and point-in-time recovery cover it. In Split, this metadata sits in Split's hosted service or, after the move, in the Harness platform, so the control boundary moves with it.

Experiment results in your warehouse

GrowthBook runs read-only SELECT queries against your own warehouse, such as Snowflake, BigQuery or Postgres, and receives only aggregated statistics back. Raw exposure and event data therefore stays where your data team already governs it. Check which role the GrowthBook connection uses, which schemas it can read, and whether your data classification rules allow aggregates to leave the warehouse.

Hosting in your cloud or on premises

A self-hosted GrowthBook deployment runs as a single Docker image or through the official Helm chart in your own cloud account, data center or private network. This keeps the application, the statistics engine and file uploads under your control, with storage on local disks, Amazon S3 or Google Cloud Storage. GrowthBook Cloud is a different choice with different data residency terms, so confirm the hosting location and sub-processors in writing before you decide.

SSO and SCIM need Enterprise

The free self-hosted Open Source edition does not include SSO or SCIM, so user lifecycle changes, such as removing a departing engineer, have to be handled by hand. Self-hosted Enterprise adds SSO, SCIM and advanced permissioning, which are often required by identity policies. Ask your identity team which controls they need for administrator access to experiments and whether a manual process is acceptable for the interim.

Approval workflows and audit evidence

Approval workflows, safe rollouts and holdouts are part of self-hosted Enterprise, not the free edition. Without approvals, a single person can change a production flag and start an experiment, which is a weak point in change control. Before you migrate, define which changes need a second approver, how those approvals are recorded, and where the history is exported for review, since Split's audit history will not transfer automatically.

Compliance readiness work from DeployOpen

DeployOpen can plan and implement the GrowthBook deployment, document data flows and configure access, logging and backups so that evidence is available for an assessment. DeployOpen does not issue audit reports, attestations or certifications. Your auditor decides whether the controls and evidence are sufficient for your framework, so agree the evidence list with them before the work is scoped.

What drives the cost of Split versus self-hosted GrowthBook

The Harness FME side of this comparison is a single recurring line item inside a quoted Harness Enterprise contract, so the number you pay depends on the written quote rather than a public list. Ask the vendor to itemize FME as a module, state which modules and seat or usage units it is priced on, and confirm what renews automatically and what the notice period is. Ask separately whether experimentation, flags and any warehouse-connected analysis are priced in the same module, because that determines whether you can drop one part without renegotiating the whole contract.

Self-hosted GrowthBook replaces the license line with infrastructure and labor. Infrastructure covers compute for the bundled Next.js front end, Express API and Python statistics engine, a managed MongoDB or compatible metadata database as the docs suggest for production, file storage for uploads, and backups. The cost that is easiest to miss is warehouse query load: GrowthBook runs SELECT queries against your own warehouse for every analyzed experiment, so the bill from Snowflake, BigQuery or Databricks rises with experiment volume, metric count and analysis frequency. Confirm with your data platform team how those queries are billed and whether a dedicated compute pool is needed.

Two categories are one-time and two recur. One-time work is the migration itself, which includes recreating targeting, rebuilding metrics on the warehouse and running both systems side by side until results match. Recurring work is operations: upgrades (GrowthBook v5.1.0 was released on September 22, 2026, so plan for regular release review), patching the database and container images, backup testing, and on-call coverage. If you need SSO, SCIM, approval workflows, holdouts or safe rollouts, those sit in the paid self-hosted Enterprise tier, so add that license to the GrowthBook side. Ask any implementation partner for a fixed-scope written quote listing the metric rebuild, the warehouse connection and the parallel-run period as separate lines.

How a move from Split to GrowthBook proceeds

The sequence takes a Split or Harness FME account from contract review to a GrowthBook deployment where flags and experiments produce results that match the old system. Each phase has a named output, so the team can decide when to cut over. The steps below describe the order of work, not a fixed timeline.

  1. Confirm contract scope and export terms

    Before any technical work, review the Harness contract with procurement and legal to confirm which Split or FME modules are licensed, when access ends, and whether the agreement permits exporting flag definitions and experiment history. Ask Harness to confirm the export path that applies to your account, because a Split importer is not among the importers documented for GrowthBook, so you cannot assume one exists. Done when you have a written list of the modules in scope, the access end date, and the export method you will use.

  2. Export flag definitions and treatments

    Pull feature definitions, treatments, targeting rules, segments and environment settings out of Split or Harness FME using the Admin API and the Python tooling Harness documents for this purpose. Store the JSON or YAML output in version control so the team can compare it later. Done when every active split in production has a stored definition and you have checked the export against a sample of live flags in the console.

  3. Recreate features, targeting and segments in GrowthBook

    Map each Split treatment to a GrowthBook feature value and each targeting rule and segment to a GrowthBook rule or attribute condition. Expect hand work for anything the export does not carry across cleanly, such as custom segments or complex rule ordering, and record each manual change. The GrowthBook LaunchDarkly importer documentation warns that advanced setups can include cases it cannot handle, so treat any importer as a partial aid. Done when a reviewer can trace every production Split rule to a GrowthBook equivalent.

  4. Rebuild metrics against your warehouse

    Define the metrics your experiments depend on as queries against your own data source, such as Snowflake, BigQuery or another supported warehouse. GrowthBook runs read-only SELECT queries there and transmits only aggregated statistics, so the data team owns the event tables and the access grants. Done when each metric used in a past Split experiment has a GrowthBook definition that reads from the same source tables and the data team has signed off on the definitions.

  5. Swap SDKs in the application

    Replace the Split SDK calls in each application with the GrowthBook SDK for its language, and keep the flag keys stable so code paths and dashboards still line up. The importer does not change application code, so developers must make this switch in each service. Done when every service that previously called Split evaluates flags through GrowthBook in a non-production environment and the Split SDK is removed from the build.

  6. Run both systems side by side

    Run Split and GrowthBook in parallel for the same traffic or a controlled subset, comparing assignments, flag values and experiment results. Investigate every mismatch in bucketing, targeting or metric definitions before moving further, since differences in assignment logic can change experiment outcomes. Done when the two systems agree on assignment and the metric results you care about are within the tolerance your analysts have agreed in writing.

  7. Cut over and retire Split

    After parallel results agree, switch production traffic to GrowthBook, keep a read-only archive of the Split exports and experiment reports for audit and historical comparison, and confirm with Harness the end of access on the agreed date. Confirm with your compliance team which records must be kept and where. Done when production runs only on GrowthBook, the archive is stored under your retention policy, and the Split account is closed or downgraded as the contract allows.

Questions buyers ask before choosing GrowthBook over Split

What does switching from Split to GrowthBook cost?

The switch has two cost components: software and the one-time work of moving. GrowthBook's self-hosted Open Source plan is free with unlimited users, 1 project and unlimited API requests, according to the GrowthBook pricing page. The paid self-hosted Enterprise tier adds SSO and SCIM, advanced permissioning, approval workflows and holdouts, and is quoted. Your ongoing costs are infrastructure (MongoDB or a compatible database, the container host, and your data warehouse query load) and staff time. Ask Harness for the FME renewal quote, and ask DeployOpen for a fixed-scope quote built from your flag count, metric count and warehouses.

How long does a Split to GrowthBook migration take?

No duration is fixed by the vendor documentation, so the answer depends on the drivers you control: the number of flags, how many use targeting rules, segments and prerequisites, how many experiments are running, and how many warehouses your metrics read from. GrowthBook's LaunchDarkly importer documentation describes a preview step followed by importing items at about one second per flag, but the Statsig guide describes its importer as covering feature gates, dynamic configs and experiments, with metric sources in beta. Split is not covered by a supplied importer, so expect the export and recreation work to be manual. Ask DeployOpen for a written timeline after an inventory of your flags and experiments.

Can our own engineers run the migration without outside help?

Often yes, if you have a platform team that can run Docker or Kubernetes, administer a MongoDB database and grant read-only access to your warehouse. GrowthBook maintains an official Helm chart and a single Docker image bundling the front end, API and statistics engine, which lowers the setup burden. The harder parts are rebuilding targeting logic, defining metrics against your warehouse tables and swapping the Split SDK for a GrowthBook or OpenFeature-based SDK in every application. Consider outside help if you have many services, complex experiments or a tight release calendar. Ask DeployOpen to scope a fixed-scope engagement covering only the parts you choose.

What does the work need from our data and analytics team?

GrowthBook analyzes experiments against your own data source, running only SELECT queries and transmitting only aggregated statistics, so your data team owns the metric definitions. You will need to confirm which warehouse holds your exposure and conversion events (GrowthBook lists BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica), grant a read-only role, and rebuild each Split metric as a SQL-backed definition. Metrics that today live in Split's hosted analytics will need the most validation. Plan for a period where both tools run side by side until results match, and confirm the query cost in your warehouse with its provider.

Does GrowthBook fit a contract we signed through Harness?

GrowthBook is a separate product and is not sold as a Harness module, so it does not replace an FME line item inside a Harness Enterprise contract on its own. Harness announced its acquisition of Split on May 30, 2024, and FME is now sold through Harness, so the decision usually sits in your renewal calendar. Before you choose, read your Harness terms for notice periods and data export rights, and ask Harness what it will return or delete. If you move, ask DeployOpen to confirm the exit plan in writing, since the contract terms are yours to review with your legal team.

Is the free self-hosted GrowthBook edition enough for us?

The free edition suits a team with one project and no need for enterprise governance. The self-hosted Open Source plan allows 1 project, while Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Count your Split projects and workspaces, then check whether your SSO, approval and holdout requirements are in the free tier. Also note that the GrowthBook LICENSE places its enterprise directories under a separate Enterprise License, so confirm with your legal team which code you run.

What security and compliance evidence does the move need?

Self-hosting keeps flag definitions and experiment data inside your environment, and warehouse access stays read-only with aggregated results leaving the warehouse. You will need to document access controls for the GrowthBook admin, the database, secrets for the warehouse connection, backups and logging. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do. Ask your auditor which evidence they expect for the flag platform before you start.

How DeployOpen helps evaluate and migrate to GrowthBook

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For teams weighing Split against self-hosted GrowthBook, we start with a written scope that separates flag migration from experiment analysis, so you can decide with facts about your own environment.

How we scope

  • Inventory which Split or Harness FME flags, experiments and metrics your teams actually use today
  • Confirm which warehouse holds your event data and which GrowthBook data source would run the queries
  • Agree in writing which Enterprise-only features your approval, SSO and rollout processes need

How we build

  • Deploy GrowthBook in your own cloud account or data center, using its Docker image or Helm chart
  • Set up the MongoDB or compatible metadata store and file storage that your environment requires
  • Recreate targeting rules and experiments, then run parallel checks so GrowthBook results can be compared with Split results

How we hand over

  • Document the architecture, configuration, SDK swap steps and rollback path for your engineering teams
  • Provide evidence of configuration and testing that your compliance team and external auditors can review
  • Walk through the warehouse query setup, permissions and metric definitions with your analytics owners

How we support

  • Offer ongoing support, upgrades and continuous testing as a retainer after handover
  • Track GrowthBook release changes and plan upgrades in your environment on an agreed schedule
  • Continue to test the deployment and advise on Enterprise licensing questions as your needs change

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.