Guides and playbooks
Migration from Other Feature Flag Providers
Map common feature-flag concepts neutrally so your team can swap providers without rewriting the whole release model.
| Common concept | Zenmanage equivalent |
|---|---|
| Feature flag | Flag with target value and optional rules |
| Environment | Environment with server/mobile/client keys and an isolated evaluation boundary |
| User or entity context | Context with type, identifier, name, and attributes |
| Audience or segment | Segment-style targeting via reusable context matching |
| Percentage rollout | Deterministic bucketing by context identifier and rollout percentage |
Cutover strategy
Keep the migration neutral and mechanical. Replace SDK initialization, map context shape, confirm server/mobile/client key handling, then validate a small number of representative flags before broader rollout. Avoid changing rollout policy and provider at the same time unless you want two sources of risk in one release.
Next step
Take the next integration step in your own stack.
Start with the quickstart that matches your runtime, then return to the reference pages when you need exact request and payload details.