Migrate from Split to Unleash

Migrate from Split to Unleash: what the move involves

For a team that uses Split mostly for flags and gradual rollouts, the migration is largely a definitions and integration exercise. The work concentrates in three places: translating Split targeting rules into Unleash activation strategies and segments, replacing Split SDK calls with Unleash SDK calls (or with OpenFeature providers if you want the application code to stay vendor-neutral), and laying out environments within the limits of the free edition. Platform or application teams usually do this work themselves, often with an implementation partner for the export scripts, the environment design and the parallel run. Effort and risk scale with the number of flags, the number of segments and the number of services that embed a Split SDK. Before you estimate anything, count those three things in your own Split workspace, and note which flags have been stale for a long time, because those are often better retired than migrated.

Split's Admin API is the starting point for the export, and the work of mapping the output follows from there. Treatments become Unleash variants on a flag, and rollout percentages and attribute-based rules generally map to activation strategies, but you should check each flag against its actual targeting, since Split's rule engine and Unleash's strategy parameters do not line up one to one. Unleash's import and export feature moves flag configurations as JSON, but segments and custom strategies travel only as references, so each segment must exist in the target instance before you import. Plan that segment rebuild as a distinct step. On environments, Unleash Open Source allows 1 project and 2 environments per instance, so map your Split environments and workspaces to that layout first, and confirm with Unleash which features you would need from Enterprise, such as multiple projects, SSO or change requests, if your current setup depends on them.

The safest cutover runs both systems in parallel behind an abstraction layer, with a short list of flags moved first and compared between the two tools before the rest follow. Confirm two things early: the Unleash edition and deployment model you will run, and whether your design relies on a caching layer. The open-source version of Unleash Edge reaches end of life on December 31, 2026, and Unleash recommends that OSS Edge users move to an Enterprise plan, so any design that depends on it needs an explicit decision. Also confirm the licensing position with your legal team, because Unleash v8.0.0 moved the server source to AGPLv3 while the official Docker images remain under Apache 2.0. Experiments are a separate workload. Unleash is a flag and rollout tool, so if Split also measures A/B tests for you, choose the experimentation tool in parallel rather than expecting Unleash to replace it.

Which Split capabilities map to Unleash and which need rework

This table compares the Split capabilities that release-focused teams use most with their Unleash equivalents. Read the status column first: Clean means a direct mapping, Needs rework means the logic must be rebuilt, and Gap means Unleash Open Source does not cover it or another tool is needed. Confirm each Split setting in your own account before planning the import.

Capability	Split side	Unleash equivalent	Status
Release flags on and off	Feature flag with on and off treatments	Feature toggle with an activation strategy	Clean
Multivariate treatments	Named treatments with traffic weights	Strategy variants on the flag	Needs rework: map each treatment, weight and SDK reference to a variant
Targeting rules	Attribute-based rules evaluated per treatment	Activation strategies with constraints, evaluated in order	Needs rework: rules are rewritten per strategy and tested again
Segments	Reusable key or attribute groups used in rules	Segments referenced by activation strategies	Needs rework: segments must exist in the target before a JSON import
Gradual rollouts	Percentage ramps through traffic allocation	Rollout strategy with percentage and stickiness settings	Needs rework: recreate the ramp schedule and confirm stickiness
Environments and projects	Multiple environments within a workspace	Environments and projects, limited to 1 project and 2 environments in Open Source	Gap if you need more than one project or two environments
Roles, approvals, SSO and SCIM	Role-based access, approval flows and identity sync by plan	Basic roles in Open Source; SSO, SCIM, custom roles and change requests in Enterprise	Gap in Open Source: confirm which controls your Split plan uses
SDK caching and delivery	Split Proxy and Synchronizer for self-hosted delivery	Unleash Edge as the caching layer between SDKs and the API	Needs rework: open-source Edge reaches end of life on December 31, 2026
Experiments and statistical analysis	Experiments with metrics and significance results	No equivalent in Unleash	Gap: pair Unleash with a separate experimentation tool

What exports cleanly from Split and what must be recreated

Split flag definitions can be pulled out as structured data, but Unleash does not take everything across in one step. The cards below separate what the Admin API export and Unleash import carry over from what you must rebuild by hand, and what changes in the SDKs and the edge layer.

Flag definitions from the Split Admin API

