Migrate from LangSmith to Opik

Migrate from LangSmith to Opik without an enterprise key

A team that needs tracing, evaluation and prompt management running in its own infrastructure, without an LangSmith Enterprise license key, can use Opik. Opik's README states that the full platform, including the server backend, web application, tracing, evaluations and prompt management, can be self-hosted under the Apache-2.0 license without a commercial license. The migration is mostly re-instrumentation, infrastructure work and rebuilding evaluations, not a change in how the platform is licensed to you. Platform engineering usually owns the move, with an ML or application owner who knows which LangChain or LangGraph chains, prompts and evaluators matter most.

Start by deciding what the self-hosted footprint must cover. Opik runs on ClickHouse, MySQL and Redis, and the README describes Docker Compose through its opik.sh script for local use and Helm charts on Kubernetes for production. Platform engineering should size the ClickHouse storage against expected trace volume and retention, confirm backup and restore for MySQL and ClickHouse, and check that the Kubernetes or Helm approach fits the cluster standards already in place. Confirm current chart values and supported versions in the Opik GitHub repository before you write deployment code, since the README and releases change over time.

The effort and risk sit in three places: swapping LangChain and LangGraph callbacks for Opik integrations, rebuilding LangSmith datasets and evaluators as Opik metrics and experiments, and deciding how much historical trace data to carry over. Historical import depends on what your LangSmith plan and export options allow, so confirm that early. Run both systems in parallel on a sample of traffic, compare trace completeness and evaluation scores, and only then retire the LangSmith integration. Ask any implementation partner for a written scope that names the frameworks, evaluators and data sets in play, because that scope, not the license, drives the timeline and cost.

Which LangSmith capabilities map cleanly to Opik and which need rework

This table maps the LangSmith capabilities most teams rely on to their closest Opik equivalents and marks each row as clean, needs rework or gap. Use it to scope the migration work, then confirm every specific against current Opik documentation and a test deployment in your own environment before committing.

Capability	Opik equivalent	Status and what to confirm
Tracing of LLM calls	Opik tracing with native integrations and the @track decorator for custom code	Clean for supported frameworks. Confirm the exact SDK calls and span fields against current Opik docs.
LangChain and LangGraph callbacks	Native Opik integrations for LangChain and LangGraph	Needs rework. Replace LangSmith tracing environment settings and callback setup, then verify nested runs appear correctly.
Multi-step agent traces	Multi-step agent tracing in Opik	Needs rework. Check how graph nodes, tool calls and sub-agents map to Opik spans in a test project before relying on them.
LLM-as-a-judge evaluators	LLM-as-a-judge metrics for hallucination, moderation and RAG	Needs rework. Built-in metrics exist, but custom LangSmith evaluators must be rewritten and their prompts re-validated.
Datasets and experiments	Opik datasets and evaluation experiments	Needs rework. Confirm how existing LangSmith datasets are imported and whether historical experiment comparisons carry over.
Prompt management and playground	Opik prompt management with a playground	Needs rework. Prompt versions must be recreated and relinked to traces so regressions stay visible after the move.
Online evaluation rules	Online evaluation rules in Opik	Needs rework. Rebuild each rule, its sampling and its filters, then confirm they run against live traces.
Guardrails	Opik Guardrails	Gap to assess. Confirm the coverage of your current LangSmith checks against what Opik Guardrails actually enforce.

How the Opik stack fits into your infrastructure

A self-hosted Opik deployment runs a server backend and a web application, backed by three data stores: ClickHouse for trace and evaluation data, MySQL for relational application data, and Redis for caching and queuing. Before you commit, map these onto your environment: decide who operates ClickHouse (a managed service in your cloud account or a cluster your team runs), where MySQL backups live, and whether Redis can be a managed instance. Each store needs its own sizing, backup and upgrade plan, and that work recurs after go-live, not only during the initial install.

