For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Sign inTry it free
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
DocsGuidesSDKsIntegrationsAPI docsTutorialsFlagship blog
  • Get started
    • Overview
    • Onboarding
    • Get started
    • Launch Insights
    • LaunchDarkly architecture
    • LaunchDarkly vocabulary
  • AgentControl
    • AgentControl
    • Manage AgentControl
  • Feature flags
    • Create flags
    • Target with flags
    • Flag templates
      • Custom flags
      • Release flags
      • Kill switch flags
      • Experiment flags
      • AI prompt flags
      • AI model flags
      • Migration flags
        • Creating migration flags
        • Targeting with migration flags
        • Migration flag metrics
    • Manage flags
    • Code references
    • Contexts
    • Segments
  • Releases
    • Releasing features with LaunchDarkly
    • Release policies
    • Percentage rollouts
    • Progressive rollouts
    • Guarded rollouts
    • Feature monitoring
    • Release pipelines
    • Engineering insights
    • Release management tools
    • Applications and app versions
    • Change history
    • Restoring previous flag versions
  • Observability
    • Observability
    • Session replay
    • Error monitoring
    • Logs
    • Traces
    • Observability metrics
    • Product analytics events
    • LLM observability
    • Alerts
    • Dashboards
    • Service map
    • Vega for auto-remediation
    • Observability MCP server
    • Search specification
    • Observability settings
    • Observability integrations
  • Experimentation
    • Experimentation
    • Experiment metric types
    • Experiment configuration
    • Managing experiments
    • Analyzing experiments
    • Multi-armed bandits
    • Holdouts
  • Metrics and events
    • Metrics in LaunchDarkly
    • Creating metrics
    • Metric groups
    • Events
    • Autogenerated metrics
  • Warehouse native
    • Warehouse native metrics
    • Setting up external warehouses
    • Creating experiments using warehouse native metrics
  • Infrastructure
    • Connect apps and services to LaunchDarkly
    • LaunchDarkly in China and Pakistan
    • LaunchDarkly in the European Union (EU)
    • LaunchDarkly in federal environments
    • Public IP list
  • Your account
    • Projects
    • Views
    • Environments
    • Tags
    • Teams
    • Members
    • Roles
    • Account security
    • Feature previews
    • Billing and usage
    • Changelog
Sign inTry it free
LogoLogo
On this page
  • Overview
  • Targeting variations and stages
  • Targeting cohorts
  • Targeting contexts
  • Migration flags’ off variations
  • Understanding restrictions for migration flags with six stages
  • Understanding potential migration issues
Feature flagsFlag templatesMigration flags

Targeting with migration flags

Was this page helpful?
Previous

Migration flag metrics

Next
Built with

Overview

This topic explains how to target contexts with migration flags.

Targeting variations and stages

The different stages of a migration flag are expressed by the flag’s variations. Migration flags have built-in variations that you cannot edit, because they are linked to the migration’s stages. To progress through stages in a migration, adjust the percentage rollout to serve a different variation to a larger group, until 100% of contexts receive the same variation. We recommend progressing through the stages in the order they’re presented.

Targeting cohorts

Migration flag cohorts are analogous to the targeting rules for other types of feature flags. The default cohort is analogous to the default rule.

You can target cohorts in mostly the same ways you target rules, but cohorts always serve a percentage rollout. This helps visualize the progress of a migration. To learn more about rollouts, read Percentage rollouts.

You must specify a default cohort that this flag targets when the contexts specified in it are not a part of any other cohort. We recommend allocating 100% of this cohort in the “off” stage.

Here’s how to create a cohort:

  1. Navigate to a migration flag’s Targeting tab.
  2. Click the + icon and choose “Target segments” or “Build a custom rule.”
  3. Configure the cohort’s targeting information. To learn more, read Target with flags.
  4. In the “Serve” section, allocate the cohort into flag variations by percentages between 0 and one hundred. The total number in all stages must equal one hundred.

The cohort creation menu for a six-stage migration flag.

The cohort creation menu for a six-stage migration flag.

Targeting contexts

You cannot target individual contexts with a migration flag. If you need to target an individual context, create a cohort that contains only that context.

Migration flags’ off variations

The off variation for a migration flag is always off. This ensures that migrations always begin in the correct stage.

Understanding restrictions for migration flags with six stages

Migrations with six stages require you to specify a context kind to represent how the migrated data is partitioned. This context kind only targets contexts for the migration flag.

Migration flags with six stages have the following restrictions:

  • When you adjust a rollout, it will only affect keys for the context kind you designated for the six-stage migration
  • You can only create cohort clauses that reference that context kind
  • Cohorts cannot use the segmentMatch operator because segments can reference other context kinds
  • You cannot add prerequisites, because they can reference other context kinds

To learn more about when to use two, four, or six-stage migrations, read Performing multi-stage migrations with migration flags.

Understanding potential migration issues

Some targeting actions may create issues that could impact your data integrity. If a scenario like this occurs, a warning appears when you try to save.

Examples of actions that may cause safety issues are:

  • Adding a cohort that causes reads from the new system when a later cohort is not backfilled or in the off stage
  • Removing a cohort that is not backfilled or in the off stage when a later cohort causes reads
  • Reordering a cohort that is not backfilled or in the off stage when a later cohort (from its old position) causes reads from the new system

You can also use the REST API: Get migration safety issues