Migrate from LangSmith to Arize Phoenix

Migrate from LangSmith to Arize Phoenix: what the move involves

If your renewal, Enterprise self-hosting cost, data residency requirement or lock-in concern is pushing you toward Arize Phoenix, plan for two main pieces of work: re-instrumenting your applications so traces flow through OpenTelemetry and OpenInference, and rebuilding datasets and evaluations on the Phoenix side. Export your existing LangSmith trace history to Parquet early, because that archive is what you keep if the destination changes later. The work is usually shared by platform engineers who stand up Phoenix, application engineers who change the instrumentation, ML or evaluation engineers who rebuild datasets and scoring, and a security owner who signs off on where traces, prompts and credentials live. Ask the security owner to confirm that role early, since they will shape the deployment choice.

Phoenix is free to self-host with no feature limitations, no license fees and no usage limits, and its documentation says traces, prompts and data stay in your infrastructure, including air-gapped deployments. Phoenix's default storage is a file-based SQLite database, so decide early whether a PostgreSQL backend, set through PHOENIX_SQL_DATABASE_URL, is needed for your scale and backup model. Before you standardize on Phoenix, have legal review the Elastic License 2.0 in the project's LICENSE file. It is source-available, not OSI-approved, and it forbids offering the software to third parties as a hosted or managed service. Internal use is the common case, but a platform team that plans to run Phoenix for customers or partners needs a written reading from counsel first.

Effort depends on how many services emit LangSmith traces, how many datasets and evaluators you maintain, and how much history you must keep. Confirm with your own team the number of instrumented services, the dataset inventory and the retention you need, then scope the work from those numbers. Ask any implementation partner for a written scope listing instrumentation changes, dataset migration, evaluation rebuild, hardening and cutover, with the acceptance checks for each. The main risks are a gap in trace coverage during cutover, evaluations that score differently after rebuild, and unclear licensing terms if the deployment is later shared outside your organization.

Which LangSmith capabilities map cleanly to Phoenix

This table maps each LangSmith capability you use to its Phoenix equivalent and marks it as clean, needs rework or gap. Read the status column first, then confirm the rows marked for checking in your own environment before you set a cutover date, since Phoenix's documented feature set is not a line-by-line match for LangSmith's Enterprise features.

Capability	LangSmith	Phoenix (self-hosted)	Status and what to check
Tracing	LangChain and LangGraph callbacks send runs to LangSmith	OpenTelemetry tracing with OpenInference instrumentation	Clean for OpenTelemetry-based code; re-instrument LangChain and LangGraph with OpenInference and verify span trees
Datasets	Hosted datasets built from traces or uploads	Versioned datasets	Needs rework; export examples and rebuild them in Phoenix, then check version history matches your needs
Experiments	Run evaluators against datasets and compare results	Experiments on versioned datasets	Needs rework; rerun baseline experiments in Phoenix and confirm comparison views meet your review process
Online evaluators	Score live production traces automatically	LLM-based evaluations; live scoring setup not confirmed here	Gap until confirmed; test whether continuous evaluation on incoming traces works in your deployment
Prompt management	Prompt hub and playground	Prompt management	Needs rework; export prompt versions and confirm the playground and version linking to traces
Annotation queues	Human review queues on traces	Annotation features not confirmed in the sources reviewed	Gap until confirmed; test reviewer workflow before relying on it for labeling
Self-hosting	Enterprise add-on with a license key, deployed on Kubernetes with Helm or Terraform	Free to self-host with no feature limits; Docker, Kubernetes, Helm and other targets	Clean for deployment; confirm storage sizing on SQLite or PostgreSQL for your trace volume
Identity and roles	Identity configured through the LangSmith Enterprise setup	OAuth2, LDAP and local accounts with role-based permissions	Needs rework; map existing SSO groups to Phoenix roles and test each role before go-live
Data export	Bulk export of trace data as Parquet to an S3-compatible bucket	Import through OpenTelemetry or stored datasets; Parquet import not confirmed	Needs rework; export from LangSmith before plan changes and confirm how Parquet files map into Phoenix