For local evaluation, Opik starts with Docker Compose through its opik.sh script. For production, the project provides Helm charts for Kubernetes. Confirm the current chart values, supported Kubernetes versions and resource requirements in the Opik README and the release notes before you size a cluster, and pin the release you test. Your platform team should also decide how ingress, TLS, secrets and network policy will be handled, since these are not covered by the default evaluation setup. Instrumentation has two supported paths beyond the native LangChain and LangGraph integrations. OpenTelemetry support lets you send traces from services that already export OTLP data, which matters if you want one telemetry pipeline for LLM and non-LLM workloads. The @track decorator suits custom Python code outside those frameworks. Choose one primary path per service so traces remain consistent across dashboards. The README cites 40M+ traces per day as a vendor statement, not a benchmark for your workload, so run a load test with your own trace sizes, span counts and retention targets before relying on it.

What data and integrations move, and what you rebuild

A LangSmith to Opik move splits into three kinds of work: historical data that you export and re-import, instrumentation that you change in code, and configuration that you recreate by hand. The cards below separate these so each has a named owner and a check before cutover.

Historical trace export

Historical traces leave LangSmith through the bulk export, which writes trace data as Parquet files to an S3-compatible bucket. 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 plan and export window before you plan the import, and test the Parquet-to-Opik mapping on a sample project before loading full history.

LangChain and LangGraph instrumentation

Opik provides native LangChain and LangGraph integrations, so most applications change their tracing setup rather than their agent logic. Remove the LangSmith tracing environment variables and callbacks, then add the Opik integration and confirm that multi-step LangGraph runs appear as nested spans. Custom functions outside the framework need the Opik @track decorator, which must be added by hand.

Prompt library and playground

Prompt versions in LangSmith do not transfer through the trace export, so they must be recreated in Opik's prompt library. Assign each prompt a stable name, record which version each production service calls, and check that the playground runs the same model settings. Teams that use prompt labels in code should confirm how Opik exposes versions before changing service configuration.

Evaluation rules and datasets

LLM-as-a-judge metrics for hallucination, moderation and RAG, along with online evaluation rules, need to be defined again in Opik and matched to the metrics your team used in LangSmith. Datasets and experiment baselines are a separate step, since a score history from one platform does not compare directly with another. Document which thresholds gate a release so reviewers know what changed.

API keys, users and projects

LangSmith API keys, workspace members and project names do not move with the data. Create the Opik workspace, map each LangSmith project to an Opik project, and issue new keys to the services and CI jobs that send traces. Rotate or retire old LangSmith keys only after the last service has sent traces to Opik, and confirm which roles your self-hosted deployment supports for each user group.

Self-hosted data stack

The self-hosted Opik deployment runs on ClickHouse, MySQL and Redis, so storage sizing, backups and upgrades become your team's responsibility. Plan the ClickHouse volume for imported history on top of new traces, and decide how long you keep data without a plan-based retention limit. Choose Docker Compose for evaluation or Helm charts for production, and confirm the stack against the Opik release you deploy.

The five-phase migration sequence from inventory to decommission

This sequence moves LangSmith tracing, datasets, prompts and evaluators to a self-hosted Opik deployment in controlled stages, so each phase ends with a written record that the next one depends on.

Inventory traces, datasets, prompts and evaluators
Your engineering lead and an owner from each product team list every LangSmith project, tracing integration, dataset, prompt in the prompt hub, and online or offline evaluator in use. Record which services call LangSmith, which LangChain or LangGraph versions they use, and which data must be kept for audit or model comparison. The output is an inventory register with one row per asset, an owner, a retention requirement and a migrate, rebuild or retire decision. The phase is done when the register has been reviewed and signed off by the owners of each affected service.
Stand up a self-hosted Opik instance
Your platform team deploys Opik inside your own infrastructure, using the Docker Compose path for a local evaluation or the Kubernetes Helm charts for a production-grade setup. Confirm that the ClickHouse, MySQL and Redis components, storage sizing, backup schedules and network boundaries meet the requirements recorded in the inventory. The output is a deployment record covering versions, hosts, persistence and access controls, and the phase closes when a test trace from a sample LangChain application appears in the Opik interface.
Run a pilot on one LangChain or LangGraph service
Choose one service with moderate trace volume and a clear owner, then switch its LangChain or LangGraph tracing configuration to point at the self-hosted Opik endpoint. Compare the span tree, token counts, latency and errors against what LangSmith shows for the same request types, and confirm that a prompt version and a basic evaluation metric work end to end. The output is a pilot sign-off document listing the checks performed, the gaps found and the owner who accepts the result.
Run both platforms in parallel
Configure the remaining services to send traces to both LangSmith and Opik for a period agreed in advance by the engineering and compliance leads. Compare volumes, sampling, missing spans and evaluator results between the two platforms, and resolve differences in instrumentation before cutover. The output is a parallel-run log with discrepancy notes and an agreed list of accepted differences, and this phase ends only when the owners of the inventory have confirmed that the results match their expectations.
Cut over SDK and environment configuration
Change the tracing and API configuration in each service through your normal change process, removing LangSmith keys from runtime secrets and pointing applications at the Opik endpoint and project names. Rebuild the evaluators and prompt references that the inventory marked for migration, and confirm that CI pipelines and alerts no longer depend on LangSmith. The output is a cutover change record per service, with the commit or release reference, and the phase closes when no service sends production traces to LangSmith.
Decommission LangSmith and keep an archive
Before you stop using the LangSmith workspace, export the data you are required to keep, using the bulk export to an S3-compatible bucket if your plan includes it, and store the Parquet files in your own object storage with access controls and a retention label. Revoke LangSmith API keys, record which users and service accounts were removed, and confirm your contract or subscription end date with LangChain. The output is a decommission record and an archive index that auditors can use to locate historical traces, and the phase is complete when both documents are approved by the data owner.

