How to export data from Braintrust before your contract ends

Yes, for a small project. Logs, datasets and experiments can be exported from the Braintrust UI as JSON or CSV, which covers modest history without custom code. Larger histories need scripting against the BTQL API, which returns JSON or Parquet. Requests are subject to a 30-second timeout, so the script must page through results in batches and resume cleanly after a failure. Your own engineers can do this if they have API experience and time to test. If the history is large or the team is stretched, a fixed-scope engagement with DeployOpen can cover the export script, validation and handover, with the scope and deliverables agreed in writing before work starts.

Four factors drive the effort more than anything else. The first is log volume, because more traces mean more pages, more storage and longer validation. The second is the number of projects, since each one needs its own export run, naming convention and checks. The third is custom scorers: their logic lives in code or configuration that must be documented and re-created in the destination platform, not just copied. The fourth is the number of downstream consumers, such as dashboards, notebooks, CI gates and internal reports, each of which reads from a specific place and must be repointed. Illustratively, a team with three projects and two scorers that feed a CI gate has a much smaller task than one with twenty projects and a dashboard built on raw logs.

You need four things in place before starting. First, an account in Braintrust with permission to use the export controls and call the API for every project in scope, which may require an administrator to grant it. Second, storage for the output files, such as an S3-compatible bucket or an encrypted network share, sized for the full history with room for re-runs. Third, an engineer who can write and run the BTQL script, handle paging and retries, and store API keys in a secrets manager rather than in code. Fourth, a reviewer who did not write the script and who checks row counts, field completeness and a sample of records against the source. Confirm the exact permission names and export limits in Braintrust's current documentation or with your account team.

The duration depends on the volume of logs, datasets and experiments, the number of projects, and how many requests the paging logic needs to complete. No single figure applies to every account, so the reliable approach is to measure first. Choose one representative project, run the full export path including paging, validation and storage, and time each step. Then multiply by the number of projects and add time for failures, retries and review. Ask your Braintrust account team whether any rate or volume limits apply to your plan, because those can change the schedule. Once you have a measured result, the timeline in a written scope can be based on your own numbers.

Not as a one-click import. Braintrust exports must be mapped to the data model of the destination before they can be loaded. Traces and spans need to become Langfuse traces and observations or Opik traces and spans, datasets need matching item structures, and scores need to be attached to the correct trace or experiment. Metadata fields often need renaming or flattening. Applications that send live traffic also need their instrumentation changed, either through the Langfuse SDK or OpenTelemetry, or through Opik's SDK or @track decorator. Before writing the mapping, check the current import options in each platform's documentation, such as the Langfuse self-hosting guide for deployment prerequisites, and test the mapping on a sample project.

The export run itself is one-time work: scripting, test runs, the full extraction, mapping and validation. Those costs are paid once, though they may be repeated if the mapping changes and the data must be re-exported. Recurring costs begin after the export. Archive storage is charged for as long as you keep the files, and retention periods set by your compliance team determine how long that lasts. If you move to a self-hosted destination, the running costs of that platform recur too. For Langfuse, these include PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, plus the staff who patch and back them up. Ask for each recurring component to be listed separately in any quote.

Not until verification is complete and the retention obligations are settled. Confirm that row counts match for logs, datasets and experiments, that a sample of records matches field by field, and that scorer definitions, prompt versions and evaluation baselines have been saved in a readable form. Check your contract for data return and deletion terms, and check internal or regulatory retention rules for the data you hold. Deleting the project removes the source of truth, so keep the verified export in a controlled archive until the destination has been used for a full evaluation cycle. Record who approved the deletion and when, so the decision can be audited later.