The Split Admin API can return feature flag definitions, including treatments, targeting rules and configurations, as JSON or YAML. Use this export as the working inventory of every flag you intend to move. For illustrative purposes, a flag with three treatments and a percentage rollout should appear in the export with each treatment and its split. Confirm the exact export fields and which environments are included in your own Split or Harness account before you script anything, because field names can differ between the Split and Harness FME interfaces.

Unleash import and export of flag JSON

Unleash moves feature flag configuration between environments or instances as JSON. Use it to load the flags you have mapped into the target environment. Segments and custom strategies are exported only as references, so they must already exist in Unleash before the import runs. Plan the import order: create segments first, then import the flags that reference them, then check each flag in the admin UI.

Segments and custom strategies to recreate

Segments and custom strategies do not travel as full definitions, so they are the most common source of failed imports. Build a list of every Split segment referenced by a targeting rule, then recreate each one in Unleash with the same membership logic. Confirm each segment's attributes in your Split export, since targeting keys and attribute names must match what your application sends to the Unleash SDK.

Treatments mapped to strategy variants

Split treatments are the values a flag returns, and they map to Unleash strategy variants. Each variant needs a name, weight and payload. Check that every treatment in the export has a matching variant and that the weights add up to the split you intended. A treatment that carried a configuration object in Split should carry its payload in the variant, and your application code must read the same keys.

SDK swap to OpenFeature or Unleash SDKs

Application code that calls Split SDKs must change to an Unleash SDK or to an OpenFeature provider. OpenFeature keeps the evaluation calls in your code independent of the vendor, which helps if you may move again. Replace each Split client call one service at a time, and compare evaluations in both systems during the parallel run before you remove the Split SDK.

Split Proxy and Synchronizer replaced by Unleash Edge

If you run the Split Synchronizer and Proxy for scale, their role moves to Unleash Edge, a caching layer between SDKs and the Unleash API. The open-source version of Edge reaches end of life on December 31, 2026, so a design that depends on it needs a dated plan. Ask Unleash which edition fits your traffic and whether an Enterprise plan is required for your scale, and confirm this with the vendor before you commit.

Migration sequence from inventory to decommission

This sequence moves Split flag definitions into Unleash in controlled stages, so each flag is proven in a non-production environment before production traffic moves. It ends with decommissioning Split only after every environment has run cleanly on Unleash and OpenFeature.

