OpenFeature Multi-Vendor Feature Flag Operations Playbook

Date: 2026-03-25
Category: knowledge
Scope: How to use OpenFeature to reduce feature-flag vendor lock-in without creating rollout inconsistency, observability blind spots, or migration chaos.

1) Why this matters

Many teams adopt feature flags through one vendor SDK, then discover three painful truths later:

• rollout logic leaks into app code,
• migration cost grows with every new flag,
• experimentation and ops telemetry become provider-specific.

OpenFeature helps standardize the application-side contract (evaluation API, context shape, hooks, events), so provider choice becomes an infrastructure concern rather than a codebase rewrite.

Important nuance: OpenFeature removes lock-in mostly at the SDK call-site layer. You still need discipline for flag definitions, targeting schemas, and analytics parity.

2) OpenFeature mental model (practical)

Think in 4 layers:

1. App code calls OpenFeature API (getBooleanValue, etc.).
2. Provider translates those calls to a real flag backend (vendor SDK, REST, local file, flagd, etc.).
3. Evaluation context carries targeting attributes.
4. Hooks + events add cross-cutting behavior (audit, metrics, validation, cache freshness).

From spec details worth operationalizing:

• Providers should return rich resolution details (value/variant/reason/error metadata).
• Context merge precedence is explicit (global -> transaction -> client -> invocation -> before-hooks).
• Provider lifecycle/events include readiness, errors, stale configuration, and config changes.

3) What OpenFeature standardizes vs what it does not

Standardized (good portability)

• evaluation API call shape,
• typed resolution flow,
• provider interface pattern,
• hooks lifecycle stages (before/after/error/finally),
• provider event handling model.

Not standardized (you must govern)

• vendor-side flag schema and naming,
• targeting rule semantics and edge-case behavior,
• experiment stat engine details,
• governance workflow and approvals,
• deprecation/removal hygiene.

Implication: portability succeeds only if your internal flag taxonomy is cleaner than your vendor UI.

4) Multi-provider strategy for migration (low drama)

OpenFeature ecosystem patterns allow running providers in parallel (primary + fallback) while migrating.

Phase A — Stabilize interface

• Wrap all app evaluations with OpenFeature first.
• Ban direct vendor SDK calls in product code.

Phase B — Parallel read

• Evaluate from both old and new providers (shadow mode for selected flags).
• Log parity deltas (value, variant, reason).

Phase C — Controlled cutover

• Route selected flags to new provider first; fallback to old provider.
• Keep event-level observability for stale/error transitions.

Phase D — Retirement

• Remove old-provider fallback only after parity + SLO gates pass for sustained period.

5) Evaluation context contract (where migrations usually fail)

Most migration bugs are context bugs, not SDK bugs.

Define a versioned context schema:

• targetingKey (stable subject key)
• cohort keys (plan_tier, region, org_id)
• environment fields (service, cluster, release_ring)
• request-scoped fields (request_id, optional)

Rules:

• no PII unless absolutely required,
• explicit data types (string/number/boolean/date/structure),
• publish context dictionary + owner,
• treat context key changes as breaking changes.

6) Hook patterns that pay off immediately

Before hook

• inject mandatory context fields,
• reject missing targetingKey for user-targeted flags,
• normalize type mismatches.

After hook

• emit evaluation metric (flag, variant, reason, provider, latency).

Error hook

• classify provider failures (transient vs fatal),
• attach fallback reason for downstream analysis.

Finally hook

• guarantee trace closure and log hygiene even on exceptions.

This gives you vendor-independent telemetry and better incident triage.

7) Reliability guardrails (production)

• Prefer provider initialization methods that wait for readiness before serving traffic paths that depend on flags.
• Alert on PROVIDER_ERROR and PROVIDER_STALE rate, not just absolute count.
• Define explicit fallback policy per flag class:
  • safety/kill-switch flags: fail-closed (safe default),
  • UX experiment flags: fail-open to control/baseline.
• Track reason distribution drift (TARGETING_MATCH, DEFAULT, ERROR, STALE) to catch silent regressions.

8) Governance model to avoid “flag entropy”

For every new flag, require:

• owner + team,
• purpose (release/experiment/ops permission),
• expiry/removal date,
• fallback default rationale,
• dependency graph notes.

Add CI lint checks:

• block duplicate or ambiguous flag keys,
• block stale flags past expiry,
• block missing owner metadata.

OpenFeature makes runtime evaluation portable; governance makes the system survivable.

9) Migration scorecard (use weekly)

Track these KPIs:

• % evaluations via OpenFeature wrapper (target: 100%),
• % flags dual-read parity clean (target: >99.9% for stable flags),
• provider error/stale incident count,
• number of direct vendor SDK call-sites remaining,
• mean age of temporary flags.

If parity is high but stale/error events rise, your app abstraction is healthy but provider ops are not.

10) Common pitfalls

• Assuming “OpenFeature adopted” means migration is done.
• Ignoring variant/reason parity and checking only boolean value parity.
• Letting vendor-specific targeting logic creep into hooks.
• Skipping context schema versioning.
• Never deleting temporary migration flags.

11) References

• OpenFeature overview: https://openfeature.dev/
• OpenFeature spec (providers): https://openfeature.dev/specification/sections/providers/
• OpenFeature spec (evaluation context): https://openfeature.dev/specification/sections/evaluation-context/
• OpenFeature spec (hooks): https://openfeature.dev/specification/sections/hooks/
• OpenFeature spec (events): https://openfeature.dev/specification/sections/events/
• OpenFeature appendix (in-memory provider, multi-provider): https://openfeature.dev/specification/appendix-a/
• flagd project: https://github.com/open-feature/flagd

One-line takeaway

OpenFeature is the portability layer; your real moat is disciplined context schema + hook-driven observability + strict flag lifecycle governance.