How to export your data from Split before the contract ends
Flag definitions and configurations can be pulled from Split through its documented Admin API and the Python tools Harness publishes for Split and Harness FME, with output in JSON or YAML. Experiment results, event history and user-level data are a separate exercise, and they need their own plan before the contract ends. This matters most when a renewal, the move onto the Harness platform or a data residency requirement puts a deadline on the work. Start by deciding which of these three groups you must keep, because each one takes a different route out.
The flag export is the easier part, but it still needs a review. Pull environments, feature definitions, treatments, targeting rules and segments, then check each file for the objects your applications depend on, such as default treatments and kill switches. In Unleash, environment import and export moves flag configurations as JSON, but segments and custom strategies are exported only as references, so you must recreate them in the target instance first. GrowthBook has no published importer for Split in the sources reviewed here, so plan to rebuild targeting and segments by hand, and log every rule you rewrite so it can be checked against the original.
Before any work starts, have your team or DeployOpen read the current Admin API and Python tool documentation from Harness and confirm which object types are included, which are excluded and what rate or size limits apply. Ask the vendor in writing for a data export from your account, including the format and retention of any event history. Record the result as a written scope item, because the answers decide whether you can finish before the contract ends. Keep the old system running until flag results in the new tool match the old ones for a full test cycle.
What you can export from Split and how
This table lists each Split data type, the export route, the output format and what to confirm before relying on it. Harness documents the Admin API and its Python tools for this work, but field-level detail for each object type should be checked against current Harness documentation for your account. Treat any object the export does not cover as a manual rebuild in GrowthBook or Unleash.
| Data type | Export method | Output format | What to confirm or limit |
|---|---|---|---|
| Feature flags and treatments | Admin API or Harness Python tools | JSON or YAML, as Harness documents | Confirm that treatment names, values and default treatment appear in one export |
| Targeting rules | Admin API or Harness Python tools | JSON or YAML, as Harness documents | Confirm that rule conditions, matchers and rule order are included in the schema |
| Segments | Admin API or Harness Python tools | JSON or YAML, as Harness documents | Confirm whether segment definitions export with membership or only as references |
| Environments | Admin API or Harness Python tools | JSON or YAML, as Harness documents | Confirm how per-environment rule sets are separated in the output |
| Traffic allocations | Admin API or Harness Python tools | JSON or YAML, as Harness documents | Confirm that percentage rollouts and traffic allocation values are exported per flag |
| Tags | Admin API or Harness Python tools | JSON or YAML, as Harness documents | Confirm tag export so ownership and lifecycle labels can carry over |
| Experiments | Admin API or Harness Python tools | JSON or YAML, as Harness documents | Confirm whether treatments and linked metrics export; plan to rebuild metrics on your own warehouse |
What does not export and how to handle it
Flag definitions are only part of what a team leaves Split with. The items below tend to stay in Split, live in your warehouse, or need to be recreated in the target, so plan for them before the cutover date. For each one, confirm the current behavior with Harness or Split support, since this page does not assume what their export tooling covers.
Historical experiment results
Past experiment readouts, significance calculations and decisions recorded in Split's metrics views are analysis outputs, not flag configuration. A team that moves to GrowthBook will recompute results from its own warehouse, so past readouts may not line up exactly with new ones. Keep a read-only copy of the final Split results, with the date range and metric names, in your documentation or data store before you turn off access.
Raw event and exposure history
Exposure and impression records show which users saw which treatment and when. Whether Split exposes these in a downloadable form depends on your plan and the Harness FME version you run, so confirm this in writing. If your events already flow to your own warehouse, the exposure history is already yours. If not, ask how long Split retains it and whether you can export it before the contract ends.
SDK keys and client credentials
Server-side and client-side SDK keys are tied to Split workspaces and environments and cannot be carried over. Every application that calls Split will need a new key from the target, plus a code change that swaps SDKs or adds an OpenFeature provider. Inventory every service, mobile build and front-end bundle that embeds a key, and plan the rollout so old and new keys do not collide during the parallel run.
User-level assignment history
Records of which individual user received which treatment at which time are a separate data set from the flag definitions. Targeting rules and percentages can be recreated, but past assignments are not replayed by the target. Stable bucketing matters here: if the target hashes users differently, some users may switch variants at cutover. Test assignment consistency on a sample of user IDs before you move traffic.
Audit logs and team permissions
Change history, who edited a flag and when, and role assignments belong to Split's administration layer. They are useful evidence for change management and access reviews. Export or screenshot the audit trail for the flags you are retiring, and map Split roles to the target's roles by hand, since Unleash Open Source and GrowthBook's free self-hosted edition limit the role and approval features you may be used to.
Metric and segment definitions in the warehouse
Metric definitions and segment logic live in Split and in the SQL or event rules your team wrote. Export the definitions you still need as text, and keep the SQL that computes them in your own repository. GrowthBook runs read-only SELECT queries against your own data source, so you will need to rebuild those metrics there and confirm they match Split's numbers during the parallel run.
What GrowthBook and Unleash accept on import
Before you export anything from Split, confirm what each target can actually load, because the answer decides how much of the work is a file transfer and how much is manual rebuilding. Unleash's import and export feature moves feature flag configurations as JSON between environments or between Unleash instances, so flag configurations can travel in bulk. Segments and custom strategies do not travel with them. They are exported only as references, which means every segment a flag depends on must already exist in the target Unleash instance before you import. Build your segment list from the Split export first, recreate those segments in Unleash, and only then load the flag JSON. Check the result against the Unleash import and export documentation for the exact file format your version expects.
GrowthBook's position is different. It documents a built-in importer for LaunchDarkly and a separate importer for Statsig, and the importer for Statsig reads environments, tags, segments, feature gates, dynamic configs and experiments through a Console API key. The material available to us does not document a Split importer for GrowthBook, so do not plan around one until GrowthBook confirms in writing that it supports Split exports for your flag types, targeting rules and experiments. Ask specifically whether it carries over fallback values, rollouts and prerequisites, and whether it handles the Split segment types you use. If there is no importer, your Split export becomes a specification for manual rebuilding, and the Statsig importer is a useful reference for the object types GrowthBook expects.
Whichever target you choose, an import brings over definitions only. It does not move assignment history, experiment results, event data or the metrics that were calculated in Split, and it does not change the code that calls the flags. Your application still has to replace the Split SDK with the GrowthBook or Unleash SDK, and each flag's evaluation must be verified in the new system before traffic is cut over. Assign an owner to the SDK change in each service, plan a parallel run where both systems return the same treatment for the same user, and record any flag whose imported behavior differs from the Split export so it is rebuilt or retired deliberately.
The export sequence, step by step, with verification at each stage
This sequence turns a Split or Harness FME account into a versioned, counted and mapped inventory, then rebuilds it in the target tool. Each stage ends with a check, so you know the export is complete before anything is recreated or switched over.
Inventory workspaces, environments and projects
Before exporting anything, list every workspace, environment and project in Split or Harness FME, along with the owner of each. Confirm the list with the teams that use each one, because stale environments often hold flags that production still evaluates. Done means you have a written inventory in which every item is marked as in use, archived or to be retired.
Create read-only Admin API credentials
Ask a Split or Harness administrator to issue an Admin API key with the narrowest read permissions available, and record who holds it and when it expires. Do not reuse a personal or write-capable key for the export. Check the key with a single read request for one environment, then confirm in the vendor's documentation that the key cannot create or modify flags.
Run the export tools and save raw files
Run the export tooling that Harness documents for Split data, once per environment, and write the output as JSON or YAML exactly as returned. Commit the raw files to a version-controlled repository without editing them, so the source of truth stays unchanged. Check that each environment produced its own file and that a second run against the same environment yields no differences.
Record counts of flags, segments and environments
Count the flags, segments, treatments, targeting rules and environments in the exported files, and write the totals per environment in a single record. Compare these totals with the counts shown in the Split or Harness interface. Done means the two sets of numbers match, or each gap has a documented explanation such as archived flags that the export omits.
Map each object to its target equivalent
Build a mapping table that assigns every Split object to a counterpart in GrowthBook or Unleash. Treatments become variants or feature values, segments become segments, and rules become targeting conditions or activation strategies, with each mismatch noted. Unleash imports need segments and custom strategies to exist in the target first, so mark those as prerequisites. Check that every row in the export has a target and an owner.
Recreate segments and dependent rules first
Create segments in the target system before any flag that references them, since flags that depend on missing segments will either fail or evaluate differently. Where a Split rule depends on another flag, recreate the dependency after the flag it relies on. Check each segment by comparing a sample of user keys, and confirm that the target returns the same membership as the Split segment for those keys.
Import or recreate flags in the target
Import the mapped flag definitions with the target's import feature or Admin API, or recreate them by hand for objects that do not map cleanly. Confirm whether GrowthBook or Unleash has an importer for Split specifically, because the documented importers cover other vendors. Check that each flag exists in the target, that default values match the export, and that flags with unsupported rules are logged for manual rebuild.
Compare counts and sample evaluations
Run both systems in parallel behind an abstraction layer, such as OpenFeature providers, and send a fixed sample of user keys through each. Compare the Split treatment with the target value for every flag, and investigate any mismatch before cutover. Done means counts match the inventory and the sampled evaluations agree, with each remaining difference recorded and accepted by the flag owner.
What to rebuild by hand for GrowthBook or Unleash
GrowthBook covers both flags and experiments, so the rebuild work centers on feature definitions and on reconnecting experiments to your own data. Exported Split definitions give you the flag names, treatments and split rules to reproduce, but the experiment layer depends on metrics and queries that live in your warehouse, not in the export. GrowthBook's documentation describes its analysis as running read-only SELECT queries against your data source and transmitting only aggregated statistics, so each experiment needs a working connection and metric definitions before results mean anything.
- Feature definitions and default values: Map each Split feature to a GrowthBook feature, including its value type and the default served when no rule matches.
- Targeting conditions and rollouts: Rebuild attribute-based rules, percentage rollouts and any allow lists by hand, since these are the constructs most often reshaped during import.
- Experiment configuration: Recreate each experiment's variations, traffic allocation and assignment attribute, then confirm which warehouse table holds the assignment and conversion events.
- Metrics and warehouse queries: Rewrite Split's hosted metrics as GrowthBook metric definitions that read from your warehouse, and test each query against known data.
- Segments and sticky bucketing: Check how Split segments and bucketing keys translate to attributes and sticky bucketing in your chosen edition.
Confirm each construct's mapping against the GrowthBook documentation for the version you deploy, and run both systems side by side until experiment results match.
Unleash models feature flags with activation strategies and strategy variants, and it has no built-in experiment analysis, so Split treatments are the main thing to map. Each Split treatment usually becomes a variant on a flag, and the targeting and rollout logic moves into activation strategies on each environment. Unleash's export and import tooling carries flag configurations as JSON, but segments and custom strategies are exported only as references, so they must exist in the target first. Open Source limits also shape the plan: 1 project and 2 environments per instance.
- Treatments to strategy variants: Convert each Split treatment and its weight into a variant with a matching name and weight, and check that the default variant matches the one served today.
- Targeting to activation strategies: Rebuild attribute conditions and percentage rollouts as activation strategies, since parameter names and operators may differ from Split's rule syntax.
- Segments created before import: Recreate every segment in the target instance first, because the export references them without carrying their definitions.
- Environments under Open Source: Map Split environments to Unleash environments, noting that Open Source allows only 2, so extra environments need a plan or an Enterprise license.
- Experiments and metrics: Plan a separate tool for experiments, since Unleash does not replace Split's experiment analysis.
Confirm each mapping against the Unleash documentation for your version, and note that Unleash OSS licensing and Edge support timelines may affect the design.
Questions teams ask before exporting from Split
How much effort does a full export from Split take?
The effort depends mainly on how many flags, segments and environments the account holds, and on how many of those use targeting rules that have no direct equivalent in the target tool. A small account with a handful of flags and one environment is mostly a copy-and-verify task. A large account with nested segments, dynamic configurations and many treatments adds mapping work for each item. Ask your team to inventory flags, segments, environments and rule types before agreeing on scope, because that inventory is what a quote should be built from. Export itself is quick compared with rebuilding and testing targeting in the new tool.
Can our own team run the export without outside help?
Often yes, if someone on the team can call the Split Admin API and read JSON, and if the account is small enough that manual recreation is manageable. Harness publishes Python tools for working with Split definitions, which reduces the scripting needed to pull them out. Outside help becomes more useful when the account has many segments, unusual rule combinations, or experiments whose metrics must be rebuilt on a warehouse. Confirm with Harness which export tools and API permissions apply to your Split or Harness FME tenant before you plan the work.
What do our engineers and product owners need to contribute?
Engineers need to own the SDK swap, the evaluation calls in each service, and any code that reads treatments as strings or depends on Split-specific behavior. Product owners need to confirm which flags are still live, which rollouts are finished, and which targeting rules encode business decisions rather than temporary tests. Plan for both groups to review the mapping of every active flag, since a rule that looks technical may carry a commercial or compliance meaning. Retire flags nobody owns rather than migrating them by default.
How long should a parallel run last, and what sets its length?
Length is set by the business cycle the flags serve, not by a fixed number of days. Run both systems side by side until every migrated flag has returned the same results for long enough to cover your normal traffic patterns, month-end processing and any release cadence that affects the flag. Experiments need the run to continue until the sample size and metric readings match the baseline you agreed. Decide the exit criteria in writing before the run starts, and confirm the expected duration with your own traffic data rather than a generic figure.
Is the export a one-time task or something we repeat?
The first full export is one-time, but teams usually repeat part of it. Flags and segments keep changing in Split while the migration is underway, so you need a delta check before cutover, and any change made during the parallel run must be copied to the new tool or frozen by policy. After cutover, the export is not needed again unless you later move between environments or instances. Keep the exported JSON as a versioned record, because it documents what the flags did at the time of migration.
What happens to experiments that are still running?
Running experiments should not be moved mid-flight without a decision. Options include letting them finish in Split or Harness FME, restarting them in the new platform with a clear note that prior results will not be comparable, or rebuilding metrics in a warehouse-based tool so the analysis continues. Experiment metrics in Split are often defined inside Split, so they must be rebuilt on your own data before results can be trusted. Set an end date for each experiment and confirm with your analysts how historical results will be archived.
Which parts of the export are hard to recreate by hand?
Segments, nested targeting rules, dependencies between flags and dynamic configurations usually take the most manual work. Unleash exports segments and custom strategies only as references, so those must exist in the target before any flag import, and this ordering is a common source of failed imports. In GrowthBook, the built-in importer reads LaunchDarkly rather than Split, so Split definitions need a custom export and mapping step. Ask for a sample migration of your most complex flags before committing to a timeline.
What to plan before the Split or Harness contract ends
The export is the easy part to start and the hard part to finish on time. These cards cover the decisions that set your deadline, your target license, your tier and your change freeze, and the records you keep afterward.
Export deadline against the notice period
Work backward from the date your Split or Harness access ends, not from the date you start migrating. Check the notice period, renewal terms and data retention window in your Harness agreement, and confirm with Harness whether flag history and experiment results remain readable after the contract ends. Schedule the export with enough room to validate the JSON and YAML outputs before that date.
Target license terms
Confirm the license of the platform you will run before you build on it. Unleash moved its server source to AGPLv3 starting with v8.0.0, while its official Docker images stay under Apache 2.0. GrowthBook is MIT outside its enterprise directories, so check which of those directories your edition touches with your legal team.
Paid tiers for SSO and approvals
Decide early which governance features you need, since they often drive the edition choice. Unleash Open Source is limited to 1 project and 2 environments, and SSO, SCIM, custom roles and change requests sit in Enterprise. GrowthBook's free self-hosted plan lacks SSO, SCIM, approval workflows and holdouts, which are listed for self-hosted Enterprise. Map each Split environment and approval step to a feature you have on the target.
Freeze on flag changes during cutover
Set a window in which no one edits flags, segments or treatments in Split while you export and recreate them. Without a freeze, the exported files describe a state that is already out of date when you import them. Name one owner who approves changes during the window and records any exception, so the target matches production on cutover day.
Retention of exports and results
Decide how long you keep the exported JSON and YAML files, the Admin API responses and any experiment results pulled from Split. Auditors and internal reviewers may ask what a flag returned on a given date, so store these artifacts with access controls and a retention period your compliance team sets. Confirm with Harness what history is available to download before access ends.
Parallel run and sign-off criteria
Agree in writing how long Split and the target will run side by side and what counts as a match. Compare evaluated treatments for a sample of users across both systems, then record the sign-off by the owners of each flag. Also decide who can switch the application SDK, since GrowthBook's importer documentation notes that the application still has to move from the LaunchDarkly SDK to a GrowthBook SDK after import.
How to verify the export matches production
Verification should not depend on trusting the export tool that produced the files. Start with object counts: record how many flags, segments, tags and environments exist in Split or Harness FME for each workspace and environment, then count the equivalent objects in GrowthBook or Unleash after the import. Any gap is a finding to explain before cutover, not a number to adjust. Keep the raw JSON or YAML files exactly as exported, with timestamps and the Admin API calls used, so the export itself can be reviewed later by someone who did not run it.
Next, diff the exported definitions against the target's configuration. Normalize field order and naming first (for example, comparing the treatments and rules structures from the source against the variants and activation strategies in the target), then review each difference by hand. Differences in identifiers are expected; differences in default treatments, rollout percentages, attribute names or segment membership are not. Behavioral checks come next: choose a sample of flags that cover your most consequential targeting, and evaluate them for representative user attributes in both systems. Log every mismatch with the flag, attribute set, expected result and actual result, and do not close an item until the cause is known. Expect some scenarios, such as custom or unusual rule types, to need manual rebuilding.
A matching configuration does not prove that metrics or experiment results carry over. Metric definitions, event mappings, attribution windows and statistical settings live in your warehouse and in the experimentation layer, so compare those separately. Run the same experiment query against the same warehouse tables in both tools and confirm the aggregated results agree within the tolerance your analysts set. Ask your experimentation vendor or the GrowthBook documentation which metric types the importer covers, and confirm that scope in your own environment before relying on it.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Split export, we start from a written, fixed scope that names the flags, environments, segments and experiments to move, then build the extraction and recreation work in your environment.
How we scope
- We inventory Split workspaces, environments, feature flags, segments and experiments that must leave Split or Harness FME.
- We agree in writing which targeting rules, treatments and segments will be recreated by hand in GrowthBook or Unleash.
- We define which Admin API exports, JSON or YAML outputs and Harness tooling are in scope for the engagement.
How we build
- We run the export tooling against your Split or Harness FME account and store the raw definitions in your own infrastructure.
- We rebuild flags, environments and segments in the target platform and document every rule that could not be carried over automatically.
- We test that evaluated values in the target system match the exported Split treatments for a defined set of test identities.
How we hand over
- You receive the export scripts, the exported definitions, a mapping table from Split concepts to target concepts, and the gap list.
- You receive runbooks for SDK swaps in your applications and for running both systems side by side until results agree.
- You receive documentation of the self-hosted deployment, backups and access controls, so your team can operate the platform after handover.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm which Split and Harness FME export features your account supports before you sign the scope.
