Migrate from LangSmith to self-hosted Langfuse in stages, not in one cutover
Your team uses LangSmith for tracing, prompt management and evaluations, and you want those capabilities running in infrastructure you control. The short answer on effort is that this move should be staged. The documented path starts with live tracing in parallel: LangSmith's OpenTelemetry spans are sent to Langfuse alongside your existing setup, so new production traffic lands in both systems while you verify the data. Datasets and prompts come next, then evaluators and, only if you need it, historical trace reingestion. Treating the move as a single cutover on a fixed date tends to leave gaps in evaluation history and prompt versions that are hard to repair afterward. The amount of work depends on five things you should inventory before any build begins. First, the size and shape of your datasets and how many evaluators depend on them. Second, the number of prompts in use and how your applications reference them by label or version. Third, how far back your team needs trace history to be queryable, since that decides whether reingestion is worth the effort. Fourth, the evaluators themselves, which the migration guide recommends recreating rather than importing. Fifth, the self-hosted infrastructure you will run Langfuse on, because that sets the capacity and backup work that sits underneath all of the above. The licensing context shapes the decision. LangSmith is proprietary SaaS, and self-hosting is available to it as an Enterprise option. Langfuse's core is MIT licensed, and self-hosted deployments run the same codebase as Langfuse Cloud. The repository's enterprise directories fall under a separate license, and some governance features need an Enterprise license key. Confirm early which of those features your organization depends on, such as project-level roles, protected prompt labels, audit logs or data retention policies, because that determines whether they belong in the first stage or a later one. The practical check to run first is a mapping exercise. A LangSmith workspace maps to a Langfuse organization, a tracing project maps to a Langfuse project or environment, run trees map to traces and observations, and threads map to sessions. Decide how many organizations and projects you need before you send any data, because renaming or restructuring them later changes how access and reporting work. Write this mapping down and have the owners of each LangSmith project sign off on it. Finally, plan for the risk that parallel running creates. While both tools receive traces, cost, retention and access obligations exist in both places, and engineers may start to rely on whichever dashboard they open first. Set an explicit exit point for each stage, name who approves moving to the next one, and decide in advance when LangSmith tracing is switched off. Confirm the specifics of the migration steps and the current SDK requirements against the Langfuse migration guide for your versions before scheduling the work.
What maps cleanly from LangSmith to Langfuse and what does not
This table compares LangSmith concepts with their Langfuse equivalents and marks where the move is a direct mapping, a design decision or a recreation. Read the notes column before you plan the cutover, because the decisions and rebuilt items set the effort more than the trace volume does. Role and retention features depend on an Enterprise license key, so confirm those needs before you map access.
| LangSmith concept | Langfuse equivalent | Notes on the move |
|---|---|---|
| Workspace | Organization | Direct mapping in most cases. Confirm how many organizations your self-hosted instance needs before you create them, since access and reporting are set per organization. |
| Tracing project | Project or environment | Needs a decision. Choose whether each LangSmith project becomes a Langfuse project or whether projects merge into one project with an environment tag. Settle this before parallel tracing starts. |
| Run tree | Trace and observations | Direct for the hierarchy of runs. Spans arrive over OpenTelemetry, so confirm that your LangSmith spans map cleanly to observation types and that inputs, outputs and metadata appear as expected. |
| Thread | Session | Direct mapping for grouping multi-turn conversations. Check that your thread identifiers are stable across requests so that sessions group correctly after the switch. |
| Dataset | Dataset | Copied with the LangSmith SDK as part of the documented migration path. Verify item counts and field structure after the copy, because schema differences can surface in evaluation runs. |
| Prompt Hub prompt | Prompt management entry | Copied with the LangSmith SDK. Version history and labels need checking after copy. Protected prompt labels require an Enterprise license key, so confirm whether you need them before you map prompt access. |
| Evaluator | Evaluator (recreated) | Recreation, not import. Rebuild each evaluator in Langfuse, then test it against known examples. Plan this work separately from data copy because it depends on your scoring logic and models. |
| Experiment and old scores | New experiment runs | Recreation, not import. The guide recommends re-running experiments in Langfuse rather than importing old experiment scores. Decide which historical baselines you need to keep as reference documents outside the platform. |
| Access roles | Organization and project roles | Needs a decision and a license check. Project-level RBAC roles require an Enterprise license key. Map your LangSmith roles to the roles you can actually enforce on the license you hold. |
| Trace retention and historical traces | Retention policy and optional OTLP reingestion | Needs a decision. Historical traces can be reingested over OTLP with original timestamps, but retention policies that need an Enterprise license key must be settled before old data lands. |
Documented import and export paths for a LangSmith move
LangSmith moves to self-hosted Langfuse through a small set of documented paths, and none of them is a bulk one-click importer. Datasets and prompts are copied with the LangSmith SDK, live tracing runs over OpenTelemetry, and historical traces can be resent over OTLP with original timestamps. Each path needs access and an endpoint your team controls, and none of them carries old experiment scores.
Datasets through the LangSmith SDK
Use the LangSmith SDK to read each dataset's examples and write them into a Langfuse dataset in your self-hosted instance. The team needs read access to the LangSmith workspace, a Langfuse project API key pair, and a script that can reach both services from one network location. Check inputs, outputs and metadata field by field after the copy, because your script defines the mapping and must be tested. Experiment results attached to these datasets are not moved, so recreate evaluators and re-run experiments in Langfuse.
Prompt Hub prompts through the LangSmith SDK
The same SDK approach copies prompts from the LangSmith Prompt Hub into Langfuse prompt management. Export each prompt version that production still calls, recreate the labels you use in Langfuse, and confirm that template variables render the same way in the calling code. The team needs read access to the prompts in LangSmith and write access to the target Langfuse project. Confirm which versions and labels survive the copy, and record which version each service calls before you switch.
Live tracing over OpenTelemetry
LangSmith's OpenTelemetry spans can be sent to Langfuse's OTLP endpoint at /api/public/otel while LangSmith tracing stays on. New traces appear in Langfuse as applications run, which lets you compare both systems before cutover. The team needs the Langfuse base URL reachable from each application or collector, and project credentials set in the exporter configuration. Traces recorded before the switch stay in LangSmith unless you reingest them, and you should check that run trees arrive as traces and observations.
Historical traces through OTLP reingestion
Historical traces can be resent over OTLP with their original timestamps, so Langfuse shows trace history at the times the runs happened. This path is optional and needs an export of historical runs that your script can convert into OpenTelemetry spans, along with the same endpoint and credentials used for live tracing. Confirm ClickHouse disk headroom for the expected volume before a large backfill. LangSmith feedback and experiment scores are not part of this path, so keep the original export for audit.
How parallel tracing over OpenTelemetry starts the move
The documented LangSmith to Langfuse guide starts with live tracing because it lets your team prove the new destination before anything else depends on it. LangSmith's OpenTelemetry spans are sent to Langfuse alongside the existing LangSmith tracing, so every request produces traces in both systems. Nothing is switched off, and no historical data is moved yet. The practical decision is which services go into the parallel run first, and who owns the comparison for each one.
What to verify during the parallel run. Compare traces for the same requests in both tools and check five things. First, span completeness: every LLM call, tool call, retriever step and nested chain should appear in Langfuse with the same parent-child shape as the run tree in LangSmith. Second, token and cost attributes: confirm that input, output and total token counts are present on generations, and that any cost figures match what you expect from your model pricing. Third, session grouping: LangSmith threads should map to Langfuse sessions, so multi-turn conversations stay together. Fourth, sampling: if either side samples, the rates must match before counts can be compared. Fifth, PII in payloads: check what prompts and outputs are stored, because the same content will now sit in a second system.
Langfuse accepts OpenTelemetry traces over OTLP at its /api/public/otel endpoint, so frameworks that emit OTEL spans can send to it. The documentation names LangChain, LlamaIndex, CrewAI and AutoGen as examples of OTEL-instrumented frameworks. Check the instrumentation version and the span attributes each framework emits in your own services, because support for specific attributes can differ between framework releases. Confirm the exact behavior with the Langfuse OpenTelemetry documentation and with a test run in your environment.
Treat parity as a claim to test, not an assumption. Confirm each instrumented service against its own traces, one service at a time, and record the result before moving to the next. A service that looks correct in aggregate can still drop spans from a specific tool, lose session IDs in a background job, or carry payloads that a different masking policy would have caught. Record which services passed, which need changes in instrumentation, and who signed off.
Plan the parallel period so it covers real traffic patterns, including batch jobs and low-volume paths that are easy to miss. Agree the exit criteria in writing before the run starts, and keep the LangSmith tracing active until those criteria are met and the team has accepted the Langfuse traces for each service.
Sequence for a LangSmith to Langfuse move with parallel run and cutover
This sequence moves LangSmith tracing, datasets, prompts and evaluators into a self-hosted Langfuse in an order that keeps production traces flowing throughout. Live tracing starts first so new data is captured, while datasets, prompts and evaluators are copied and rebuilt alongside it. The result is a verified Langfuse deployment that applications send to, and LangSmith access retired once your retention needs are met.
Inventory projects, datasets, prompts and evaluators
Your team lists every LangSmith workspace, tracing project, dataset, Prompt Hub prompt, evaluator and integration that sends or reads data. Map each workspace to a Langfuse organization, each tracing project to a Langfuse project or environment, and note where threads need to appear as sessions. Record which applications, CI jobs and gateways depend on each project, and which data must be kept for retention or audit reasons. Done when application owners and the security team approve the mapping and dependency list, because later steps depend on these decisions.
Size and deploy self-hosted Langfuse
Choose the topology before provisioning. Docker Compose on a single VM suits testing only because it has no high availability, so production runs on Kubernetes with Helm or Terraform on the cloud your organization uses. A production deployment runs Langfuse Web and Langfuse Worker plus PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. The Langfuse scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse. Treat these as a starting point and confirm them against your expected trace volume. Done when health checks pass and a test trace is visible in the UI.
Configure SSO and access controls
Connect Langfuse to your identity provider through one of its supported Auth.js providers, such as Entra ID, Okta, Keycloak or generic OIDC. Decide whether password sign-in stays enabled for break-glass accounts, and map identity groups to Langfuse roles. Where your domain policy requires it, enforce SSO for specific email domains. Project-level RBAC roles, protected prompt labels and audit logs need an Enterprise license key, so confirm early whether your access model depends on them. Done when a test user from each group signs in and sees only the projects they should.
Run parallel OpenTelemetry tracing
Confirm with LangSmith's documentation how its OpenTelemetry spans can be exported in your setup, then configure a parallel export to Langfuse's OTLP endpoint at /api/public/otel. LangSmith stays in place during this step, so both tools receive spans for the same requests. Compare trace counts, run-tree nesting mapped to traces and observations, token usage and latency for representative workflows. Done when a sampled set of requests shows matching structure in both systems and the team has reviewed and accepted any gaps.
Copy datasets and prompts with the LangSmith SDK
Use the LangSmith SDK to read datasets and Prompt Hub prompts, then write them into Langfuse with its SDK or API. Keep a migration log that records the source workspace, item identifiers and version details for each item. Compare record counts, then check sample inputs, expected outputs and prompt text against the source. Review prompt labels before cutover, because labels and versions determine what applications fetch at runtime. Done when counts match, sampled prompts return identical text from Langfuse, and the log lists every skipped item with a reason.
Recreate evaluators and re-run experiments
Rebuild each LangSmith evaluator as a Langfuse evaluator or scoring step, using the copied datasets as input. The migration guide recommends re-running experiments instead of importing old experiment scores, so results come from the same logic in the new system. Record the evaluator logic, model settings and dataset version for each run so results can be reproduced later. Done when each evaluator produces scores on a test dataset and the team agrees the new results are acceptable for release decisions.
Reingest historical traces when needed
This step is optional and applies only if compliance or investigation work needs older traces inside Langfuse. Reingest them over OTLP with their original timestamps, scoped by project and date range, and test the process on one project first. Langfuse's v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data, so use it as a planning reference if it matches your version path. Done when a sample of reingested traces shows original timestamps and the record count matches the export.
Cut over applications and retire LangSmith access
Switch application configuration to the Langfuse SDK or OTLP endpoint and keys, one service at a time, starting with lower-risk workloads. Keep the parallel run until dashboards, alerts and prompt fetches have been checked for each service. After the retention needs agreed in step one are met and exports are archived, remove LangSmith keys and revoke access for users and service accounts. Done when no service sends data to LangSmith, the access review is signed off, and the decommissioning record states where archived data is held.
What drives the cost and duration of the move
This table lists the factors that raise or lower the effort of a LangSmith to self-hosted Langfuse move, with the direction each one pushes. Use it to scope a quote, since most of the cost sits in your team's time and the number of objects to move, not in the software itself.
| Driver | Effect on effort | What to confirm or reduce |
|---|---|---|
| Tracing projects and services instrumented | Each project or service adds mapping, OTLP configuration and verification work | Inventory every LangSmith tracing project and the services that send to it before scoping |
| Volume and age of historical traces | Reingestion effort and ClickHouse load grow with trace count and age; reingestion is optional | Decide which history the team actually needs, and keep the reingestion window narrow |
| Datasets and Prompt Hub prompts | More datasets and prompts mean more SDK copy scripts and checks that content matches | Count objects per workspace and remove stale prompts and datasets before the move |
| Evaluators to recreate | Each evaluator is rebuilt by hand in Langfuse, so effort rises with the count and complexity | List active evaluators and retire unused ones; confirm which ones your reviewers rely on |
| Experiment history the team needs | Experiments are re-run rather than imported, so keeping old scores adds run time and cost | Agree in writing which experiments must be reproduced and which can be archived |
| SSO and RBAC requirements | Project-level roles, protected prompt labels and SCIM need an Enterprise license key, which adds a vendor fee | Confirm which access controls you need on day one with Langfuse's license key documentation |
| Target infrastructure (managed Kubernetes or VM, cloud or data center) | Kubernetes and high availability add build and operations work beyond a single VM test setup | Choose the hosting model before design; confirm the target platform and Helm or Terraform path |
| ClickHouse sizing and backup design | Sizing, disk headroom for backfills and tested backups add engineering time and storage cost | Ask for sizing based on expected trace volume and confirm backup and restore tests are in scope |
| Internal skills in OpenTelemetry | Teams new to OTLP need more time to instrument and debug; experienced teams move faster | Assess current OpenTelemetry skills early and decide whether training or a partner is needed |
Datasets, prompts and evaluators: what the LangSmith to Langfuse guide copies and what you rebuild
The move after live tracing is where most of the effort sits, and the documented guide draws a clear line between what it copies and what you rebuild. Datasets and Prompt Hub prompts are copied with the LangSmith SDK. Evaluators are recreated in Langfuse, and experiments are run again in the new environment rather than carried over. Plan the work around that split, because it decides how much of your quality history survives the move and how much of it you have to regenerate. For datasets and prompts, the copy is a scripted export from LangSmith and an import into Langfuse. Once the import finishes, check each prompt in the Langfuse UI and API. Confirm that the version count matches what you expect, that the latest version is the one production code reads, and that labels such as production or staging point to the versions your applications actually request. Also confirm that dataset item counts and fields match the source. A short reconciliation sheet, with one row per dataset and prompt and the counts from both systems, gives your reviewers something concrete to sign off. Evaluators are a different case. The guide recommends recreating them rather than importing them, because an evaluator is usually code or a rubric tied to LangSmith's evaluation model and its scoring conventions. Each recreated evaluator needs a fresh review: the prompt it sends to a judge model, the parsing of its output, the score range, and the data fields it reads. Name an owner for each evaluator and record which LangSmith definition it replaces. The guide also recommends re-running experiments instead of importing old experiment scores. This has a direct effect on any before-and-after quality comparison. Old scores were produced by LangSmith's evaluators on the old pipeline, so they cannot be treated as the baseline for Langfuse results. To compare quality across the move, run the same dataset through the same prompt versions and evaluators in both environments, or keep the LangSmith results as a frozen reference and state clearly that the scores come from different evaluator implementations. Two governance points need a decision before cutover. Protected prompt labels, which stop unauthorized changes to production prompts, need an Enterprise license key in self-hosted Langfuse. The same applies to project-level RBAC roles and audit logs, so confirm with your Langfuse account team or the license key documentation which of these you rely on in LangSmith today. Any evaluator logic you recreate must also be reviewed in the new environment, including the judge model endpoint it calls, since that endpoint may now sit inside your own network with its own access rules.
What usually goes wrong in a LangSmith to Langfuse move and how to prevent it
Most problems in this move come from decisions made too late: what data enters traces, how workspaces and projects map, and when traffic switches. Each card names one failure, the prevention step tied to the documented guidance, and what to confirm with Langfuse or in your own environment.
Personal data reaches traces unmasked
LangSmith traces often carry prompts, user messages and tool outputs that contain personal data. Before any span is sent to Langfuse, decide which fields must be masked and how long traces should be kept. Server-side data masking and data retention policies are Enterprise features that need a license key, so confirm your license scope before you plan around them. Check a sample of migrated traces for personal data before historical reingestion starts.
Workspaces and projects mapped inconsistently
The migration guide maps a LangSmith workspace to a Langfuse organization and each tracing project to a Langfuse project or environment. If teams pick their own names, staging traces can land in production projects and access boundaries become unclear. Write the mapping table before the first OTLP export, including environment names and the keys each project uses. Confirm with your Langfuse administrator how organizations and projects are created in your deployment.
ClickHouse undersized for historical reingestion
Reingesting history over OTLP with original timestamps writes a large volume of data into ClickHouse in a short window. The Langfuse v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data, and the scaling guide sets minimums of 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of memory for larger deployments. Size for the full history you plan to move, not only for daily traffic, and confirm the headroom figure against the guide version you deploy.
Cutover before parallel traces and evaluators match
The guide begins with live tracing sent to both platforms in parallel, so the same spans arrive in each before anything switches. Cutting over before trace counts, fields and timestamps agree hides gaps that surface later in dashboards and experiments. Evaluators are recreated and experiments re-run, and old experiment scores are not imported, so compare evaluator results on the same traces in both systems. Keep LangSmith running until both checks pass.
SSO misconfiguration locks users out
Self-hosted Langfuse supports SSO through providers such as Google, GitHub, Entra ID, Okta and generic OIDC, and can disable password sign-in or enforce SSO for specific email domains. Enforcing SSO before the provider callback has been tested can leave administrators without a working login. Test each provider with a non-administrator account in a staging instance, keep a separate administrator recovery path, and agree the enforcement settings with your identity team before production.
Test deployment treated as production
Langfuse documents Docker Compose on a single VM for testing, with no high availability, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP. A rehearsal on one VM is useful, but running live tracing on it carries the risk of running without backups or failover. Helm installs with bundled data stores need the chart upgraded from v1 to v2 before Langfuse v4, so plan that path from the start. Confirm the target topology, backup schedule and recovery test with your platform team before cutover.
Questions teams ask before moving from LangSmith to self-hosted Langfuse
How much does moving from LangSmith to self-hosted Langfuse cost?
The cost has three parts: software, infrastructure and services. Langfuse's core features and APIs are available under the MIT-licensed open source version without limits, so the core product carries no license fee. Infrastructure is the recurring cost you carry: compute and storage for Langfuse Web and Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage in your cloud or data center. Services are the one-time work of setting up parallel tracing, copying datasets and prompts, recreating evaluators and, if chosen, reingesting history. Ongoing support or upgrades are a separate retainer. Enterprise licensing is needed only for specific features. Ask any quote to split these components, state the infrastructure sizing assumptions, list the Enterprise features in scope, and state the volume of history to be moved.
How long does a LangSmith to Langfuse migration take in practice?
The duration depends mainly on how much of your LangSmith setup must move and how ready your target environment is. Live tracing can run in parallel with LangSmith, so it does not have to wait for the rest of the work. The main drivers are the number of tracing projects and environments, the number of datasets and Prompt Hub prompts to copy, and how many evaluators must be recreated and experiments re-run. Historical trace reingestion adds time in proportion to volume. Infrastructure readiness matters too: an existing Kubernetes platform or VM operations process, SSO integration and change approvals can each add steps. Ask for a written schedule that ties each phase to a named deliverable and to the decisions your data owners must make.
What does our internal team need to provide for a Langfuse migration?
Your team needs four capabilities. First, OpenTelemetry knowledge, because LangSmith's spans are sent to Langfuse's OTLP endpoint and the application instrumentation must be verified. Second, Kubernetes or VM operations skills to run Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage, including upgrades and backups. Third, SDK and API access: LangSmith credentials that allow the LangSmith SDK to export datasets and prompts, and Langfuse credentials for the target project. Fourth, data owners who decide which traces may be moved, how long they are retained, and whether prompts or traces contain personal data that needs masking. Confirm these owners and access grants before the scope is signed, because delays here usually affect the schedule more than technical work.
Can an in-house platform team migrate from LangSmith to Langfuse alone?
A capable in-house team can do this alone, because the migration path is documented and Langfuse's core is open source. The deciding factors are capacity and existing skills rather than the migration steps themselves. Teams that already operate Kubernetes, PostgreSQL and object storage, and have someone comfortable with ClickHouse, usually cover the deployment work. Teams without ClickHouse operations experience, without spare engineering time, or with a fixed deadline often benefit from a partner for the data stores and cutover. A practical split is to keep ownership of application instrumentation and evaluators in-house while a partner handles deployment, copying and hardening under a written scope. Either way, assign an owner for the Langfuse instance after go-live, since upgrades and backups recur.
Do we need a Langfuse Enterprise license to migrate from LangSmith?
No. The core migration path, covering live tracing, datasets, prompts, evaluators and historical reingestion, runs on the MIT-licensed open source version, which Langfuse states has no feature limits. Enterprise features are needed only when your governance requirements call for them. These include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the org management API with SCIM and the instance management API. The Self-Hosted Enterprise plan is custom-priced and adds a named support engineer, solutions architect access and a support SLA. Note that Enterprise code sits under a separate license in specific directories. Decide which of these features are required before signing, and ask the quote to show them as separate line items.
Can we move historical LangSmith traces into self-hosted Langfuse?
Yes. The migration guide allows historical traces to be reingested into Langfuse over OTLP with their original timestamps, and this step is optional. It runs after live tracing is working, so new traces are not affected. Run trees map to traces and observations, and threads map to sessions. Plan for the volume: more history increases ingestion time and ClickHouse storage, so confirm disk headroom with your database operator before starting. Do not import old experiment scores. The guide recommends recreating evaluators and re-running experiments in Langfuse instead. After reingestion, check trace counts, timestamps and session grouping against a sample taken from LangSmith, and record the results in the handover documents.
How do LangSmith workspaces and projects map to Langfuse?
A LangSmith workspace maps to a Langfuse organization, and a LangSmith tracing project maps to a Langfuse project or environment. Run trees become traces and observations, and threads become sessions. Engineers should settle this mapping before live tracing starts, because changing project names or environments later means re-tagging traces and updating dashboards and evaluators. Check how many tracing projects you have, whether they correspond to production and non-production environments, and which teams need access to each one. If you need project-level roles to separate those teams, that is an Enterprise feature. Record the final mapping in the scope document so the SDK configuration, access model and reporting all use the same names.
How DeployOpen scopes and delivers a LangSmith to Langfuse migration
DeployOpen plans and implements the move from LangSmith to a self-hosted Langfuse inside infrastructure you control. The work follows the documented sequence: live tracing first, then datasets and prompts, then evaluators and optional historical trace reingestion, with workspace and project mapping settled before any data moves.
How we scope
- Inventory LangSmith workspaces, tracing projects, datasets, Prompt Hub prompts and evaluators in use today.
- Map each LangSmith workspace to a Langfuse organization and each tracing project to a Langfuse project or environment.
- Decide whether historical traces are reingested, and confirm the storage headroom that backfill would require before committing.
How we build
- Set up self-hosted Langfuse with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage sized for your ingestion volume.
- Route LangSmith OpenTelemetry spans to Langfuse in parallel with existing tracing, and verify traces match on both sides.
- Copy datasets and prompts with the LangSmith SDK, and recreate evaluators in Langfuse rather than importing old experiment scores.
How we hand over
- Deliver a written runbook covering the project mapping, tracing configuration, dataset and prompt copy steps, and open decisions.
- Document the verification checks used to confirm trace, dataset and prompt parity before LangSmith tracing is switched off.
- Walk your platform and data teams through operating the deployment, including upgrade and backup procedures for your environment.
How we support
- Support the first production period, including tuning worker and web scaling as trace volume grows in your environment.
- Plan any later major Langfuse upgrade as a separate project, since it changes infrastructure and data models.
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope migration.