Inventory flags, treatments and segments in Split
Start by listing every feature flag (split), its treatments, its targeting rules, its segments and the environments and SDK keys where it runs. Export the definitions through the Split Admin API so the inventory comes from the source of truth, not from memory. Mark each flag as a release toggle, a gradual rollout, a kill switch or an experiment. Experiments move to a separate tool, so they are tagged here and excluded from the Unleash scope. The output is an inventory sheet with one row per flag, its owner, its environments and its status. The step is done when the product owner and a platform engineer have both signed off that the sheet matches what the SDKs actually evaluate in production.
Map treatments and targeting to Unleash strategies
For each flag in scope, translate Split treatments into Unleash strategy variants and Split targeting rules into activation strategies with their constraints. Note any rule that has no direct equivalent, such as a custom attribute the Unleash SDK does not send, and decide how the application will supply it. Confirm the details against the current Unleash documentation for your version, since Unleash v8.2.0 was released on September 8, 2026. The output is a mapping document that lists each Split construct, its Unleash target and any manual change. The step is done when every treatment in the inventory has an Unleash target or a documented reason it is being retired.
Stand up Unleash in a non-production environment
Deploy the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI on port 4242, in a staging network inside your own infrastructure. Plan the environment count against Unleash Open Source limits of one project and two environments, so the pilot and the first production target fit within the free tier. Decide early whether you need Unleash Enterprise features such as SSO, SCIM or change requests, because those drive the edition choice. The output is a running non-production instance with backups tested and access restricted to the migration team. The step is done when a test user can log in, create a flag and read it through an SDK.
Recreate segments before importing flags
Unleash exports and imports carry segments and custom strategies only as references, so each segment must exist in the target before any flag that uses it is imported. Recreate every Split segment in Unleash using the mapping from the earlier step, and record the segment names exactly as they appear in the flag definitions. Keep a check list that pairs each Split segment with its Unleash segment and the flags that depend on it. The output is a segment register and a test import file that contains one pilot flag. The step is done when the pilot import completes without missing-reference errors.
Pilot one low-risk flag in a non-production environment
Choose a flag with a simple boolean or two-treatment rule and a low blast radius, and import it into the non-production environment using the Unleash import feature. Wire a test service to the Unleash SDK, evaluate the flag for a set of known test users, and compare the results with the Split values for the same users. Record any mismatch and fix the mapping or the attribute feed before going further. The output is a pilot log with the test cases, the expected and actual results, and the fixes applied. The step is done when results match for every test case and the owner accepts the mapping rules.
Run Split and Unleash in parallel behind OpenFeature
Place an abstraction layer such as the CNCF OpenFeature API between application code and the flag SDKs, so that a provider can switch from Split to Unleash without changing business logic. Import the remaining in-scope flags into Unleash and keep Split as the active provider. Run both systems side by side, and log every evaluation from each provider for the same request context. OpenFeature lists SDKs for the main server and client languages, so confirm that your stack has a supported provider for each service. The output is a comparison report that shows agreement rates per flag and lists every discrepancy. The step is done when discrepancies are explained and closed for every flag that will move.
Cut over one environment at a time
Move flags into production in stages, one environment at a time, starting with the least sensitive environment and ending with production. For each environment, switch the OpenFeature provider to Unleash, watch the evaluation logs and error rates, and keep the Split provider configured so you can switch back quickly. Record the switch time, the operator and the observed results. Plan for Unleash Edge if you rely on a caching layer at scale, and note that the open-source version of Edge reaches end of life on December 31, 2026, so confirm the Enterprise path before choosing that design. The output is a cutover log with one entry per environment. The step is done when each environment has run on Unleash for an agreed period and no open defects remain.
Decommission Split SDKs and the Split account
After every environment has run on Unleash, remove the Split SDK dependencies from the codebase and delete the Split provider configuration. Revoke Split SDK keys, remove service accounts and archive the final Admin API export for audit and rollback reference. Confirm with finance and procurement the notice terms that apply to your Split or Harness FME agreement before you cancel anything, and ask your vendor to confirm data retention after termination. The output is a decommission record listing removed SDKs, revoked keys, the archived export and the contract confirmation. The step is done when no service makes a Split call in logs for a full monitoring cycle.

Fitting environments into Unleash Open Source limits

Unleash Open Source allows one project, two environments and 5,000 feature flags per instance, with basic roles. Before you map anything, count the Split workspaces, environments and flags the migration has to carry. If your flags fit in one project with a development and a production environment, the free edition may be enough. If you run more environments (for example, separate staging, QA and production lanes, illustrative), you have three routes: consolidate environments and flags into the two allowed, run a separate Unleash instance for each workload group, or buy Enterprise. Each route carries different costs in people and operations. Make the choice before you import, because Unleash import and export moves flag configurations between environments and instances, but segments and custom strategies must already exist in the target.

Unleash Enterprise removes the project and environment caps and adds single sign-on, SCIM provisioning, project and custom roles, user groups and change requests. These are the controls that usually matter when a Split account relies on per-team access rules or approval steps for production changes. Check which Enterprise plan and hosting model apply to your self-hosted deployment. The Unleash pricing page lists Pay-As-You-Go at a per-seat rate with a five-seat minimum for self-hosted, and Custom Enterprise on annual contracts. Ask for a written quote that states the seat count, the number of projects and environments covered, and the support scope, so you can compare it with the cost of running extra instances.

From v8.0.0, the server source in the main Unleash repository and the unleash-server npm package is licensed under AGPLv3. The official open-source Docker images remain under Apache 2.0, and the SDKs keep their permissive licenses. Unleash states that running the official images without modification is not affected by the change. Modifying the server and offering it to others as a public or commercial service carries obligations: you must publish the modified source or buy a commercial license. Internal platform teams that fork the server, or that host Unleash for other business units or customers, should treat this as a question for counsel. Have legal review your intended use before you choose a deployment model, and read Unleash's AGPLv3 announcement alongside that review.

What drives migration cost and duration

This table lists the factors that change how much work and spend a Split to Unleash move requires, with a note on how to keep each one under control. Read it as a checklist to bring to a scoping conversation, since the largest variables are the ones you can measure in your own Split account before any quote is written. Unleash Open Source is free to self-host, but the Pay-As-You-Go plan lists $75 per seat per month with a 5-seat minimum for self-hosted, so environment needs often decide the licensing path.

