Migrate to FlagTGL
FlagTGL supports guided migrations from LaunchDarkly, Unleash, ConfigCat, and Flagsmith. A migration copies feature-management configuration into FlagTGL; it does not connect the two systems at evaluation time and it does not silently enable Slack, Datadog, webhooks, or other operational integrations.
Start with a preview, migrate into a non-production FlagTGL organization, compare evaluations with representative contexts, and cut over one environment at a time. Keep the source platform available until production behavior and rollback have been verified.
Choose the right guide
- LaunchDarkly has the deepest migration path, including flags, multi-context targeting, prerequisites, lifecycle and selected control-plane resources.
- Unleash maps activation strategies, constraints, variants, rollouts, and reusable segments into FlagTGL's portable evaluation model.
- ConfigCat maps configs, environments, typed settings, targeting rules, percentage options, and segments.
- Flagsmith maps projects, environments, feature states, remote-config values, segments, and segment overrides.
- Validation and cutover is the production checklist for every source.
Capability matrix
Preserved means the concept has a direct FlagTGL representation. Transformed means the source data is retained in a coherent FlagTGL form but its exact provider semantics may differ. Not moved means customers must recreate, reconnect, or retain it outside FlagTGL.
| Capability | LaunchDarkly | Unleash | ConfigCat | Flagsmith |
|---|---|---|---|---|
| Projects and environments | Preserved | Preserved; keys normalized | Config becomes project; keys normalized | Preserved; keys normalized |
| Boolean flags | Preserved | Preserved | Preserved as typed settings | Preserved |
| String/number/JSON values | Preserved | Strategy variants transformed | Typed settings preserved | Remote-config scalar values transformed |
| Environment state/default | Preserved | Preserved | Served value becomes default variation | Preserved |
| Direct context targets | Preserved by context kind | Not moved | Not a source concept | Identity overrides not moved |
| Targeting rules | Preserved | Strategies transformed | Rules transformed | Segment overrides transformed |
| Percentage rollout | Preserved, including source bucket metadata | Weights preserved; bucketing transformed | Weights preserved; bucketing transformed | Multivariate rollout not moved |
| Reusable segments | Preserved with environment caveat | Constraints preserved | Conditions transformed | Trait rules preserved |
| Prerequisites/dependencies | Preserved | Not moved | Prerequisite comparators not moved | Not moved |
| Tags | Preserved | Preserved | Not moved | Not moved |
| Experiments and release controls | Selected resources retained as lossless payloads | Not moved | Not moved | Not moved |
| Members, roles, SSO, audit history | Not moved | Not moved | Not moved | Not moved |
| Source API/SDK credentials | Never moved | Never moved | Never moved | Never moved |
| Operational integrations | Imported configuration remains inactive and must be reviewed | Not moved | Not moved | Not moved |
What “1:1 where it makes sense” means
Flag keys, variation values, environment state, ordered rules, and segment membership logic are copied when FlagTGL can evaluate the same concept coherently. FlagTGL does not emulate provider-specific execution engines. Custom Unleash strategies, ConfigCat confidential or semantic-version comparators, Flagsmith identity state, and LaunchDarkly Big Segment membership are examples that require an explicit redesign or external data source.
Percentage membership can change when moving from a provider with a different hashing algorithm, salt, or stickiness attribute. Treat rollout percentages as distribution parity, not guaranteed user-by-user cohort parity, unless the provider guide explicitly says the source bucket metadata is preserved.
Safe migration workflow
- Inventory projects, environments, flags, segments, SDKs, credentials, integrations, and governance resources.
- Create a least-privilege, read-only credential where the source supports it.
- In Organization → Migrations, restrict the first run to one project or config.
- Select Preview changes and reconcile counts before writing anything.
- Migrate with Clear existing flags disabled.
- Follow the validation and cutover checklist.
- Rerun the migration and confirm resources are updated or unchanged rather than duplicated.
- Disconnect the migration source and revoke its credential when the move is complete.
Idempotency and ownership
Migrations match projects, environments, flags, and segments by their target keys. Rerunning a migration updates matching imported resources. After the first run, changes can therefore be overwritten by a later source sync.
Clear existing flags deletes flags in matched FlagTGL projects before importing them. It does not mean “only clear resources created by this provider,” and it is not a general reset of environments, segments, or control-plane resources. Leave it off unless replacement is deliberate and independently backed up.
Security and data handling
Migration credentials are masked in the UI and encrypted at rest using authenticated encryption. Use short-lived or dedicated credentials, restrict their source scope, avoid personal administrator credentials where possible, and revoke them after cutover. FlagTGL generates new target SDK credentials; source SDK keys and API tokens are never copied.
Need help planning a complex migration? Contact [email protected].