Re-instrumenting LangChain apps with OpenTelemetry and OpenInference

Phoenix does not read LangSmith traces. Its tracing is built on OpenTelemetry, and the instrumentation that fills it comes from OpenInference, so the LangChain and LangGraph code has to move from LangSmith's tracing setup to OpenInference instrumentation that exports spans over OTLP to your Phoenix instance. In practice this means removing the LangSmith environment variables and callbacks that your team relies on, installing the OpenInference LangChain instrumentor for your language, registering a tracer provider that points at the Phoenix collector endpoint, and then running a few representative chains and agent graphs to confirm that the spans show the nodes, tool calls, prompts and token counts you expect. Check span coverage before you retire anything, because custom callbacks and streaming paths often produce gaps that only appear under real traffic. The OpenInference and Phoenix documentation at Arize Phoenix documentation lists the current instrumentation packages and the collector settings to confirm for your deployment.

During the parallel run, keep the LangSmith exporter and the Phoenix exporter active in the same process so that each request produces traces in both systems. This lets you compare trace trees, latency and token attribution for identical inputs before you switch off LangSmith. Give each exporter its own configuration and be explicit about which service name and environment tag each one sends, so that dashboards and comparisons do not mix data from the two systems. Confirm that sensitive fields such as prompts and user content are handled the way your policy requires in both exporters, since the parallel run doubles the places where that data is sent. Decide in advance how long the parallel run lasts and what counts as a match, and record that decision with the owners of the application.

Keep the instrumentation vendor-neutral. Because the same OpenTelemetry and OpenInference instrumentation works with both Phoenix and Arize AX, a team that later needs the managed platform can point the same exporter at a different endpoint instead of re-instrumenting its code. Route spans through an OpenTelemetry Collector if you want to add authentication, batching or fan-out to a second backend without changing application code, and check the collector's own configuration guidance before exposing its receivers beyond the cluster. Confirm with Arize which features differ between Phoenix and Arize AX before you rely on any of them, because instrumentation portability does not guarantee that evaluations, datasets or access controls behave the same way in both products.

What to export from LangSmith and what to rebuild in Phoenix

LangSmith's bulk export moves trace data out, but datasets, prompts, evaluators, annotation queues and API keys do not come along as a package. Treat the export as one input and plan the rebuild of everything else in Phoenix before you change any application code.

Bulk trace export as Parquet

LangSmith bulk export writes trace data to an S3-compatible bucket in Parquet format. For customers who signed up after August 3, 2026, it is available only on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Confirm in your own account which plan and sign-up date apply, and run the export before the access window closes. Check that the bucket you export to can be read by the team that will load the files.

Datasets and evaluators to recreate

Bulk export carries traces, not the dataset definitions, experiment results or evaluator configuration that sit on top of them. Phoenix has versioned datasets and experiments, so export the reference examples you still need and recreate them as Phoenix datasets. Evaluators such as LLM-based judges must be rewritten and re-validated against the new scores, because a change in judge prompt or model will shift results.

Prompts and annotation queues

Prompt versions in LangSmith's prompt hub and the annotation queues used for human review are not part of the trace export. Copy the prompt text and version history into Phoenix prompt management, and record which version each production trace used so regressions stay traceable. Annotation queues and reviewer assignments need to be recreated, and any labels already applied should be exported separately if you want to keep them.

API keys, access and tracing setup

Every LangSmith API key, service account and project-level permission has to be retired or replaced. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so decide which identity source governs access before users log in. Update the environment variables and tracing configuration in each service, and remove old keys from CI secrets and deployment manifests so they cannot keep sending data to LangSmith.

Phoenix storage and the Collector layer

Phoenix starts with a file-based SQLite database by default and also supports PostgreSQL. SQLite suits a single-node trial, while production teams should plan a PostgreSQL instance with backups and sizing for trace growth. Placing the OpenTelemetry Collector in front of Phoenix gives one point to batch, filter and authenticate telemetry, and it lets you change the backend later without re-instrumenting every service.