Driver	Why it matters	How to keep it down
Flag and segment count	Each flag and segment must be exported, recreated and tested in Unleash, so volume sets most of the build effort.	Export definitions first, retire stale flags in Split, and migrate only live flags and segments that still gate behavior.
Targeting complexity	Split treatments with nested attribute rules, percentage splits and allowlists must map to Unleash activation strategies and variants by hand where the export does not carry logic over.	Simplify rules before migration and document each one in a mapping sheet so reviewers can check equivalence.
SDK integrations and languages	Every service that calls Split needs its SDK swapped or wrapped, and each language has its own evaluation behavior to verify.	Introduce an OpenFeature abstraction layer so application code changes once, then move services in waves.
Environment layout versus Open Source limits	Unleash Open Source allows 1 project and 2 environments per instance. More Split environments or projects mean either consolidating or paying for a higher tier.	Count Split environments and projects before design. Confirm with Unleash whether consolidation or a paid tier is needed, and ask for the per-seat cost in writing.
Edge design for scale	Open-source Edge reaches end of life on December 31, 2026, so high-traffic designs need an Enterprise path or a replacement caching plan decided early.	Ask Unleash which Edge edition fits your traffic, and plan the caching layer before load testing begins.
Parallel-run length	Running Split and Unleash side by side doubles evaluation and reporting work until flag results and rollout behavior match.	Set exit criteria per flag group in advance, such as matching targeting outcomes in staging, so the parallel period has a defined end.
Experimentation tooling	Split experiments do not move into Unleash. A separate experimentation tool adds its own data, metric and warehouse work.	Decide early which experiments continue, and scope that work separately from the flag migration.
Internal test effort	Your team must verify targeting, rollout percentages and kill switches across every environment and SDK before cutover.	Build a test matrix from the export, automate evaluation checks, and reuse the same tests for the parallel run.

Why experiments need a separate tool after moving to Unleash

Unleash covers feature flags and rollouts, so the experimentation side of Split does not move with your flag definitions. Split's metrics, experiment results and statistical analysis need their own platform, and for most teams that means self-hosted GrowthBook, which runs read-only SELECT queries against your warehouse so event data stays in your environment. Plan this as a second migration with its own sequence, not as a step inside the Unleash cutover. Confirm first whether any of your Split experiments are still live, because a flag that controls an active test cannot be switched off in Unleash until the test's analysis has been decided.

Before you decide anything about experiment tooling, inventory your Split experiments and classify each one. For every experiment, decide whether its history is exported as a record, archived as a static report with its metric definitions and results, or re-run in the new experimentation tool under a fresh hypothesis. Historical results are rarely directly comparable to new ones because metric definitions, attribution windows and data sources often change during a move. Ask your analytics lead which results must remain auditable for product, financial or regulatory reasons, since those are the ones worth archiving in full.

Treat the experiment tool choice as a separate project with its own owner, budget and timeline. Run a short evaluation against a handful of representative experiments, and confirm with each candidate vendor which features are included in its free self-hosted edition, how its warehouse connection works and who maintains the SDK integration. Keep the Split experiments running until the new tool reproduces known results on the same data. Ending Split experiments before that check leaves you without a baseline to compare against.

What usually goes wrong in a Split to Unleash move

Most failed flag migrations break on sequence, defaults and limits rather than on the flag logic itself. The cards below cover the risks that tend to surface late, with a prevention step and a check to run before cutover.

Importing flags before segments exist

Unleash exports and imports reference segments and custom strategies without carrying their full definitions, so the target must already contain them. If a flag is imported first, its targeting can reference segments that do not exist yet. Create every segment in the target instance, confirm the names match the Split segment names exactly, and only then import flag definitions. Check that each imported flag's segment references resolve before enabling anything.

Silent targeting drift between strategies

Split targeting rules, such as attribute matches and percentage splits, do not translate one to one into Unleash activation strategies. Hashing and bucketing can differ, so a user may land in a different group after the move. Prevent this by mapping each Split rule to a named Unleash strategy in a written table, then compare evaluation results for a fixed sample of user identifiers in both systems. Any mismatch should be resolved before users are moved.

Edge end of life affecting scale designs

Split's Proxy and Synchronizer layer has no direct equivalent in an Unleash design, and teams often plan to use Unleash Edge for caching. The open-source version of Edge reaches end of life on December 31, 2026, so a design that depends on it for scale will need a different plan or an Enterprise plan. Confirm the caching architecture and its support status with Unleash before committing the target design, and load test the SDK path at expected traffic.

