How to export your data from Doppler

A key count check is the simplest proof of completeness. Doppler's platform limits allow up to 1,200 secrets per config, so a config near or at that ceiling deserves particular attention. Compare the number of secrets in each Doppler config with the number of entries in the exported file, and with the number of keys your target system reports after import. A mismatch means something was dropped, duplicated or filtered out during export.

• Count per config: Record the secret count for every config before export, not just for the configs you expect to be large.
• Compare the export file: Count the top-level keys in each JSON or YAML file and confirm the number matches the Doppler count.
• Check for silent skips: Look for keys that were empty, reserved or excluded by your export command, and log each exception.
• Repeat after import: Count keys in OpenBao KV paths or Infisical environments once the import finishes.
• Flag near-limit configs: Note any config approaching 1,200 secrets so it can be exported and checked in a separate step.

Keep the counts for each config in the migration record, with the date and the person who ran the check.

Counts show that keys arrived, but not that the values are correct. Spot checks compare selected values between Doppler and the target system. Choose a sample that includes the most sensitive configs, the longest values, values with special characters such as quotes, equals signs and newlines, and any values that are base64 encoded or multi-line certificates. Compare them through a secure channel, and never paste production values into tickets, chat or shared documents.

• Sample by risk: Select production and payment-related configs for a larger sample than development configs.
• Cover edge characters: Include values with quotes, $ signs, trailing whitespace and multi-line content.
• Compare hashes: Compare SHA-256 hashes of each value on both sides so plain values never leave their systems.
• Record the method: Note which keys were sampled and how they were compared, not the values themselves.
• Escalate mismatches: Treat any mismatch as a stop condition until the cause is understood.

The result to record is the list of sampled key names, the comparison method and the outcome for each.

Format checks confirm that the file your pipeline reads matches what it expects. Doppler's download endpoint returns a config's secrets as json, dotnet-json, env, yaml, docker or env-no-quotes, and optional name transformers such as lower-snake or dotnet-env change key names. A transformer applied in one export and omitted in another produces keys that look similar but do not match, which breaks applications silently.

• Record the exact format: Store the format and transformer used for each export as part of the run record.
• Parse the file: Confirm each file parses with the expected parser before it is loaded anywhere.
• Check key names: Compare transformed key names against the names your applications and manifests reference.
• Check quoting: For env output, confirm quoted and unquoted values are handled as your loaders expect.
• Use one format per target: Keep one export format for each target system to avoid mixed results.

Record the format, transformer and parser result for every config so the team can reproduce the export.

Dynamic secrets need separate treatment because they are not stored values. Doppler's download API returns dynamic secrets only when include_dynamic_secrets is set, and those leases expire after 1,800 seconds by default. An export taken without that flag omits them entirely, and an export taken with it contains credentials that stop working on schedule. The check confirms which dynamic secrets were in scope, how they were issued and that none were copied into a static store as if they were permanent.

• Inventory dynamic secrets: List every dynamic secret source per config before export.
• Confirm the flag: Verify whether include_dynamic_secrets was set for each export and record the result.
• Check lease expiry: Confirm no exported lease was written as a long-lived static value.
• Recreate at the target: Confirm the target system issues its own dynamic credentials with leases and revocation.
• Test revocation: Revoke one test lease in the target system and confirm the dependent service fails as expected.

Record the dynamic secret inventory, the flag setting and the revocation test result.

A restore test proves the exported data works where it is going. Load a copy of the export into a non-production target, then start a representative application or pipeline and confirm it reads the secrets it needs. Doppler's documentation strongly recommends against writing plain-text secrets to the file system, so run the test with the same safeguards used for the real export, such as an encrypted fallback file or process substitution, and remove any staging copies afterward. Do not treat this as a substitute for a dry run of the migration itself, but use it to confirm that the target is correctly configured.

• Use a non-production target: Restore into a separate OpenBao cluster or Infisical instance first.
• Start a real consumer: Run one application or pipeline that depends on the restored secrets.
• Confirm access controls: Check that policies or roles allow only the intended identities to read each path.
• Remove staging copies: Delete any temporary plain-text files and confirm the deletion.
• Document the rollback: Record how the team would return to Doppler if the restore fails.

Retain the restore test results, the consumer tested and the access check outcome as the final evidence set, and confirm with your auditors or compliance team which records they require.