Migrate from Unleash

FlagTGL reads Unleash through the Admin API using an Admin API token and your hosted or self-hosted instance URL. The API path is intentional: Unleash's documented JSON export includes flags, strategies, variants, and segment references, but does not include segment definitions or custom-strategy definitions. FlagTGL fetches reusable segments separately.

What moves

Unleash	FlagTGL	Transformation
Project	Project	Project ID becomes a lowercase URL-safe key
Environment	Environment	Name becomes the key; missing colors receive a neutral default
Feature flag	Flag	Name becomes the flag key; description and tags retained
Enabled state	Environment state	Disabled serves the first/off variation
Boolean activation strategy	Targeting rule serving true	No matching strategy falls through to false
Strategy constraints	Rule clauses	Portable string and numeric operators are normalized
Strategy variants and payloads	Typed variations	Payload value is used when present; otherwise variant name is used
Gradual rollout	Percentage rollout	Weights retained and normalized to FlagTGL's scale
Segment	Project segment	Name, description, and constraints retained; strategy references become segment-match clauses

Unleash describes a segment as reusable strategy constraints and an activation strategy as the rule that decides access. See Segments and Activation strategies.

Differences that require review

• Standard constraints map directly only for IN, NOT_IN/inversion, contains, starts-with, ends-with, and numeric greater/less comparisons. Date, semantic-version, custom, and other provider-specific operators must be recreated and tested.
• A custom strategy's executable behavior is not imported. Its available constraints can become clauses, but the strategy name is descriptive only.
• Source stickiness fields and hashing are not preserved. Portable rollouts bucket on the FlagTGL user key, so the percentage is retained but individual users may enter a different cohort.
• Variants declared in different environments are merged into one project-wide ordered variation list. Review cases where the same variant name has different payload types or values by environment.
• Feature dependencies, release plans/templates, change requests, safeguards, impact metrics, custom context-field definitions, stale/completed state, and archived history are not moved.
• Users, service accounts, roles, groups, SSO, audit events, API tokens, client keys, and integrations are not moved.
• Source SDKs and tokens cannot be reused as FlagTGL credentials. Replace the Unleash SDK or evaluation call with a supported FlagTGL SDK/API during cutover.

Run the migration

1. Create a dedicated Unleash Admin API token with access only to the intended projects where your Unleash edition supports that restriction.
2. Open Organization → Migrations → Unleash.
3. Enter the instance base URL, including any hosted instance path, and the token.
4. Optionally scope by exact project ID or name, then save the migration source.
5. Preview and reconcile project, environment, flag, and segment counts.
6. Migrate into a non-production FlagTGL organization and run the validation checklist.

For boolean flags, test a context that matches each activation strategy and one that matches none. For variants, compare both the returned typed value and distribution; do not assume source cohort identity survives the move.