Split vs Unleash

The commercial side is a quoted Harness contract, and Feature Management and Experimentation is sold as a module within it, so the price is set by the modules, seats and usage tiers written into that quote rather than by a public list. Ask Harness or your account team to itemize the FME module, any other Harness Enterprise modules bundled in, the seat or usage basis, the support tier, and the renewal and uplift terms. Also ask whether the quote covers SSO, approvals and environment limits, since those features often sit in higher tiers. Recurring fees are the main cost on this side, and they repeat for every term you renew.

The Unleash Open Source edition has no license fee, and the Unleash pricing page lists it as free and self-hosted with 1 project, 2 environments and 5,000 feature flags per instance. The cost you still carry is the infrastructure, operations and any paid features you need. If you need more than one project or two environments, or capabilities such as single sign-on, SCIM provisioning or change requests, the Enterprise route applies. Pay-As-You-Go for self-hosted is listed at $75 per seat per month with a 5-seat minimum, and Custom Enterprise is sold on annual contracts. Confirm current terms on the pricing page before budgeting.

Pay-As-You-Go self-hosted pricing is charged per seat per month, with a listed minimum of 5 seats, so the recurring cost scales with the number of people who need admin access. As an illustrative calculation only, five seats at the listed rate would be 5 times $75 per month, before any tax or contract terms. Costs drop if fewer people hold editing rights and most users work through read-only access or the API. Ask whether the seat definition covers viewers, service accounts and automation tokens, because that changes the count.

A self-hosted Unleash deployment needs a server running the unleash-server image, a PostgreSQL 15 or later database, and network paths from your applications to the server. The getting started guide shows the server and admin UI listening on port 4242. Infrastructure cost comes from compute, database storage and backups, load balancing, TLS certificates, monitoring and the hosting environment, whether that is your cloud account, a data center or an air-gapped network. These costs recur monthly and grow with environment count and SDK traffic. Ask your platform team to size them against your own environments rather than relying on a generic figure.

Unleash Edge is a caching layer between SDKs and the Unleash API, and it is useful when many clients poll the server. The open-source version of Edge enters end of life on December 31, 2026, and Unleash recommends that OSS Edge users move to an Enterprise plan. Plan for that as a recurring licensing decision, or design your architecture so the Edge tier is replaceable. Ask Unleash whether Edge is included in the plan you are quoted, and ask your engineers to measure SDK polling volume before choosing a caching design.

Your team pays for operations: applying Unleash upgrades, patching the operating system and PostgreSQL, rotating credentials, testing backups and watching availability. These costs are recurring and depend on how many people you can assign and how often you release. The Unleash v8.2.0 release on September 8, 2026 is an example of the upgrade cadence to plan for. A support retainer from an implementation partner can cover upgrades and monitoring, and DeployOpen offers ongoing support and upgrades as retainers, priced from a written scope.

Migration is mostly one-time labor: exporting Split definitions, recreating targeting rules as activation strategies, mapping treatments to strategy variants, moving segments, and running both systems in parallel while SDKs are swapped. Cost rises with the number of flags, segments, environments and SDKs in use, and with how much of Split's configuration lives in code. Unleash's documentation notes that segments and custom strategies must exist in the target before an import. Ask any implementer for a written scope that lists flag counts, environments, SDK languages and the parallel-run period, and ask who owns the cutover decision.

Request one written comparison with separate lines for each cost category:

• Harness quote: FME module, other bundled modules, seats or usage basis, support tier, renewal terms.
• Unleash: edition, seat count if Pay-As-You-Go or Custom Enterprise, Edge arrangement, and what happens after Edge reaches end of life.
• Infrastructure: server, PostgreSQL, backups, monitoring and environments, sized by your platform team.
• Labor: migration scope, parallel-run period, operations and upgrade coverage.

Separate one-time costs such as migration from recurring ones such as licenses, seats, infrastructure and support, and compare both options over the same number of years.

The effort depends mainly on how many flags, segments and targeting rules Split holds, and how many of them are actively used. Each flag has to be mapped to an Unleash activation strategy, each Split treatment that varies by user needs an Unleash strategy variant, and each segment must be rebuilt. Unleash's import and export feature moves flag configurations as JSON, but segments and custom strategies are exported only as references, so they must exist in the target before import. Ask DeployOpen or your own team to inventory flags by age, owner and last evaluation before estimating, because stale flags are usually the cheapest to retire and the costliest to convert.

A team with platform engineering experience and access to the Split Admin API can usually export definitions and rebuild flags in Unleash without a partner, provided the flag count is modest and the targeting logic is simple. Outside help becomes more useful when flags are wired deep into application code, when segments are shared across many services, or when the team lacks time to run both systems in parallel. Unleash publishes a migration guide that recommends exporting definitions as JSON, recreating them through the Admin API or the import feature, and running both systems behind an abstraction layer. DeployOpen plans and implements this kind of work under a written, fixed scope if you prefer to hand it over.

Engineers own the SDK swap, the abstraction layer and the removal of old flag checks once a flag is retired. Product owners and flag owners must confirm which rollouts are still live, which audiences each flag targets and which flags can be deleted rather than copied. In practice this means:

• Engineers: replace Split SDK calls, wire an OpenFeature provider or equivalent abstraction, and test evaluations in each environment.
• Product owners: sign off on targeting for each live flag and approve retirement dates.
• Platform staff: provision Unleash, manage PostgreSQL and roles, and set access control.

Without named owners for each flag, the inventory stalls, so agree on owners before the export starts.

The parallel period should end when your own validation criteria are met, not on a calendar date set by a vendor. Useful criteria include evaluation results that match between the two systems for every migrated flag, no unexplained differences in targeting across a full business cycle your team chooses, and a rollback path tested for each flag still in use. Define those criteria in writing before cutover and have the flag owners sign them off. Ask any implementation partner to tie its scope to these criteria rather than to a fixed duration.

Unleash is a feature flag system and does not run experiments or compute statistical results, so Split experiments need a separate tool before you retire Split. Keep active experiments running in Split until they conclude, export their definitions and results for your records, and decide whether to rebuild the analysis in GrowthBook or another tool. The GrowthBook sibling guide covers the experimentation side in more detail. Confirm with your analytics owner which experiment history must be retained for audit or business reasons before you cancel.

Yes, if your design uses the open-source version of Unleash Edge to cache flag evaluations for SDKs at scale. Unleash states that the open-source version of Edge entered long-term support on December 12, 2025 and reaches end of life on December 31, 2026, and it recommends that OSS Edge users move to an Enterprise plan. Plan the caching layer as a decision point: either adopt a supported Edge option under the commercial plan, or design an alternative caching path and test it under production load. Confirm the current support terms with Unleash before you commit, because they set the cost of the caching layer.

Starting with Unleash v8.0.0, the server source code moved from Apache 2.0 to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Unleash states that running those images without modifying the source is not affected. If your team modifies Unleash and offers it to others as a public or commercial service, the AGPLv3 terms require publishing the source or buying a commercial license. Have your legal team review the terms against your intended use, especially if you plan to fork or patch the server.

Unleash Open Source allows 1 project and 2 environments per instance, with basic roles. If Split's workspace uses more environments, or your teams need separate projects, change requests, SSO or SCIM provisioning, you will need Unleash Enterprise or a different structure. Count your current environments and projects before you design the instance. Unleash's pricing page lists Pay-As-You-Go self-hosted pricing per seat per month with a 5-seat minimum, and Custom Enterprise plans on annual contracts. Ask Unleash for a written quote that matches your seat count and hosting model.