How the migration differs by team size and starting point

A small team using LangSmith mostly for tracing LangChain and LangGraph applications usually has a narrow migration. The work centers on swapping the tracing setup, moving prompts and a modest set of datasets, and deciding whether a single Opik instance is enough. Because the integration is native for LangChain and LangGraph, the code change is typically limited to configuration rather than rewritten application logic.

Callback configuration: Confirm which environment variables and callback handlers the applications set, and plan a staged switch per service.
Prompt inventory: List the prompts in the LangSmith hub that production code depends on, and decide which ones move first.
Historical traces: Decide whether past traces are needed for audits or regressions, since the bulk export is limited for some plans.
Single-node hosting: Ask whether Docker Compose through the opik.sh script is acceptable for your traffic and retention needs, or whether you need Kubernetes.
Hosted option: Check whether the Comet.com hosted service fits your data residency rules before committing to self-hosting.

Before you start, confirm your LangSmith plan and export access, and which teams own each application's tracing configuration.

What drives the cost and duration of moving to Opik

This table lists the main drivers behind the cost and effort of moving LangSmith tracing and evaluations to self-hosted Opik, and how each one changes the bill. Read it as a checklist for scoping, with the last column showing what to ask for in a written quote.

Driver	Why it changes cost or effort	How to keep it down
Number of services and instrumented callbacks	Each LangChain or LangGraph application, custom service and @track-decorated function needs instrumentation and testing before traces reach Opik, so effort grows with the count of services.	Inventory every LangSmith project and callback first, group services that share one tracing pattern, and migrate the highest-value workflows before the rest.
Trace volume and retention needs	Opik stores traces in ClickHouse, so storage and compute grow with trace volume and the retention period you choose. Retention is set by your own team rather than by a plan.	Measure current trace volume from LangSmith, set retention per project, and sample low-value traces before the cutover.
Depth of evaluator and prompt rebuild	LangSmith datasets, online evaluators and prompt hub entries do not move automatically, so each evaluator and prompt version must be recreated and checked in Opik.	Rebuild only evaluators that gate releases or dashboards, retire unused prompts, and reuse Opik's built-in LLM-as-a-judge metrics where they fit.
Historical trace import	Bulk export from LangSmith writes Parquet files, and mapping those files onto Opik projects needs scripting and validation. Plan limits on export also affect how much history you can take.	Confirm your export entitlement early, decide which history matters for audits or regressions, and import a time-boxed subset first.
Network and identity integration	Connecting Opik to your SSO, secrets store, private DNS, egress rules and log pipeline involves platform and security staff, and each control needs its own review.	Reuse existing identity and secrets services, document required outbound endpoints, and agree on the access model before deployment starts.
Helm or Docker Compose operating model	Docker Compose suits local evaluation, while production on Kubernetes with Helm needs cluster capacity, storage classes, backups and upgrade windows managed by your team or a partner.	Decide the production target before scoping, standardize on your existing cluster, and define who performs Helm upgrades and backup restore tests.
One-time versus recurring costs	One-time work covers design, instrumentation, evaluator rebuild, import and cutover. Recurring costs cover infrastructure, storage growth, upgrades, monitoring and support.	Ask the quote to separate these groups so you can compare the first-year total with the ongoing run cost.
What to request in a written quote	A useful quote states scope by project, the list of integrations, the evaluator count, the import approach, the target environment and the support period after cutover.	Ask for deliverables, acceptance criteria, assumptions about trace volume and the named responsibilities for your team and the provider.

