How to export your data from LangSmith

The effort depends less on the export job itself than on what you do with the files afterward. Running the scheduled bulk export to an S3-compatible bucket in Parquet format is configuration work. The larger effort comes from four drivers: the total volume of trace data you need to keep, the retention window you want to preserve, the schema mapping from LangSmith's Parquet layout into the data model of your target platform, and the verification that proves the copy is complete. Teams with a small set of projects and a short history usually face a narrow job. Teams with years of traces, many projects and nested agent runs face a larger one, mainly because mapping and verification scale with the number of distinct structures in the data. Ask any provider to split the estimate into these four parts so you can see which one drives the cost.

Yes, a capable platform engineer can configure the bulk export and pull the Parquet files, and many teams do this in-house. What is less obvious is the work after the files land. Someone has to decide how LangSmith run and trace fields map onto the tables of a self-hosted Langfuse or Opik project, write and test that mapping, handle edge cases such as very large inputs or runs that were still open at export time, and prove that counts and identifiers match between source and destination. If your team already owns Parquet tooling, ClickHouse or PostgreSQL administration and an S3-compatible bucket, the gap is usually the mapping and verification. If none of these skills sit in-house, outside help can cover that gap without taking over your operations.

Before any export runs, you need four inputs. First, an S3-compatible bucket with a defined location, access logging and a retention rule that matches your policy. Second, an IAM identity or equivalent credentials scoped to write to that bucket and nothing else, with rotation handled under your existing secrets process. Third, named engineering time from the team that owns the destination platform, because someone must confirm the schema and the target project layout. Fourth, a sign-off owner who accepts the verification results, usually a data owner or a security lead who will be asked whether the copy is complete and where it lives. Agree on these in writing, because a missing sign-off is the most common reason an export stalls after the technical work is finished.

No duration figure is supplied for this work, so treat any number you hear as a claim to verify. The timeline is set by volume, the number of projects and environments, how many schema variants appear in the data, and how quickly your reviewers can sign off. Run timeouts are a practical factor: large exports may need to be split by time window or project so that individual runs complete reliably, and each split adds planning and checking. A fixed-scope engagement puts the phases, dependencies and acceptance points into writing before work begins. Ask for the schedule to show which steps wait on your team, such as bucket provisioning or sign-off, since those waits often set the calendar more than the technical work does.

The bulk export described in LangSmith's documentation covers trace data written to the bucket in Parquet format, and that is what the supplied facts establish. Prompts, datasets, annotation queues, evaluator configurations and experiment metadata should be treated as separate items that need their own extraction path, and you should confirm with LangSmith's current documentation and your own account exactly which of these are included in the export. Plan for them explicitly. Prompt versions usually need to be recreated in the target platform's prompt management, and datasets often need a separate export through the API. Ask a provider to inventory every object type in your workspace so nothing is assumed to be covered by the trace export.

According to LangSmith's data export documentation, customers who signed up after August 3, 2026 can use bulk export only on the Enterprise plan. Earlier Plus customers keep access until February 1, 2027. If you are on Plus and signed up before that date, the export window has a fixed end, so the planning question is how quickly you can schedule the work, not whether the feature exists today. Confirm your account's plan and sign-up date in LangSmith directly, because the access rule depends on the account, and do not assume a plan change will keep the feature available.

Ask for a written scope that names the source objects, the target platform (self-hosted Langfuse or Opik), the schema mapping you will receive, the verification method and the acceptance criteria. The quote should list deliverables, such as the export configuration, mapping documentation, a reconciliation report and a runbook, along with the dependencies on your team. Ask which items are one-time work and which recur, for example if you need ongoing exports during a parallel run. Request the assumptions about data volume and retention, a clear statement of what is excluded, and how change requests are handled if the data turns out to be larger or more varied than expected. DeployOpen works on fixed scopes agreed in writing before work starts, and does not publish a price list, so the written scope is what the quote follows from.

Verification should compare the source and the copy at several levels: total record counts per project and time window, identifier matches for traces and runs, spot checks of nested agent steps, and checks that timestamps, token counts and status fields survived the mapping. Use a sample of records that engineers read by hand, because automated counts can match while fields are shifted or truncated. Document the method and the tolerance for differences, and have the sign-off owner accept the reconciliation report before the source is retired. Keep the Parquet files and the report under your retention policy so the evidence remains available if a question arises later. This work prepares evidence for your own reviews and does not replace an independent audit where one is required.