Confirm the export scope first

Before planning the rebuild, check in your LangSmith account which projects, datasets and time ranges the export covers and whether your plan includes bulk export. Compare that list with what your teams actually use in the last several releases. Items outside the export must be rebuilt from source files or screenshots, so record their owners now while the original workspace is still accessible.

The migration sequence from inventory to decommission

This sequence moves LangSmith traces, datasets, prompts and evaluators to a self-hosted Arize Phoenix instance without losing history or breaking running services. Each step produces a named artifact, so the team can confirm the move is complete before LangSmith is switched off.

Inventory traces, datasets, prompts and evaluators
Platform owners and the team leads of each LangChain or LangGraph service list every LangSmith project, dataset, prompt, online evaluator and annotation queue in use, along with the services that send traces to each one. Record the trace volume, retention needs, data region and who relies on each item. The output is an inventory register that assigns each item a keep, rebuild or retire decision. Confirm the export entitlement for your plan now, because bulk export availability depends on when the account was created and the plan tier, as set out in LangSmith's data export documentation.
Export trace history to Parquet first
Before any instrumentation changes, run the LangSmith bulk export to your S3-compatible bucket in Parquet format for every project in scope. Store the files in a bucket with versioning and access logging enabled, and keep a copy under your own retention policy. Checksum each file and record the export window. The output is a verified Parquet archive with a manifest that a second person has checked against the register.
Stand up a Phoenix pilot on PostgreSQL
Deploy Phoenix in your own cluster or cloud account using the Kubernetes or Helm route in the self-hosting documentation, with PostgreSQL configured through PHOENIX_SQL_DATABASE_URL instead of the default SQLite file. Configure the authentication method your organization requires: OAuth2, LDAP or local accounts with role-based permissions. Restrict network access and confirm that no trace data leaves your environment. The output is a pilot instance with a tested backup and restore procedure and a signed-off access model.
Run LangSmith and Phoenix in parallel
Instrument one non-critical service with OpenTelemetry and OpenInference so that it sends spans to Phoenix while the existing LangSmith tracing stays active. Compare span counts, token and cost fields, latency values and error attributes between the two systems for the same requests. Use an OpenTelemetry Collector if you need to fan out one stream to both backends or apply redaction before export. The output is a parity report listing each attribute that differs and the fix applied.
Rebuild datasets and evaluations in Phoenix
Import the datasets you chose to keep from the Parquet archive or from a CSV or JSON extract, then recreate the evaluators in Phoenix's LLM-based evaluation and experiment tooling. Map each LangSmith evaluator to a Phoenix equivalent, and mark any LangSmith feature without a direct match, such as a specific annotation workflow, as a gap to resolve. Have the evaluation owners rerun a baseline experiment and compare scores with the last LangSmith results. The output is a signed-off dataset and evaluation rebuild with a list of accepted differences.
Cut over instrumentation service by service
Move each service to Phoenix once its parity report is accepted, starting with lower-risk workloads. Update the tracing configuration, remove the LangSmith environment variables from the deployment, and confirm that traces appear in Phoenix under the expected project names. Keep a documented rollback path to the previous configuration for each service until its first full release cycle on Phoenix has passed. The output is a cutover log that records the date, owner and rollback status for every service.
Decommission LangSmith after export verification
Once every service is live on Phoenix and the Parquet archive has been verified against the inventory register, disable LangSmith tracing, revoke API keys and remove the workspace integrations. Confirm with LangChain how your account data will be handled at the end of the subscription, and keep the archive under your retention policy. Review the Elastic License 2.0 terms with legal before standardizing on Phoenix for any service that will be offered to third parties. The output is a decommission record that links the archive, the cutover log and the license review.

How the migration differs by team size and starting point