What usually goes wrong and how to prevent it

Most failed LangSmith to Opik moves fail on details rather than on the platform itself: evaluators that behave differently, history that lands in the wrong place, and infrastructure that runs out of room. The cards below cover the risks we see most often and a prevention step for each, so the cutover is planned against them rather than discovered during it.

Evaluator parity gaps found late

LangSmith evaluators, online rules and annotation queues do not map one-to-one onto Opik's LLM-as-a-judge metrics, guardrails and online evaluation rules. A score that looked stable in LangSmith can shift once the judge prompt, model or rubric changes during rebuilding. Before cutover, run the same labeled dataset through both systems, record each evaluator's inputs and outputs, and confirm that every production gate has a named Opik equivalent.

Historical context lost in import

Parquet files from LangSmith's bulk export carry trace, run and feedback fields that do not share Opik's data model, so a naive import can flatten nested agent steps or drop feedback. Teams then compare new traces against history that no longer shows the same structure. Map each Parquet column to an Opik field on a sample export, import a small time window, and check run counts, token totals and timestamps against the source before importing everything.

Unbounded ClickHouse storage growth

Opik stores trace data in ClickHouse, and self-hosting moves retention decisions from a LangSmith plan to your own disks. Without a retention policy and disk alerts, storage grows with every instrumented call, and a full volume can stop ingestion during a busy release. Set retention windows per project, size volumes from a measured trace volume in a pilot, and alert on disk usage and merge backlog before go-live.

Instrumentation drift across services

Some services move to Opik's LangChain or LangGraph callbacks while others still send traces to LangSmith, and a few custom code paths use the @track decorator with different project names. The result is split dashboards and traces missing from the wrong place. Keep an inventory of every service that emits traces, assign each one an owner and a target project name, and block the old LangSmith environment variables in deployment templates.

Secrets and keys in Kubernetes

The Helm deployment needs database credentials for MySQL, ClickHouse and Redis, object storage keys, and API keys for judge models and the Opik SDK. Values committed to values files or copied into ConfigMaps tend to outlive the migration and spread to developer laptops. Store credentials in Kubernetes Secrets or an external secrets manager, scope each API key to one project, restrict who can read namespaces, and rotate keys used during the import.

Cutover before dashboards are ready

Teams often switch tracing to Opik before the dashboards, alert rules and on-call runbooks that depended on LangSmith data are rebuilt. Latency and error alerts then go silent for a day or more, and nobody notices until a regression reaches users. Run both systems in parallel for a defined period, rebuild each dashboard and alert against Opik data, and make the cutover conditional on a signed checklist from the service owners.

Questions teams ask before moving from LangSmith to Opik

Does self-hosted Opik need a license key?

No. Opik is Apache-2.0 licensed, and its README states the full platform, including the server backend, web application, tracing, evaluations and prompt management, can be self-hosted without a commercial license. Self-hosted LangSmith, by contrast, is an add-on to LangChain's Enterprise plan and needs a license key. Confirm the current license file and README in the Opik repository before you write the decision into a procurement record, since the license terms of any dependency you add later still apply to you.

How much effort does the migration take, and what drives it?

Effort is driven mainly by the number of LangChain and LangGraph applications, the number of prompts and evaluators you rebuild, and how much historical trace data you need to keep. Application changes are usually the smallest part when code already uses LangChain callbacks. The larger items are standing up the ClickHouse, MySQL and Redis stack, wiring authentication and backups, and deciding which LangSmith datasets and evaluators must be recreated. For an illustrative team with a handful of services, the work is a series of small, testable steps rather than one cutover. Ask any implementation partner for a written scope that lists each application, dataset and evaluator.

