What you can export from LaunchDarkly, and what stays behind
If a renewal, a pricing change or a residency requirement forces you to leave LaunchDarkly, you can pull your flag, segment, environment and project definitions through the versioned REST API, authenticated with an access token in the Authorization header. Live flag evaluation and custom events can be streamed out through the Data Export add-on, but history from before the export starts is not backfilled. Plan the migration around those two paths, because they cover different data and run on different timelines. For definitions, create a token with the permissions your export needs and confirm it works against the right base URL: the default app host, the EU host for EU accounts, or the federal host for federal accounts. SDK keys and client-side IDs cannot be used for this purpose. Store the JSON you pull as an artifact you can review, since it is the most portable record of targeting rules, variations, segments and prerequisites. Confirm with LaunchDarkly which API fields and resource types your plan exposes before you rely on the export as complete.
For evaluation and custom event data, Data Export sends flag evaluation events for contexts only when a flag's "Send detailed events to data export destinations" setting is on or when the flag is part of an experiment. If you need evaluation history for analysis, check that setting on each flag now, because events that were never sent cannot be recovered later. Data Export also retries delivery five times over 30 minutes when a destination does not acknowledge an event, so confirm your receiving pipeline is available for that window and monitor for gaps. Treat the cutover date as a hard line in your data plan. Anything that happened before the export was enabled stays in LaunchDarkly, so archive or query the existing experiment results while your access is still active, and record the flags and experiments that depend on that history. Ask LaunchDarkly to confirm any export limits, retention terms and the contractual access you keep after termination, since those details sit in your agreement rather than in public documentation.
Which LaunchDarkly data types export, by method and format
This table compares each LaunchDarkly data type by the method that can pull it, the format it arrives in and the limits that apply. Read each row against your own export plan, and treat any cell marked for verification as a check to run in your account before you rely on it. The main takeaway is that definitions come out through the REST API as JSON, while evaluation and custom events only arrive going forward through Data Export.
| Data type | REST API (JSON) | Data Export (live stream) |
|---|---|---|
| Feature flags and flag status | Flag definitions and on or off status are readable through the REST API with an access token | Not applicable; flags are not sent as a stream |
| Segments | Readable through the REST API, so the definitions can be recreated in the target system | Not applicable |
| Environments and projects | Readable through the REST API as the structure that flags and segments belong to | Not applicable |
| Audit logs | Readable through the REST API; confirm the retention window and pagination in your account | Not applicable |
| Flag evaluation events | Not returned by the REST API | Sent only for contexts when the flag's detailed events setting is on or the flag is in an experiment; no historical backfill |
| Custom events | Not returned by the REST API | Exported live; confirm the event schema and the destination format in your account |
| Authentication | Access token in the Authorization header; SDK keys and client-side IDs are not accepted | Configured per destination; confirm the credentials each destination needs |
| Endpoint variants | Standard API for most accounts, for EU accounts and for federal accounts | Confirm the destination region matches the account region before enabling |
| Delivery failure handling | Not applicable; requests are made on demand by your script | Retries five times over 30 minutes if a destination does not acknowledge an event; plan for events outside that window |
Why history, unsent events and SDK-side state do not leave
Exporting from LaunchDarkly is not one switch. Data Export streams live events only, flag evaluations are sent selectively, and the SDK credentials in your applications cannot read flag definitions. Each gap below shapes what you can move, and when you need to start capturing data.
No historical backfill
Data Export sends live data and does not backfill history, so the destination only holds events from the point the stream was switched on. Any evaluation or custom event recorded before that date stays in LaunchDarkly. For teams planning a migration, that means enabling the stream early, before the cutover date, so there is a usable baseline to compare against. Ask LaunchDarkly to confirm the exact start behavior for your account and plan.
Selective flag evaluation events
Flag evaluations are only sent for contexts when a flag has the detailed events setting turned on or when the flag is part of an experiment. A default export therefore misses most evaluations for flags that are not in experiments. Review each flag that matters for audit or analysis and decide whether its detailed events should be enabled before you rely on the stream as a record of what users saw.
Delivery retries and gaps
If a destination does not acknowledge an event, LaunchDarkly retries five times over 30 minutes. An outage on your receiving side that lasts longer than that window can leave events undelivered. Check your destination's availability, monitor for gaps in event timestamps, and record in your runbook how you would reconcile a missing window before you decommission LaunchDarkly.
SDK keys cannot read definitions
Server SDK keys and client-side IDs cannot authenticate to the REST API, so the applications in production cannot be used to pull flag, segment or environment definitions. Export definitions with a dedicated access token that has the minimum role needed, and store it in your secrets manager. Rotate or revoke it once the export is complete so that no long-lived credential remains.
Keep your own evaluation log
Because history is not backfilled and default evaluations are not sent, a team that needs a defensible record of flag decisions should log evaluations in its own pipeline during the parallel-run period. Capture the flag key, variation, context key and timestamp. This is an illustrative pattern, and it adds storage and PII review work that your privacy team should approve before you start.
Export audit logs before termination
The REST API exposes audit logs, which record configuration changes such as who edited a targeting rule and when. Audit history is the hardest record to reconstruct later, so pull it in full before you end the subscription. Confirm with LaunchDarkly how far back the API returns entries for your account, and store the export with your change management evidence.
How to run a complete export in the right order
This sequence produces a complete, verified copy of your LaunchDarkly definitions and a live stream of evaluation data, so you can check each layer against the console before you rely on it.
Create a scoped access token for the export
A LaunchDarkly administrator creates a personal or service access token with read permissions for the projects and environments you plan to export, and stores it in your secrets manager. The REST API authenticates with this token in the Authorization header, so SDK keys and client-side IDs will not work. Done means a single test call to the API returns your project list with the expected count when compared against the console.
Export projects and environments as JSON
Your platform team calls the projects and environments endpoints of the LaunchDarkly REST API and saves each response as a versioned JSON file in a repository you control. Use the EU or federal API host if your account is on one of those instances. Verify by matching the project and environment keys and names in the files against the console, and record the exported date and the token owner alongside them.
Export flags and segments per environment
For each project and environment, export feature flag definitions and segment definitions as JSON, including targeting rules, variations, prerequisites and off values. Keep the files separated by environment because the same flag key can carry different rules in production and staging. Verify by counting flags and segments per environment and spot-checking several multivariate flags, confirming that each variation value matches what the console shows.
Capture audit logs for the change history
Export audit log entries through the REST API for the period you need to retain, then store them with the flag definitions. Audit logs record who changed what and when, which is the evidence most often requested during an audit review and is not reconstructed by any destination later. Verify by confirming the entry count for a known recent change matches the console and that timestamps are in the expected time zone.
Configure Data Export to a destination you control
In LaunchDarkly, set up Data Export to send events to a destination in your own infrastructure. Turn on the detailed events setting only for flags whose evaluation history you need, because LaunchDarkly sends flag evaluation events for contexts only when that setting is on or the flag is in an experiment. Remember that export is live: it does not backfill history, so the stream starts from the moment you enable it.
Run both exports in parallel and check acknowledgments
Let the definition exports keep running on a schedule while Data Export streams live events into your destination. Confirm that the destination acknowledges events, and watch for failed deliveries, because LaunchDarkly retries five times over 30 minutes before a destination is left behind. Done means your destination's event counts for a sample flag roughly match LaunchDarkly's own counts for the same window, and the gap is documented.
Record the gaps and sign off the snapshot
Write down what the export does not carry, including the missing pre-enablement evaluation history, any flags or segments your token could not read, and any settings the API does not return. Have the flag owner and a second engineer compare a sample of flags against the console and sign the snapshot as complete for each environment. The signed record becomes the baseline for the migration and for any later reconciliation.
Which export path fits your situation: definitions, events or both
Use this path when the goal is to move flag logic, segments and environments to a new platform and you do not need historical evaluation data. You export definitions through the LaunchDarkly REST API using an access token in the Authorization header, then map them to the target. The REST API exposes feature flags, flag status, segments, environments and projects, which covers the configuration most migrations need.
- What you get: flag definitions, targeting rules, variations, segments, environments and projects as JSON you can store and review.
- What it leaves out: evaluation history, custom event data and the audit trail as a dataset you can replay elsewhere.
- What the receiving platform needs: segments and context fields created before flags reference them, and a mapping for each targeting rule type.
- Importers: Flagsmith and GrowthBook offer built-in LaunchDarkly importers, but do not assume they copy everything. Check each imported flag by hand.
- Mapping reference: the Unleash migration guide maps targeting rules to activation strategies, multivariate flags to variants and prerequisites to flag dependencies.
Before you start, confirm with your team which environments and projects are in scope, and whether any flags depend on context attributes the target must recreate first.
Use this path when a compliance team, auditor or analytics owner needs a record of how flags were evaluated. LaunchDarkly Data Export sends flag evaluation events and custom events to destinations you configure, so the history is captured as it happens. It does not reconstruct past events, so the export only holds data from the time you enable it.
- What gets sent: flag evaluation events for contexts only when a flag has the 'Send detailed events to data export destinations' setting on, or when the flag is part of an experiment.
- What it leaves out: history from before the export was enabled, because LaunchDarkly exports live data without backfilling.
- Delivery behavior: if a destination does not acknowledge an event, LaunchDarkly retries five times over 30 minutes. Plan for a destination that can accept and store the stream.
- What the receiving platform needs: a durable store with retention that matches your policy, and a way to join events to flag keys and versions.
- Gaps to confirm: check with LaunchDarkly which event types your plan includes and which fields each destination receives.
If an auditor needs a complete history for a fixed period, confirm the export start date now, because earlier evaluations cannot be recovered from LaunchDarkly through this path.
Use this path when you are leaving LaunchDarkly entirely and need both the configuration and the data that supports it. A full exit runs two tracks in parallel: definitions moved through the REST API, and live event data captured through Data Export. Plan both tracks as a single project with one owner, because the cutover depends on each track finishing in the right order.
- Start the event export early: because Data Export does not backfill, every day without it is history you cannot recover from LaunchDarkly.
- Move definitions second: recreate segments and context fields in the target before flags that reference them, as the Unleash migration guide recommends.
- Run both systems in parallel: the same guide suggests an abstraction layer so you can switch flag sources per service during cutover.
- Accept the gaps: neither track gives you a complete record of past evaluations, and importers may skip advanced setups.
- Plan the SDK change: every application still needs its LaunchDarkly SDK replaced or wrapped, which takes development effort that no export tool performs for you.
Before you commit, ask your implementation partner or platform team to write down which data you will lose, who signs off on that loss, and how you will keep the export running until the last service has moved.
What to plan before the LaunchDarkly contract ends
Exporting from LaunchDarkly is a timing problem as much as a technical one. The items below sequence the contract, the export, the archives, parallel running and what the vendor keeps, so the data you need is captured while access still works.
Confirm the end date and notice terms
Read the contract for the termination date, the notice period and any auto-renewal clause, then put those dates on the migration plan. Ask LaunchDarkly in writing which accounts, projects and environments fall under the agreement, including any federal or EU account that uses a different API host. Your export window is bounded by the date your API access ends, so treat that date as the deadline for every other item on this list.
Schedule the full export early
Run the REST API export of flags, segments, environments and projects while the access token still works, and repeat it before cutover to capture later changes. Data Export only sends live evaluation events from the point it is switched on, so the history you need for analysis must be pulled from your own stores before access is reduced. Confirm which token type your integration uses, since SDK keys and client-side IDs cannot call the API.
Decide archive storage and access
Exports contain targeting rules, segment membership and sometimes context attributes that may include personal data. Choose where the JSON files and event archives will live, who can read them, how long they are kept and how they are encrypted. Document the owner of the archive so the copy is governed like any other system of record.
Plan parallel running
Keep LaunchDarkly and the new system live side by side for a defined period so flag values can be compared before users move. Put an abstraction layer or OpenFeature provider in front of the flag calls so you can switch the source without a code rewrite. Agree the comparison checks, the rollback path and who signs off the cutover before the window opens.
Confirm post-termination data availability
Ask LaunchDarkly, in writing, what happens to flag definitions, audit logs, evaluation data and Data Export destinations after the contract ends, how long each remains accessible and how you obtain a final copy. Also ask whether any retained data can be deleted on request. Record the answers in the migration file, because the export tooling alone does not answer these questions.
Common questions about exporting from LaunchDarkly
Can I export my LaunchDarkly data myself without outside help?
Yes, a single engineer with administrator access can pull flag, segment, environment and project definitions through the LaunchDarkly REST API using an access token. The API authenticates with a token in the Authorization header, and SDK keys and client-side IDs cannot be used for this purpose. The harder part is not the download but the translation: someone has to map targeting rules, segments and prerequisites into the target platform and check the results. Teams without someone who knows both systems often bring in outside help for that mapping and for verification, while the raw extraction stays a modest task.
How long does a LaunchDarkly export take and what changes the effort?
No duration is fixed for every account, so confirm the effort against your own environment before planning. The main drivers are the number of projects, environments and flags, how many segments and prerequisites link them, and how many flags use multivariate variations or complex targeting rules. Each additional project multiplies the work because environments and flags must be checked one by one. Event data adds a separate question, since Data Export only sends live events going forward. Ask for a written scope that lists these counts before agreeing to a timeline.
Can I recover historical flag evaluation data from LaunchDarkly?
Generally no, not through Data Export. LaunchDarkly Data Export exports live data without backfilling history, so events begin only when the export is switched on. Flag and segment definitions can still be read through the REST API in their current state, and the audit log endpoint is available for change history, but that is a separate record from evaluation events. Teams that need past experiment results should keep their own warehouse copy or the analysis already run in LaunchDarkly, and confirm retention and access terms with LaunchDarkly before relying on any older data.
What formats should I expect from a LaunchDarkly export?
Definitions come back as JSON from the REST API, which is the format Unleash recommends for moving flag and segment definitions. Event data from Data Export is delivered to the destination you configure, and flag evaluation events are sent for contexts only when a flag's detailed events setting is on or the flag is in an experiment. That means a plain flag evaluation feed is not a complete record of every user decision. Before relying on any file, check the field names and value types in a sample against the target platform's import format, because the import paths differ between Unleash, Flagsmith and GrowthBook.
Can I export only some projects or environments from LaunchDarkly?
Yes, the REST API reads projects and environments individually, so you can export a subset and leave the rest in place. This is useful when only a release-flag project is moving while experiments stay on LaunchDarkly. Partial exports need care in two places: segments and prerequisites can cross projects, and an export that omits a referenced segment will break targeting in the copy. Also decide whether a partial move will run in parallel with LaunchDarkly, since both systems then need the same flag values during cutover. Ask your implementation partner to list cross-project references in the written scope.
When should I bring in outside help for a LaunchDarkly export?
Bring in outside help when the export touches many projects, multivariate or prerequisite-heavy flags, warehouse-linked experiments, or production traffic that must not change during cutover. Help is also worth considering when no one on the team has access to both systems or when audit evidence for the move is required. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a quote based on that written scope, which should list projects, environments, flags, segments and the parallel-run period. DeployOpen does not issue audit reports or certifications.
What does a LaunchDarkly export leave out that I should check?
Several items need manual verification after extraction. Historical evaluation data is not backfilled, so reporting continuity must be planned separately. Flag evaluation events reach a destination only under the detailed-events setting or during experiments, so a feed may be incomplete for analysis. Segments and custom configuration must exist in the target before a dependent import succeeds. Unleash, for example, exports segments and custom strategies only as references. Use a checklist covering these gaps and confirm each one in a test environment with the vendor's documentation before production cutover.
Do I need a LaunchDarkly EU or federal endpoint to export?
Only if your account lives on one of those regions. The REST API uses app.eu.launchdarkly.com for EU accounts and app.launchdarkly.us for federal accounts, so calling the default endpoint for an account in another region will not return your data. Confirm your account's region before writing any script. If the data must stay inside a specific jurisdiction or authorization boundary, record where the exported files are stored and who can read them, because the export itself moves configuration out of LaunchDarkly.
How to prove the export is complete before you cancel
Do not cancel until you can show, with numbers, that the export matches the live account. LaunchDarkly Data Export does not backfill history, so the completeness check covers configuration (projects, environments, flags, segments) and the live evaluation stream you captured, not past events. Start by reconciling counts per project and per environment: the number of flags, flag states, segments and environments in each project should match between the JSON you pulled through the REST API and the Admin API or import output in your target. Record the totals for each environment separately, because a single project-level total can hide a missing environment. Confirm the scope of your access token too, since a token that cannot read an environment will silently produce an incomplete file. Confirm the API base URL for your account type, including the EU or federal endpoint if your account uses one.
Counts do not prove the rules are right. Pick a sample of flags across each project, including flags with multivariate variations, prerequisites, segment targeting and partial rollouts, and compare the targeting rules and rollout percentages in the target system against the live LaunchDarkly console for the same environment. Rollout percentages deserve the most attention, because a mismatch there changes which users see which variation. For Data Export, check each destination's delivery status and confirm it acknowledged the events you expected. LaunchDarkly retries five times over 30 minutes when a destination does not acknowledge an event, so a destination that failed earlier may need a review of its own logs before you rely on its data. Also confirm which flags had detailed event sending turned on, because only those flags and experiment flags produce flag evaluation events.
Keep a dated, signed record of each check: the exports and their hashes, reconciliation tables, the sample list, the destination acknowledgement logs and the person who approved cutover. The record is your evidence, and you are responsible for filing and retaining it. DeployOpen can help plan these controls, prepare the reconciliation scripts and organize the evidence so it is easy to review, but DeployOpen does not issue audit reports or attestations. If an external auditor or a regulator will rely on this evidence, ask them in advance which format and retention period they expect.
What a fixed-scope export engagement covers
A fixed-scope export engagement starts with a written scope that names the systems in scope, the data types to extract and the destinations that will receive them. For a LaunchDarkly export, the scope should list each project and environment, whether flag definitions, segments, prerequisites and audit history are included, and whether evaluation or custom events are part of the work. It should also state which access token type will be used, since the REST API requires a personal or service access token in the Authorization header and does not accept SDK keys or client-side IDs. Confirm the correct regional base URL before scope is signed, because EU and federal accounts use different hosts from the default one. The written scope should also say who holds the token, where exports are stored and how they are protected in transit and at rest.
Verification is where a fixed-scope export earns its price. The written scope should define how each export is checked against the source: record counts per project and environment, a diff of flag keys, variation sets and targeting rules against the JSON output, and a sample of flags reviewed by a named owner on your side. Data Export events need their own check, because the system only sends detailed evaluation events for contexts when a flag's "Send detailed events to data export destinations" setting is on or when a flag is in an experiment. Ask for a written list of which flags were covered by that setting, and confirm that the destination acknowledged events within the retry window described in LaunchDarkly's Data Export documentation. Deliverables should include the exported files, a gap report that lists what could not be carried over, and a runbook for repeating the export.
Ongoing support and retainers are available if the export runs longer than the fixed scope anticipates, for example when a destination needs rework or when a second round of exports is needed before cutover. Decide before signing whether that support is needed at all, and if it is, agree how changes to scope are raised, approved and priced. Ask your partner to state what a change request looks like in writing and who on your side approves it. Retainers also suit teams that will keep running the target platform and want exports rerun on a schedule while both systems are live. Any dates, effort estimates or fees belong in the written quote that follows the agreed scope, and you should ask for them there.
How DeployOpen scopes, delivers and supports LaunchDarkly exit work
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a LaunchDarkly export, we start by agreeing in writing which flag, segment and environment data leaves LaunchDarkly, which event data is in scope, and where the exported material will be held.
How we scope
- We confirm which LaunchDarkly projects, environments, flags and segments the written scope covers.
- We agree whether Data Export evaluation events are in scope, and which destination will receive them.
- We record the access token handling, the LaunchDarkly region and the storage location for exported JSON.
How we build
- We script REST API exports of flag and segment definitions into version-controlled JSON files.
- We check exported files against the LaunchDarkly console, noting archived flags and multivariate variations.
- We document the gaps, such as the absence of historical backfill, so the client knows what cannot be recovered.
How we hand over
- We deliver the export scripts, the exported definitions and a written inventory of what was and was not exported.
- We provide a mapping document that shows how each LaunchDarkly concept lines up with the target platform.
- We walk your engineers through the runbook so they can repeat the export and verify it independently.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Pricing follows from the written scope and is not published as a list, so ask for a quote against your inventory.