A small team with a few LangChain services on LangSmith Cloud usually has the narrowest scope. Most of the work is changing how traces are emitted and deciding where Phoenix runs, because there is no existing cluster or identity setup to adapt. Phoenix starts with a file-based SQLite database by default, which can be enough for a pilot, but production use with several engineers normally calls for PostgreSQL.

Instrumentation scope: Replace the LangSmith tracing environment settings with OpenInference instrumentation for each LangChain or LangGraph service and confirm that spans appear in Phoenix before removing the old setup.
Storage choice: Start on SQLite for a single-host pilot, then move to PostgreSQL through PHOENIX_SQL_DATABASE_URL once retention and concurrent use matter.
Authentication: Local accounts with role-based permissions may be enough for a handful of users, so confirm whether OAuth2 or LDAP is needed before onboarding more people.
Cutover approach: Run both tracing paths side by side for a short period, and export the LangSmith data you need from the bulk export while your plan still includes it.
Ownership: Name one person to own the Phoenix host, backups and upgrades, since nobody on a small team is likely to have that role by default.

Before cutover, confirm with LangChain which bulk export options your plan includes and check that Phoenix's Elastic License 2.0 terms fit how your team will use it.

What drives the cost and duration of the move

This table lists the main cost and effort drivers for moving LangSmith tracing and datasets to self-hosted Phoenix, with how each one changes the work and how to keep it under control. Read it as a checklist for scoping: each row names who carries the cost and whether it is paid once or recurs.

Driver	Why it changes cost or effort	How to keep it down
Services and instrumented callbacks	Each service that calls LangChain or LangGraph needs its LangSmith tracing swapped for OpenTelemetry and OpenInference instrumentation, and each one needs testing	Inventory callback use first, group services with shared code, and re-instrument a shared library once rather than each service separately
Trace volume and retention	Storage on PostgreSQL grows with trace count, span size and retention window, and that recurs every month	Set retention targets before go-live, sample high-volume low-value traces, and size the database from a measured week of traffic
Bulk export before the plan change	Exporting Parquet from LangSmith is time-bound for some plans, so a late start can force a larger one-time data effort or lose history	Confirm your plan and export window early, then schedule the export and verify row counts in Phoenix before cutover
Datasets and evaluator logic	Versioned datasets and LLM-based evaluators must be recreated in Phoenix, and custom evaluator code is the part that needs engineering judgment	Count datasets and evaluators in the inventory, retire unused ones, and keep only the evaluators that gate releases
Identity integration (OAuth2, LDAP)	Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so connecting your identity provider and mapping roles is a one-time configuration task with security review	Reuse the existing identity provider, define roles before rollout, and avoid local accounts beyond break-glass use
PostgreSQL and storage sizing	Phoenix starts on SQLite by default, so a production move needs PostgreSQL provisioning, backups and capacity planning, which recur as an operating cost	Use an existing managed or hardened PostgreSQL service if the platform team already runs one, and confirm backup and restore tests
Collector operations	An OpenTelemetry Collector between services and Phoenix adds configuration, upgrades and authentication work, and it recurs with each release cycle	Standardize one Collector configuration, pin versions, and document who approves upgrades
Teams to retrain	Developers, evaluation owners and on-call staff each need to learn new trace views, dataset tools and where to look during incidents	Run a short training per team tied to their own traces, and publish a one-page runbook for the first month

Questions teams ask before moving from LangSmith to Phoenix

Is Arize Phoenix free to self-host?

Yes, according to the Phoenix self-hosting docs, Phoenix is free to self-host with no feature limitations, no license fees and no usage limits. Your traces, prompts and data stay in your infrastructure, including air-gapped deployments. Your costs are the infrastructure to run it, the storage behind it and the people who operate and upgrade it. Confirm the current terms in the Phoenix self-hosting docs before you budget, since the license terms apply to how you use the software, not only to what it costs.

What does the Elastic License 2.0 forbid for Phoenix?

