Migrate from LangSmith to Langfuse: what the move involves
The move from LangSmith to self-hosted Langfuse is feasible, but traces, datasets, prompts and evaluators each travel a different path, so the effort depends on which of them your team actually uses. Teams that are facing a renewal, a self-hosting requirement, a data residency rule or a lock-in concern usually run this as a joint project between platform or ML engineering and a security owner who signs off on where traces and prompts are stored. The short answer on effort is that instrumentation and trace history are the parts to plan carefully, while prompts and evaluators are mostly rebuilding work. The main risk is losing history you assumed would come with you, so decide early what must be kept.
LangSmith's bulk export writes trace data to an S3-compatible bucket in Parquet format, which is the most direct route for historical traces. Check the plan limits before you rely on it: for customers who signed up after August 3, 2026, bulk export is only available on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Confirm your account's status with LangChain, and check the LangSmith bulk export documentation for the current file layout. Export what you need to keep for audit or regression comparison before any contract change, then decide with your security owner how long those files stay in your own bucket.
Your tracing code changes are the second workstream. LangChain and LangGraph applications send traces through LangSmith callbacks, and the switch to Langfuse means configuring the Langfuse callback handler or OpenTelemetry export and retiring the LangSmith environment settings in every service. Dataset and prompt migration is manual: you export or copy datasets and prompt versions, then recreate evaluators as Langfuse scores or experiments and re-link prompt versions to traces. Plan a parallel run where both systems receive traces, so you can compare outputs before cutting over. Ask your implementation partner to write the cutover checklist, the rollback path and the retention settings for the self-hosted Langfuse instance.
Which LangSmith capabilities map to Langfuse, and where rework is needed
This table maps each LangSmith capability in your current setup to its closest self-hosted Langfuse equivalent and marks whether the move is clean, needs rework or leaves a gap. Read the rows with your own usage in mind, since a feature you do not use may not matter. The main takeaway is that tracing and datasets move with little change, while RBAC, retention controls and audit logs depend on a Langfuse Enterprise license key.
| LangSmith capability | Langfuse equivalent | Status | Notes for the move |
|---|---|---|---|
| Tracing of LLM calls and spans | Langfuse tracing via SDKs and OpenTelemetry | Clean | Re-point SDK keys and host. Confirm span attributes you query still appear after instrumentation. |
| LangChain and LangGraph callbacks | Langfuse LangChain and LangGraph callback handlers | Needs rework | Replace the tracer configuration and environment variables, then test nested graph runs and streaming output in staging. |
| Datasets | Langfuse datasets with items | Needs rework | Export examples from LangSmith and re-import them. Check that input and expected output fields map as you expect. |
| Experiments | Langfuse dataset experiments | Needs rework | Historical experiment results do not carry over as comparable runs. Keep old results in an archive for reference. |
| Online evaluators | Langfuse LLM-as-a-judge evaluations on traces | Needs rework | Rewrite each evaluator prompt and scoring rule. Confirm which trace filters you need before enabling them. |
| Annotation queues | Langfuse annotation queues | Clean | Confirm reviewer roles and queue assignments. Role limits may depend on the Enterprise license key. |
| Prompt hub and playground | Langfuse prompt management with versions and labels | Needs rework | Recreate prompts and label deployments. Protected prompt labels require an Enterprise license key. |
| Retention and data control | Self-managed retention in your ClickHouse storage | Needs rework | Data retention policies are an Enterprise feature. Set storage and deletion rules in your own infrastructure and document them. |
| SSO and RBAC | Langfuse SSO and project-level RBAC roles | Gap | Project-level RBAC roles, audit logs and SCIM require an Enterprise license key. Confirm which controls your assessor needs before you choose a tier. |
What data can leave LangSmith and how it lands in Langfuse
Trace history is the part of a LangSmith move that can be exported in bulk, but the export has plan limits and its files need re-mapping before they fit a Langfuse project. The cards below separate what leaves LangSmith through a supported path from what must be rebuilt in your code and pipelines.
Parquet bulk export and its plan limits
LangSmith's bulk export writes trace data to an S3-compatible bucket in Parquet format. For accounts that signed up after August 3, 2026, the export is available only on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Confirm your account's signup date and plan with LangChain before you plan the export window, and confirm which trace fields the export includes.
Re-mapping Parquet files into Langfuse
Parquet files are not a Langfuse import format, so the team must map LangSmith run fields onto Langfuse traces, observations, users and sessions before loading them into a self-hosted project. Check how nested runs, token usage, costs and metadata appear in the export, and test the mapping on a small sample before a full load. Expect a one-time transformation script whose effort depends on how much custom metadata your runs carry.
LangChain and LangGraph callbacks
Applications instrumented with LangChain or LangGraph send traces to LangSmith through environment-driven tracing. Moving to Langfuse means replacing that tracing setup with Langfuse's callback handler and checking that nested chains, tool calls and graph nodes still appear as parent and child observations. Test one graph end to end, including streaming and error paths, before switching production services.
OpenTelemetry instrumentation
Services that already emit OpenTelemetry spans can send them to Langfuse's OpenTelemetry endpoint, which reduces lock-in to any single SDK. Decide whether spans go directly to Langfuse or through an OpenTelemetry Collector that you operate, since the Collector adds authentication, filtering and routing control. Verify attribute names for model, prompt and token usage, because they determine whether Langfuse shows cost and quality views correctly.
Prompt sync and CI evaluation hooks
Prompts and datasets need a documented export path from LangSmith, and this must be confirmed with the vendor before the migration plan is final, since the bulk export described above covers trace data. Prompt versions, dataset examples and any CI jobs that call LangSmith evaluators must be rebuilt against Langfuse's prompt management, datasets and experiments. Ask LangChain whether prompt history can be retrieved in bulk, and keep a copy of current prompts and golden datasets in your own repository as a fallback.
Collector configuration and access controls
If you route traces through an OpenTelemetry Collector, its configuration becomes a security boundary that holds credentials for Langfuse and carries trace content. Use the Collector's authenticator extensions to control who may send data and to add credentials to outgoing exporter requests, and review the configuration best practices before production. Treat this as a checklist item in the migration plan rather than an afterthought.
How the Langfuse self-hosted stack fits your environment
A self-hosted Langfuse deployment is a set of stateful services you will operate yourself, so the first decision is which path matches your environment. Langfuse documents Docker Compose on a single VM for testing, which has no high availability, and Kubernetes with Helm or Terraform on AWS, Azure and GCP for production. The stack has two application containers, Langfuse Web (the UI and APIs) and Langfuse Worker (asynchronous event processing), plus PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Map each of these to a service your platform team already runs, and confirm who owns backups, patching and capacity for ClickHouse, since it holds the trace volume.
If you plan to move to a current major version, check the version floor before you provision anything. The Langfuse v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and it moves to an observations-first ClickHouse data model. The same guide advises about 3x ClickHouse disk headroom when backfilling historic data, which matters for a migration that brings LangSmith history across. Read the Langfuse upgrade guide for the migration sequence, and confirm the minimum versions your managed database or Kubernetes offering supports before committing to an architecture.
If your applications already send telemetry through an OpenTelemetry Collector, you can route Langfuse traffic through it rather than sending it straight to Langfuse Web. The Collector can authenticate incoming connections with an authenticator extension such as OIDC and attach credentials to outgoing exporter requests, which gives you one place to enforce access and routing across services. This is an optional layer, not a requirement, and it adds a component you must version, secure and monitor. Confirm the Collector components and their stability levels in the OpenTelemetry Collector documentation before you put them on the trace path.
The migration sequence from inventory to decommission
The sequence moves LangSmith work to self-hosted Langfuse in six stages, each closed by a written check, so traces, datasets, prompts and evaluators are verified before LangSmith access ends. The cutover date is set from the written scope, not from a fixed schedule.
Inventory projects, callbacks, datasets and evaluators
Your team lists every LangSmith project, the LangChain and LangGraph callbacks and tracing settings in each codebase, every dataset, prompt version and online or offline evaluator, and which people and CI jobs depend on them. DeployOpen can run this inventory with your engineers as a fixed-scope input to the written plan. It is done when each item has an owner, a target Langfuse equivalent and a note on whether it must be rebuilt, moved or retired.
Stand up the self-hosted Langfuse pilot
The platform team deploys self-hosted Langfuse in your infrastructure, using Docker Compose only for a non-production test and Kubernetes with Helm or Terraform for anything that carries real traces. The deployment needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and sizing follows Langfuse's scaling guidance. It is done when the web and worker containers are healthy, backups run, and a test trace appears in the UI.
Switch one pilot project to Langfuse callbacks
Engineers pick one low-risk service and replace its LangSmith tracing configuration with the Langfuse callback handler for LangChain or LangGraph, or with Langfuse OpenTelemetry export if the service already emits OpenTelemetry spans. The pilot keeps the same prompts and model calls so output differences come from tracing alone. It is done when the pilot's traces show complete chains, nested tool calls, token usage and user or session identifiers in Langfuse.
Run both systems in parallel
For a period set in the written scope, the pilot service and the other migrated services send traces to LangSmith and Langfuse at the same time. Engineers compare trace counts, latency overhead, error capture and cost fields for the same requests. The parallel run closes when the teams sign off that every trace type they rely on appears in Langfuse with matching content, and the open issues are logged with owners.
Import historical data and rebuild evaluators
Historical traces leave LangSmith as Parquet files from its bulk export, delivered to an S3-compatible bucket, so check the export plan terms for your account before relying on it. Your team maps those files onto Langfuse projects, re-imports prompts and datasets, and rebuilds each evaluator with Langfuse LLM-as-a-judge, annotation queues or dataset experiments. It is done when a sample of historical records matches the source and every evaluator that gates a release produces scores in Langfuse.
Cut over SDK configuration and CI evaluations
Engineers change the production SDK configuration, environment variables and CI evaluation jobs so that they write to the Langfuse host and use Langfuse datasets, with the cutover date set from the written scope. Rollback steps are documented so the previous LangSmith configuration can be restored for a defined window. It is done when production traces arrive only in Langfuse, CI gates report from Langfuse, and no service still sends new data to LangSmith.
Decommission LangSmith access
After the agreed window, the team removes LangSmith API keys from code, secrets stores and CI variables, revokes user seats and scheduled exports, and confirms with LangChain how long data remains in the account and how it is deleted. Retention for retained records is then governed by your Langfuse settings and the self-hosted retention policy, which requires an Enterprise license key if you use it. It is done when access is revoked, the final export is archived and the decommission record is signed off.
What drives cost and duration in this migration
This table lists the factors that move cost and calendar time when moving LangSmith tracing, datasets and prompts to self-hosted Langfuse. Read each row as a question to answer before requesting a quote, since most lines scale with the size of your current LangSmith footprint and the retention you need to keep.
| Driver | Why it moves cost or effort | What to ask for or keep down |
|---|---|---|
| Projects and callback integrations | Each LangChain or LangGraph application that sends traces needs its callback or environment settings changed, tested and deployed, so effort grows with the number of services. | Ask for an inventory of projects and callbacks, and group services that share one tracing configuration to reduce rework. |
| Trace volume and retention needed | Trace volume drives ClickHouse storage, worker CPU and memory, and backup size. Keeping data beyond LangSmith's 14-day default means you own that storage growth. | Ask the quote to model ingestion volume and retention period separately, and confirm whether retention policies need an Enterprise license key. |
| Historical data to backfill | Importing past traces from Parquet exports takes compute and time. For Langfuse v4 backfills, plan for about 3x ClickHouse disk headroom during the migration, according to Langfuse's upgrade guide. | Decide which history is truly needed, limit the backfill window, and ask for disk sizing that includes the 3x headroom. |
| Evaluators and datasets to rebuild | LangSmith online evaluators, datasets and annotation queues have to be recreated in Langfuse, and each one needs validation against known results before teams trust it. | Ask for a count of evaluators and datasets, and a list of which ones must match prior scores exactly. |
| Prompt versions and labels | Prompts must be re-created with versions and labels, and applications must fetch the right label. Teams with many prompts see more review cycles. | Ask for a prompt inventory and whether protected labels, which need an Enterprise key, are required. |
| SSO and RBAC requirements | Project-level RBAC, SCIM, audit logs and SSO integration are Enterprise key features in self-hosted Langfuse. Requiring them adds a license cost and identity integration work. | Confirm early which roles and identity controls are mandatory, and ask whether the quote covers the key and its renewal. |
| Infrastructure and platform readiness | Self-hosting requires PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage on Kubernetes or Docker Compose. Missing platform capacity extends the schedule. | Ask whether your Kubernetes, database and object storage platforms already exist, and what sizing the scaling guide implies for your load. |
| In-house versus partner capacity | Internal teams carry the cost of learning Langfuse operations, while a fixed-scope partner engagement shifts effort into written deliverables and timelines. Ongoing upgrades recur either way. | Compare an internal staffing estimate against a written scope with deliverables, and ask what ongoing support or upgrade retainer is priced separately. |
How the migration differs by team size and starting point
A small team with a few chains usually has a short export and a small rebuild. The most time-sensitive question is the export window. Customers who signed up before August 3, 2026 keep Parquet bulk export on the Plus plan until February 1, 2027, so the export should happen while that access lasts.
- Export path: Run the Parquet bulk export to an S3-compatible bucket while Plus access lasts, then load the files into a single Langfuse project. Confirm your signup date against your LangSmith agreement before you plan the schedule.
- Keys and roles: The core Langfuse feature set is MIT licensed, so tracing, datasets and prompt management do not need an enterprise key. Project-level RBAC is behind a key, so a single project is simpler to start with.
- Deployment: Docker Compose on one VM is documented for testing and has no high availability. Treat it as a pilot and move to Kubernetes with Helm before production traffic.
- Evaluator rebuild: A few LLM-as-a-judge prompts and a small dataset are usually enough. Rebuild them by hand and keep copies of the original definitions for comparison.
Before you choose the export window, check your signup date, the number of chains you run and the trace history you need to keep.
Several LangGraph services mean many callbacks to switch and a retention policy that the platform team has to enforce. Projects, environments and retention rules should be designed before the first export, because they are harder to change once traces are loaded.
- Callbacks: Each LangGraph service needs its tracing configuration changed. Standardize on one wrapper or environment variable pattern so services can switch in the same release.
- Export path: Export by project and time window, and confirm any run timeouts that apply to large histories on your plan. The Langfuse v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data, so size storage before the backfill starts.
- Retention: Data retention policies are a Self-Hosted Enterprise license key feature. Decide whether you need the key or will manage retention through your own storage lifecycle, and confirm the approach with Langfuse before you commit.
- Scaling: Langfuse recommends scaling worker containers on CPU load. Under heavy ingestion, split langfuse-web into separate ingestion and user interface deployments.
- Evaluator rebuild: Evaluators usually need to be rebuilt per service, and release gates based on dataset experiments take the most rework in this group.
Before setting a cutover date, check total trace volume, the retention requirement for each data class and the ClickHouse capacity you have available.
Regulated teams usually start from the requirement that traces, prompts and user data stay inside their own infrastructure, and that access and changes can be shown to an assessor. Several of the controls they need, including audit logs and project-level roles, sit behind the Langfuse enterprise license key, so that decision comes early.
- Self-hosting: Langfuse runs in your cloud account or data center on PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage. Your team owns backups, restore tests and patching for each of these components.
- Key needs: Audit logs, server-side data masking, SCIM and project-level RBAC require an enterprise license key. Confirm with Langfuse which SSO methods the open-source version supports by reading its authentication and SSO guide.
- Export path: Keep the Parquet files in your own bucket with the same access controls, encryption and retention rules as other regulated records.
- Evidence: DeployOpen prepares systems, controls and evidence for compliance assessments. Independent auditors issue any audit report or certification.
- Upgrades: Major upgrades such as v3 to v4 require ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later. Test each upgrade in staging first.
Ask your assessor which controls must be demonstrated and whether they require enterprise features before you commit to a license key.
What usually goes wrong and how to prevent it
Most failed LangSmith to Langfuse moves come from the same gap: data, code and infrastructure change at once, and nobody owns each piece. Export timing and lost evaluation history are data risks, callbacks are a code risk, and retention, ClickHouse sizing and Enterprise keys decide what runs after cutover. Assign an owner to each item before the first trace moves.
Missed export windows
Bulk export writes trace data to an S3-compatible bucket as Parquet, and access depends on when your account signed up. Accounts created after August 3, 2026 need the Enterprise plan for it, while earlier Plus customers keep access until February 1, 2027. Confirm your plan and sign-up date now, run a full export into a test bucket, and keep a dated copy of each export before any renewal or plan change.
Gaps in evaluator history
The export documents trace data, so evaluator definitions, online evaluator results, annotation queue labels and dataset versions may not arrive in the same form. Langfuse rebuilds these as LLM-as-a-judge evaluators, annotation queues and dataset experiments, which means historical scores need a mapping table. Before cutover, list every evaluator and queue, record its results, and confirm with LangChain what the bulk export leaves out.
Retention mismatch across storage
LangSmith retention is set by your plan, and its 14-day window can be far shorter than the period your audit or debugging needs. Langfuse retention on self-hosted instances is governed by data retention policies, which need an Enterprise license key. Choose a retention period per project before cutover, decide which older traces live only in the Parquet archive, and align backup and disk policy with the period you select.
Unplanned ClickHouse sizing
Langfuse's scaling guide lists 2 CPU and 8 GiB as minimums for ClickHouse, with at least 16 GiB of memory for larger deployments. Backfilling historic data adds load, and the v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom during backfill. Size disks and memory from your expected trace volume and retention, not from a test instance, and ask the vendor or your architect for a sizing review tied to those numbers.
Callbacks still pointing at LangSmith
LangChain and LangGraph services often read LangSmith settings from environment variables and secrets, so a job or notebook that was missed keeps sending traces to the old project. Switching to Langfuse means changing the callback or instrumentation, the keys and the host in every deployment. Run both destinations for a short overlap, compare trace counts per service, then remove the LangSmith settings from manifests, secret stores and CI variables.
Features assumed free
Langfuse's core features and APIs are MIT licensed without limits, but several self-hosted controls need an Enterprise license key. These include project-level RBAC, protected prompt labels, data retention policies, audit logs, server-side data masking and SCIM. Teams that relied on these controls in LangSmith may find them missing after cutover. Map each control you depend on to its license tier before go-live, and request a written quote that covers the key and support.
Questions teams ask before moving from LangSmith to Langfuse
What does a move from LangSmith to self-hosted Langfuse cost?
The cost is mostly infrastructure and labor, not a license fee for the core product. Langfuse's repository is MIT licensed outside its enterprise directories, and its docs state that all core features and APIs are available in the open source version without limits. The recurring costs are the cloud resources for Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, plus the engineers who operate upgrades and backups. One-time costs include re-instrumenting callbacks, moving datasets and rebuilding evaluators. Features such as RBAC roles, data retention policies, audit logs and SCIM need an Enterprise license key, so ask any implementation partner to separate those line items in a written quote. Compare that against your current LangSmith plan and any extended retention charges.
How long does the migration take?
Duration depends on the factors that set scope: how many LangChain and LangGraph applications send traces, how many datasets and evaluators exist, how much historical trace data you need to carry over, and how the target environment is provisioned. The stack has several stateful services, and Langfuse's scaling guide lists minimum resources for web, worker, PostgreSQL, Redis or Valkey and ClickHouse, so infrastructure readiness often sets the schedule. Major version upgrades also follow separate migration guides. Ask for a timeline tied to a written scope with named phases, and confirm the export and backfill steps against your own data volumes before agreeing dates.
What does the team need to provide during the migration?
The work needs owners on four sides. Platform engineers provision Kubernetes or Docker hosts and the managed or self-run data services. Application engineers update LangChain and LangGraph callbacks in each service and test that traces arrive with the right metadata. Data or ML owners decide which datasets and prompts move and which evaluators are rebuilt. Security and compliance staff review access control, key handling and where data is stored. Confirm with the vendor which Langfuse features your access model requires, since RBAC and audit logs sit behind an enterprise key.
Can our own engineers do the migration without an outside partner?
Yes, a capable platform team can run a self-hosted Langfuse deployment, and the open source version has no feature limits. Langfuse documents Docker Compose on a single VM for testing, without high availability, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP. Production operation adds upgrades, backups and capacity planning for ClickHouse, which Langfuse's v3 to v4 guide makes clear is a significant step. Teams without that experience often bring in an implementation partner for a fixed-scope engagement. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and quotes follow from a written scope.
Can we import historical LangSmith traces into Langfuse?
LangSmith's bulk export writes trace data to an S3-compatible bucket in Parquet format, which gives you a portable copy of the data. Whether that export can be loaded into a self-hosted Langfuse project, how fields map, and how much ClickHouse headroom a backfill needs are separate questions. Langfuse's v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, so plan storage before loading. Also check the plan access rules: for customers who signed up after August 3, 2026, bulk export is only available on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Confirm the export availability for your account with LangChain before you rely on it.
How do we keep retention under our control after the move?
Self-hosting moves retention decisions into your own infrastructure. The retention period is determined by how long you keep rows in your PostgreSQL and ClickHouse stores and in the blob storage that holds events, so you set the policy and the disk budget. Data retention policies in Langfuse are one of the features that need an Enterprise license key, so confirm whether automated retention is included in your chosen tier or whether you need scheduled cleanup jobs. Storage grows with retention, so size ClickHouse and object storage against the period you choose, and document the policy so auditors can trace it.
What happens to our data residency and access controls?
With self-hosting, traces, prompts and datasets stay in the infrastructure you choose, rather than in a vendor region. Langfuse's self-hosting docs describe the required services, so you control where PostgreSQL, ClickHouse, Redis or Valkey and blob storage run. Access controls such as project-level RBAC, SCIM provisioning and audit logs require an enterprise license key, so confirm which of these your security policy requires before choosing a tier. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but independent auditors issue any audit report or certification.
How DeployOpen scopes and runs the move
DeployOpen plans and runs the move to self-hosted Langfuse as a fixed-scope engagement inside your own cloud account, data center or air-gapped network. DeployOpen is a Chainscore Labs company. It plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms in the client's infrastructure, so the Langfuse stack (Web, Worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage) is deployed and owned by your team, not hosted by us. Before work starts, the written scope should name the decisions that shape the rest of the plan: which LangChain and LangGraph services are instrumented, which datasets and prompts move, how much history is imported, and which retention period you will run.
Scope, deliverables and timelines are agreed in writing before any work begins, and a quote follows from that written scope rather than from a published price list. Ask the proposal to itemize the components: deployment design and sizing, Kubernetes or Docker Compose setup, callback and SDK changes in each service, export and import of traces, datasets and prompts, rebuilding evaluators, backup and restore testing, and documentation. Also ask which items are one-time work and which recur. Anything the export cannot carry, such as evaluator logic or annotation queue history, should appear as an explicit deliverable with an owner, not as a footnote.
Ongoing support, upgrades and continuous testing are available as retainers after the cutover. This matters for Langfuse because a major version change, such as the v3 to v4 path, has its own migration guide and infrastructure requirements, and retention settings tied to storage growth need periodic review. Confirm with the proposal what a retainer covers, including who applies minor updates, how database migrations are tested before go-live, and how the team gets help during an incident. DeployOpen does not issue audit reports or certifications. If your compliance program needs evidence for an assessment, the independent auditor or certification body will issue the findings, and DeployOpen prepares the systems, controls and records for that review.