Exceeding Open Source project limits

Unleash Open Source allows one project and two environments per instance. Split workspaces often hold several projects, and staging, QA and production environments can exceed the limit during the move. Inventory every Split workspace and environment before starting, decide which ones are in scope for Unleash, and confirm whether consolidation into one project or a licensing change is needed. Check the count against the limit before any import runs.

SDK version mismatches

Moving from Split SDKs to Unleash SDKs changes client code, configuration keys and how evaluations are reported. Teams often upgrade the server but leave older application SDKs in place, or mix SDK versions across services that evaluate the same flag. Inventory every service and its SDK version, pin the target SDK versions in a single list, and run a staging pass where each service evaluates flags against the new instance. Confirm that the Unleash server version and SDK versions you pin are documented as compatible.

Treating Split treatments as variants without defaults

A Split treatment is returned for every evaluation, including when a flag is missing or the SDK cannot reach its data source. Unleash variants only return when a variant is configured, and the fallback value your code receives depends on how the SDK call is written. Map each treatment to an Unleash variant, record the default value each call site expects, and test what happens when the flag is absent or the server is unreachable. Confirm the fallback behavior in the target SDK before cutover.

How the migration differs by starting point

A small team with a few dozen flags in one Split environment usually has the simplest migration. The work is mostly a flag inventory, a rebuild of targeting rules in one Unleash project and a plan for two environments. Open Source Unleash allows 1 project and 2 environments, so a single-product team can often fit inside it. Illustrative example: a team with one web app, a production environment and a staging environment would map its flags into the one project and keep both environments.

Single project fit: Confirm that all flags belong to one product area, since Open Source allows only 1 project.
Environment count: Map Split environments to at most 2 Unleash environments, or confirm that Enterprise is needed.
Strategy coverage: Rebuild simple percentage and user-list rules as activation strategies and check each one in staging.
Flag ceiling: Check the pricing page limit of 5,000 feature flags per instance against your inventory.
Operations: Run one PostgreSQL 15 or later database and one server on port 4242, and document who can change flags.

Before you start, export your Split definitions and count the flags, environments and segments you actually use, then confirm that Open Source limits fit that count.",

Questions teams ask before moving from Split to Unleash

How much effort does a move from Split to Unleash take, and what drives it?

The effort depends mostly on how many flags, segments and targeting rules you have, and on how many environments and services read them. Flag definitions can be exported as JSON, but segments and custom strategies are exported only as references, so each one must be recreated in Unleash before any import runs. Teams with many treatments that map to multivariate logic, or with flags wired into dozens of services, carry more SDK and testing work than teams with a short list of release toggles. Ask any provider to inventory flags by type, owner and consuming service before quoting.

How long does a Split to Unleash migration take?

No researched duration applies to this migration, so treat any timeline you receive as provisional until it is tied to a written scope. The schedule is set by the flag inventory, the number of SDK integrations to change, the number of segments to rebuild, and how long you run both systems in parallel before cutting over. Parallel running is the step most often underestimated, because you need evidence that evaluations match across both platforms. Ask for a milestone plan that names each environment and the exit criteria for cutover.

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

Your engineers need to own the SDK changes in each service, because the application code must call Unleash instead of Split. Platform or DevOps staff must run the Unleash server against PostgreSQL 15 or later and expose the server and admin UI on port 4242. Product owners need to confirm which flags are still in use and which should be retired rather than carried over. Security or compliance staff should review who holds admin access in the new tool, since role features differ by edition.

Can our team migrate from Split to Unleash without outside help?

A team with strong backend engineering and a small, well-documented flag set can often do the migration in-house, using Unleash's import and export documentation and its LaunchDarkly migration guide as a pattern. Outside help is more useful when flags sit across many services, when you need an abstraction layer to run both systems side by side, or when you need evidence for an audit. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure, typically under a fixed scope agreed in writing before work starts. Compare an in-house plan with a written scope before deciding.

Is Unleash Open Source enough, or do we need Enterprise?