ELv2 forbids two things that matter most to platform teams: providing Phoenix to third parties as a hosted or managed service, and circumventing license key functionality. Running Phoenix for your own engineers, products and customers' data inside your organization is the normal use case. If you plan to offer Phoenix as a service to clients or subsidiaries outside your legal entity, have counsel review the wording first. ELv2 is source-available, not an OSI-approved open-source license, so standardize on it only after your legal team has signed off.

Can our own team migrate from LangSmith to Phoenix without outside help?

Often, yes, for a small service with a few LangChain or LangGraph applications and a short list of datasets. The work is well documented, but it touches tracing code in every service, evaluation scripts and access controls. A team that already runs Kubernetes or Docker, has a PostgreSQL service it can operate, and has an engineer who owns observability will usually cope. Teams with many services, strict residency rules or audit evidence to produce usually benefit from an implementation partner for the hardening and the cutover plan.

What does the migration need from our engineers and platform team?

The work needs application engineers to switch instrumentation to OpenTelemetry and OpenInference, platform engineers to deploy Phoenix and any OpenTelemetry Collector, and a data or evaluation owner to rebuild datasets and scoring. Security and compliance staff should review identity, role assignments and retention. Expect the most effort in the places where traces are created, not in Phoenix itself. Ask who will own each area after cutover, because the migration is usually the cheap part and running the platform afterwards is the recurring work.

How long does a move from LangSmith to Phoenix take?

The duration depends on the number of services that emit traces, how many datasets and evaluators must be rebuilt, the identity integration you need, and how much historical data you must keep. Phoenix deployment itself is rarely the long pole. Parallel running, where LangSmith and Phoenix receive traces side by side, adds time but lowers cutover risk. No general figure applies, so ask any implementation partner for a timeline built from a written inventory of your services and datasets.

Can we move our LangSmith traces directly into Phoenix?

Usually not directly. LangSmith bulk export writes trace data to an S3-compatible bucket as Parquet, and that file set is a useful archive, but it is not a native import format for Phoenix. Most teams keep the Parquet files as read-only history and send new traces to Phoenix from the cutover date. If you need historical traces searchable in Phoenix, plan a separate conversion step and confirm its fidelity against a sample before you commit to it. Check the LangSmith data export docs for the export format and plan access.

What should we ask for in a written scope before we start?

Ask for a written list of in-scope services, instrumentation changes per service, the target deployment (Kubernetes, Docker or another supported option), storage choice (SQLite or PostgreSQL), identity and role design, and how datasets and evaluations will be rebuilt. Also ask how historical Parquet archives are stored and who can read them, what testing proves parity before cutover, what the rollback plan is, what documentation and handover you receive, and what ongoing support or upgrade work is included. Fixed-scope agreements, which DeployOpen typically works under, make these items explicit before work begins.

What usually goes wrong and how to prevent it

Most failed LangSmith to Phoenix moves do not fail in the tracing code. They fail in the surrounding decisions: the export window, the license reading, the storage choice, and the people and evaluators nobody wrote down. Each card below names one risk and the check that prevents it.

Export window closes before verification

Customers who signed up after August 3, 2026 can only use LangSmith bulk export on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Start the Parquet export early, then confirm row counts and a sample of trace payloads in the S3-compatible bucket before you cancel or downgrade anything. Keep the archive in storage you control, and confirm your plan's entitlement with LangChain in writing.

Treating ELv2 as open source

Phoenix is licensed under the Elastic License 2.0, which is source-available and not OSI-approved. It forbids offering Phoenix to third parties as a hosted or managed service, and it forbids circumventing license key functionality. If you build an internal platform that customers or partners reach, have counsel confirm that the use fits the license before you standardize on Phoenix across the organization.

Undocumented evaluators go missing

LangSmith online evaluators, scheduled checks and annotation queues often exist only in the LangSmith UI, so nobody lists them during planning. Before cutover, export the evaluator definitions, prompts and scoring rules, then inventory every dataset and experiment that a release gate depends on. Rebuild each one in Phoenix and run both sets on the same sample traces to confirm the scores agree within a tolerance your team agrees on.