Can historical LangSmith traces be imported into Opik?

Yes, but the path depends on what LangSmith still lets you export. LangSmith's bulk export writes trace data to an S3-compatible bucket in Parquet format. For customers who signed up after August 3, 2026, that export is only available on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Check your own account's plan and date before planning. After export, the Parquet files must be mapped onto Opik's data model, which is a custom step. Confirm with Comet and your own data team which fields map cleanly and what gets dropped.

Do LangChain and LangGraph applications need code changes?

Usually only configuration changes, because Opik has native integrations with LangChain and LangGraph and works alongside the existing application code. The typical change is replacing the LangSmith tracing environment settings and callback setup with Opik's integration and pointing the client at your self-hosted endpoint. Custom functions traced with the LangSmith decorator are a separate case, and Opik offers a @track decorator for custom code. Run both systems side by side in a staging environment and compare traces for the same inputs before you switch production traffic.

What does the team have to provide for a self-hosted Opik?

Your team provides the infrastructure and the people who run it. Opik self-hosts with Docker Compose for local use through its opik.sh script, or on Kubernetes with Helm charts for production. The production stack uses ClickHouse, MySQL and Redis, so you need a Kubernetes cluster or equivalent hosting, persistent storage sized for your trace volume, backup and restore procedures, TLS, identity and access controls, and someone on call for upgrades. Decide early who owns each of these, because they recur after the migration ends.

Can our own engineers run the migration without outside help?

Yes, if you have engineers comfortable with Kubernetes, Helm, ClickHouse and database operations, and time to test. Opik's documentation and README cover the deployment options. Teams without that experience, or with strict audit or data residency requirements, often hire a partner to plan, implement, harden and document the deployment, then hand it over or retain support. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in the client's own infrastructure, under a fixed scope agreed in writing before work starts. It does not issue audit reports or certifications.

How does Comet.com's hosted Opik differ from self-hosting?

The difference is who runs the platform and where the data sits. Opik is also offered as a hosted service on Comet.com, where Comet operates the platform and your traces are stored in their environment. Self-hosting keeps the server, databases and trace data in infrastructure you control, which is the reason many teams choose it. The code and license are the same Apache-2.0 open-source platform in both cases, so you can move between them. Ask Comet for their current data location, retention and support terms in writing, since those are not covered by the open-source license.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a LangSmith to Opik move, that work covers the Opik deployment itself, the ClickHouse, MySQL and Redis stack behind it, the LangChain and LangGraph instrumentation in your applications, and the historical trace import. Before any work starts, the first step is a written scope that names which projects, environments and trace volumes are in, which evaluators and prompt versions must be rebuilt, and what evidence you need at the end. Ask whether the scope includes a parallel run period in which both platforms receive traces, since that choice shapes the deliverables more than any other single decision.

Most engagements are fixed-scope, meaning the scope, deliverables and timelines are agreed in writing before work begins. A quote follows from that written scope rather than from a price list, so the quote lines should map to the same items: Kubernetes or Docker Compose deployment on your side, storage sizing and backup design, integration changes in each application, migration of datasets and prompts, and documentation handed to your operations team. Ask the proposal to state who is responsible for each line, including your own platform team's time for cluster access, DNS, certificates and secrets. Confirm the exact Opik release and the Helm chart version you intend to run in the written scope, because the migration plan depends on them. Any timeline in the proposal should be tied to named milestones, not to calendar dates alone.

Ongoing support, upgrades and continuous testing are available as retainers after the migration is complete. For Opik, this matters because the ClickHouse, MySQL and Redis components, the Helm chart and the Opik application each need upgrades that must be tested against your trace volumes and integrations. Decide before the cutover whether you will operate Opik with your own staff, with a retainer, or with a mix, and write that decision into the scope so that runbooks, alerts and on-call duties are assigned. Ask for a clear statement of what the retainer covers, how upgrades are scheduled and rolled back, and which parts of the self-hosted environment remain your responsibility. DeployOpen does not issue audit reports or certifications; if your compliance team needs evidence for an assessment, agree in writing which control evidence the migration will produce and which independent assessor will evaluate it.

Migrate from LangSmith to Opik