Unleash Open Source is limited to 1 project and 2 environments with basic roles, and its pricing page lists 5,000 feature flags per instance. Teams with one product and a dev, staging and production pipeline may fit within those limits. Enterprise adds unlimited projects and environments, single sign-on, SCIM provisioning, project and custom roles, user groups and change requests. Check your environment count, your SSO requirement and your approval workflow against these limits before you commit. Also note that Unleash v8.0.0 moved the server source to AGPLv3, so legal review of how you modify and offer the software is worth doing.

What happens to our experiments when we move flags to Unleash?

Unleash handles feature flags and rollouts, not experiment analysis, so experiments need a separate tool. Before moving, list each Split experiment, its metrics, its data source and any running tests that must finish. Then choose an experimentation platform that fits your data, such as GrowthBook, which runs read-only queries against warehouses like Snowflake and BigQuery. Keep the exposure logic consistent between the flag tool and the experiment tool, so users see the same treatment in both. Plan to finish or deliberately close running experiments before cutover, so historical results remain available.

What does the Unleash Edge end of life mean for our design?

The open-source version of Unleash Edge, the caching layer between SDKs and the Unleash API, reaches end of life on December 31, 2026. Unleash recommends that OSS Edge users move to an Enterprise plan. If your design relies on Edge to scale SDK traffic, you need a decision on whether to pay for Enterprise, redesign caching, or accept the risk of running an unsupported component. Review this before the migration, because it changes the architecture you would be building. Confirm the current status with Unleash's documentation, since the date is set by the vendor.

Official sources for the Split to Unleash migration

Start with the Unleash documentation on import and export, because it defines what a move between environments or instances actually carries. Flag configurations move as JSON, but segments and custom strategies are exported only as references, so every segment must exist in the target Unleash instance before import. Read the page with a Split export in hand and mark each targeting rule and segment that will need to be recreated by hand. Then read the Unleash OSS vs Enterprise comparison against your environment count. Open Source allows 1 project and 2 environments with basic roles, so a Split workspace that uses more stages needs a decision about Enterprise or a consolidated environment model before cutover.

Use the Unleash blog guide to migrating from LaunchDarkly as a pattern reference, not as a Split procedure. It maps targeting rules to activation strategies, multivariate flags to strategy variants and segments to segments, and it recommends running both systems in parallel behind an abstraction layer. Split's treatments, splits and Admin API fields differ from LaunchDarkly's model, so confirm each field mapping directly with Harness, since the vendor owns the export schema and any changes after the move to Harness. Check the Unleash Edge documentation too: the open-source Edge version reaches end of life on December 31, 2026, so a Split proxy replacement designed around OSS Edge needs a plan for that date.

Read the Unleash AGPLv3 post with your legal team before you choose a deployment pattern. Starting with v8.0.0, the server source code moved to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Unleash states that running those images unmodified is not affected, but modifying the server and offering it as a service triggers source publication or a commercial license. Ask Unleash directly whether any custom strategy, plugin or proxy you build counts as a modification in your case, and record the answer. Finally, confirm current limits and tier details on the Unleash pricing page at the time of your quote, because the pricing units and the 5,000 flag figure shown there can change.

How DeployOpen scopes and runs the migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Split to Unleash move, we agree the scope in writing before work starts, then build and hand over the Unleash environment in your own cloud account, data center or air-gapped network.

How we scope

Inventory every Split flag, treatment, segment and environment that teams actually use in production today
Confirm which Split targeting rules map to Unleash strategies and which need custom work
Agree in writing whether Unleash Open Source limits or an Enterprise plan fit your environment count
Decide with you where experiments move, since Unleash does not run experiment analysis

How we build

Deploy the official Unleash server image against PostgreSQL in your infrastructure, listening on port 4242
Export Split definitions through the Admin API and recreate flags, variants and segments in Unleash
Plan the Unleash Edge design with its open-source end-of-life date of December 31, 2026 in mind
Swap SDK calls behind an abstraction layer so application code is not tied to a single vendor

How we hand over

Document each flag mapping, the parity checks performed and the environment configuration in your repositories
Walk your platform, release and product teams through flag ownership, strategy changes and rollout procedures
Provide runbooks for backups, upgrades and the Unleash license terms that apply to your deployment
Record which Split features were retired or replaced so your compliance and change records stay accurate

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the handover
Schedule upgrades against Unleash release notes so your team reviews changes before they reach production
Re-run configuration checks after each upgrade to confirm flags still evaluate as expected
Confirm retainer terms, response expectations and included services with us in the written quote

Migrate from Split to Unleash