SQLite carried into production

Phoenix starts with a file-based SQLite database by default. That is convenient for a pilot but makes backups, concurrent writes and recovery harder once many engineers send traces. Plan a PostgreSQL backend through PHOENIX_SQL_DATABASE_URL or the separate connection variables before production, and rehearse restoring it from backup. Confirm the storage sizing with your own trace volume, since no sizing figure is supplied here.

Trace loss during dual export

Running LangSmith and Phoenix side by side is the safest cutover, but only if both paths receive the same spans. Dual exporting through the OpenTelemetry Collector can drop spans when an exporter queue fills, a credential expires or a service never gets the new configuration. Compare span counts per service between the two backends each day, and keep the Collector configuration under version control with the authentication extensions turned on.

Roles that do not map across

LangSmith workspace roles and Phoenix role-based permissions rarely line up one to one, and a team that moved from SSO-managed access may find local accounts in Phoenix. Write a mapping table of each LangSmith role to a Phoenix role before go-live, and confirm which of OAuth2, LDAP or local accounts your identity provider can feed. Remove shared logins and test that a departing engineer loses access to traces that contain prompts and user data.

Checking the Elastic License 2.0 terms before standardizing on Phoenix

Phoenix is free to self-host, but it is not open source in the OSI sense. Phoenix is licensed under the Elastic License 2.0 (ELv2), which is source-available. The self-hosting docs say there are no feature limits, license fees or usage limits, and that is true for running Phoenix inside your own environment. The license, however, restricts what you can do with the software beyond that. Before the migration becomes a standard across teams, read the LICENSE file in the Phoenix repository yourself and put it in front of legal counsel, because the answer depends on how your organization intends to use the tool.

ELv2 forbids providing the software to third parties as a hosted or managed service, and it forbids circumventing license key functionality. For most internal use, such as tracing your own LangChain or LangGraph applications on your own cluster, the restriction is unlikely to matter. It becomes a real decision if you plan to offer Phoenix to customers, run it for affiliates or business partners as a managed service, or embed it in a product you sell. Ask counsel to confirm how those cases map to the license text, and document the internal-use position in your architecture decision record.

If the review concludes that you need an OSI-approved license, plan that choice now rather than after the move. The Opik and Langfuse pages in this hub cover Apache-2.0 and open-core options, and the Langfuse page explains which parts of its code sit under a separate commercial license. Phoenix also keeps its OpenTelemetry and OpenInference instrumentation, so re-instrumented applications are less tied to the backend chosen.

How DeployOpen scopes and runs the Phoenix migration

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from LangSmith to Arize Phoenix, we agree the scope in writing first, then build, test, document and hand over the tracing, dataset and evaluation work so your team can run Phoenix without us.

How we scope

Inventory LangSmith projects, traces, datasets, evaluators and prompts that must move, and which will be retired.
Confirm your LangSmith plan, its bulk export status and the Parquet export window before any work starts.
Agree in writing the Phoenix deployment target, SQLite or PostgreSQL storage, and the identity model for users.

How we build

Re-instrument applications with OpenTelemetry and OpenInference so traces flow to your self-hosted Phoenix instance.
Rebuild versioned datasets and LLM-based evaluations in Phoenix, and check them against the LangSmith results you already trust.
Review the Elastic License 2.0 terms with your legal team and confirm they fit how Phoenix will be offered internally.

How we hand over

Deliver runbooks covering deployment, configuration, role assignments, backups and the OpenTelemetry Collector setup.
Document the mapping from LangSmith projects and datasets to Phoenix projects, with a record of what was rebuilt or dropped.
Walk your engineers through the tracing conventions, evaluation workflow and the steps to add new applications.

How we support

Engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work begins.
Ongoing support, Phoenix upgrades and continuous testing are available as a retainer after handover.
Ask us to confirm current Phoenix release behavior and configuration against your environment before each upgrade.

Migrate from LangSmith to Arize Phoenix