Migrate from Arize to Opik

Migrate from Arize to Opik: what the move involves

A renewal, a licensing question or a residency requirement is usually what pushes teams to move LLM traces and evaluations off Arize AX. For Opik, the answer is direct: it is Apache-2.0 licensed, and its README states that the full platform, including the server backend, web application, tracing, evaluations and prompt management, can be self-hosted without a commercial license. The work is mostly re-instrumentation and evaluator rebuilding, not a bulk data lift. Platform engineering usually owns the deployment and the instrumentation changes, since they touch every service that emits traces. LLM application engineers own the evaluators, because they know which failure modes matter for each application. Security and compliance staff should sign off on where the trace store lives, which prompts and user inputs are captured, and who can read them before production traffic is pointed at the new system.

Effort and risk concentrate in three places. Deployment is a one-time setup that becomes recurring upkeep: Opik runs locally with Docker Compose through its opik.sh script and on Kubernetes with Helm charts for production, and its infrastructure uses ClickHouse, MySQL and Redis, so someone must own backups, capacity, patching and upgrades for each. Instrumentation is the largest code change. Opik supports OpenTelemetry and has native integrations with LangChain, LangGraph, LlamaIndex and CrewAI, plus a @track decorator for custom code. Services already emitting OpenTelemetry spans may need only an exporter change, while services using Arize-specific instrumentation need a review of span attributes. Confirm in a proof of concept how each attribute maps before committing. Hosted Opik on Comet.com is also available, which changes the operating cost picture if your residency rules permit it.

Which Arize AX capabilities map to Opik, and what needs rework

This table maps the main Arize AX capabilities to what Opik's documented features cover, with each row marked clean, needs rework or gap. Clean means a direct feature match, needs rework means the feature exists but instrumentation, evaluators or rules must be rebuilt, and gap means you must confirm the item before committing. Items on SSO, access control and support tiers need checking against Opik's current documentation and Comet's offering.

Capability	Arize AX	Opik	Status
Tracing	Managed traces for LLM apps built on OpenTelemetry and OpenInference	Multi-step agent tracing with native framework integrations and a @track decorator	Clean
OpenTelemetry ingestion	Spans sent with OpenTelemetry and OpenInference instrumentation	OpenTelemetry supported; confirm attribute mapping for your spans	Needs rework
LLM-as-a-judge evaluators	Managed evaluators and templates tied to traces	Judge metrics for hallucination, moderation and RAG; rewrite prompts and thresholds	Needs rework
Datasets and experiments	Datasets and experiments managed in the AX interface	Confirm dataset and experiment APIs and import paths in current Opik docs	Needs rework
Prompt management and playground	Prompt versions and playground in the AX interface	Prompt management with a playground; re-link versions to traces after import	Clean
Online evaluation	Evaluations run continuously on incoming production traces	Online evaluation rules; recreate each rule and its sampling in Opik	Needs rework
SSO and access control	Enterprise identity and role controls on the managed platform	Not covered in the README; confirm SSO and RBAC availability with Comet	Gap
Self-hosting	Self-hosted AX on Kubernetes, typically under an Enterprise contract	Docker Compose via opik.sh for testing, Helm charts for production	Clean
Support tiers	Plan-based support levels set in your AX contract	Confirm support levels for self-hosted and hosted Opik with Comet	Gap

What data and integrations move, and what you rebuild

A migration from Arize AX to Opik moves some items through an export and rebuilds others by hand. Trace history, datasets, prompts and evaluators are separate items with separate paths, so plan each one on its own. The cards below set out what moves, what has to be repointed in your code, and what you recreate in the new platform.

Exporting history with the Arize client

The Arize export button on tracing, embeddings and dataset pages generates a code snippet, and the Python export client returns pandas DataFrames. Those frames carry Arize's column layout, so reshape them before loading into Opik, mapping span hierarchy, inputs, outputs and metadata to Opik's trace and span structure. Test the reshaped data on a small time window first. Ask Arize to confirm any row or time-range limits on export for your plan, since those limits decide how many export runs you need.

Datasets and prompts as separate items

Datasets, prompt versions and evaluator definitions are separate objects in Arize, and none of them comes across with trace history by default. Export each dataset as its own file and recreate it in Opik with the same example fields. Prompts need their version history and the model settings attached to each version, so treat prompt versions as their own migration item and confirm with your team which versions are still in use before you copy them.

Evaluator templates and scores

Evaluator templates and their historical scores do not move automatically. Opik's LLM-as-a-judge metrics for hallucination, moderation and RAG are built-in options, but your custom Arize templates, judge prompts and scoring rules must be rewritten as Opik metrics. Keep the old scores in an archive table, because historical scores cannot be recomputed with the new judge and compared fairly against new runs.

OpenTelemetry exporters and endpoints

Applications that send traces through OpenTelemetry or OpenInference exporters must point at your self-hosted Opik endpoint instead of Arize. Check the exporter configuration, the authentication headers and the project or workspace name in every service, not only the main application. Opik supports OpenTelemetry, so the instrumentation code can often stay the same while the endpoint and credentials change. Run both exporters side by side for one release cycle to compare trace counts.

Framework integrations and @track decorators

Opik has native integrations for LangChain, LangGraph, LlamaIndex, CrewAI and 60+ other frameworks, and custom code uses the @track decorator. Each Arize instrumentor you removed or replaced needs its Opik counterpart, and each @track call needs review so spans nest correctly under agent steps. Inventory every instrumented service, because a service missed in this inventory will stop reporting traces without an error.

Pinning the Opik release

Opik's Docker Compose and Helm deployments are updated through new releases, and the latest tagged release at the time of your evaluation was 2.2.103, published on October 16, 2026. Pin the version you test against in your deployment manifests and record it in your change log. Before each upgrade, read the release notes for schema or API changes that affect your exporters, since an upgrade can change the client contract that your repointed services depend on.

The migration sequence from inventory to decommission

This sequence moves LLM tracing and evaluation from Arize AX to self-hosted Opik in controlled stages, so each service is proven on Opik before Arize stops receiving traffic. Each step produces a written artifact that the next step depends on.

Inventory traces, datasets, prompts and evaluators
List every Arize project, tracing space, dataset, experiment, prompt version, online evaluator and alert that your teams rely on, and map each one to the application or service that produces it. Record the retention period you need for traces and the owner of each evaluator, because those two items drive storage sizing and review sign-off later. Confirm the current export options and any plan limits with Arize before you rely on them. The output is an inventory list with one row per asset, its owner, its source service, and a yes or no for whether it must move or can be archived.
Deploy Opik and run a pilot on one service
Stand up Opik in your own infrastructure using the opik.sh script with Docker Compose for a non-production sandbox, or the Helm charts on Kubernetes for production. Choose one service with moderate traffic and a clear owner, then instrument it with either OpenTelemetry or the Opik SDK, including the @track decorator for custom code. Verify that traces show the full agent steps, that the ClickHouse, MySQL and Redis components are healthy, and that the storage and backup plan you chose in the inventory is in place. The output is a working pilot where the service's traces appear in Opik with the same spans and metadata that the team expects from Arize.
Rebuild evaluators and datasets on Opik
Recreate the evaluators from the inventory using Opik's LLM-as-a-judge metrics, such as those for hallucination, moderation and RAG, or custom metrics that your team writes. Re-create the priority datasets and prompts, then run the same test cases through both platforms to confirm the scores agree within the tolerance your team sets. Where a score differs, check the judge model, the prompt template and the input mapping before you accept the difference. The output is a short evaluator test record showing which evaluators were rebuilt, what they were compared against, and any gaps that still need manual review.
Run both platforms in parallel
Configure the pilot service to send traces to both Arize and Opik at the same time, and keep online evaluation running on both sides for a period your team agrees in advance. Compare trace counts, latency overhead, token and cost fields, evaluation scores and alert behavior each day through a shared review. Investigate every mismatch and record the cause, whether it is a missing attribute, a sampling difference or a configuration error. The output is a parity report that lists each metric, the observed agreement, and the sign-off from the service owner to move forward.
Write the cutover runbook
Prepare a runbook for each remaining service that names the exporter or OpenTelemetry endpoint to change, the environment variables and secrets to update, the evaluator to enable in Opik, and the rollback step if traces stop arriving. Schedule cutovers in small groups so that a failure affects one team at a time, and assign an owner who can approve the rollback. Confirm that access controls, single sign-on and user roles in your Opik deployment match the policy you apply to Arize. The output is a cutover runbook, reviewed by security and the service owners, with a rollback step for every service.
Cut over exporters and evaluators
Apply the runbook service by service, switching the exporters and enabling the rebuilt evaluators on Opik, then confirm that traces from each service reach Opik within the expected window. Turn off the Arize exporter only after the new path has run cleanly under real traffic. Record each change in the change management system so that the audit trail shows when each service moved. The output is a cutover log listing each service, the change time, the verification check, and the rollback status, with no service still sending to Arize unless it is on the agreed exception list.
Export history and decommission Arize
Export the trace history, datasets and evaluation results you need to retain from Arize using its export tooling, then load them into your archive or Opik and check record counts and sample contents against the inventory. Confirm that the retention you require is met in your own storage before you end the Arize subscription or remove the API keys and integrations. Keep a read-only copy of key evaluation results for audit purposes. The output is a decommission record that lists what was exported, where it is stored, who verified it, and the date Arize access was removed.

How to run Arize and Opik in parallel and cut over safely

Run both pipelines at the same time and cut over only after the team signs off. During the parallel window, keep the existing Arize exporters in place and add a second exporter that sends the same spans to a self-hosted Opik instance. Because Opik accepts OpenTelemetry, the simplest route is to add a second OTLP exporter in the application or collector configuration rather than rewriting instrumentation. Confirm the exact OTLP endpoint and authentication headers for your Opik deployment against the Opik GitHub repository and your own Helm values, since the endpoint depends on how you expose the service inside your network. Tag every span with an environment or migration marker so you can filter the two backends consistently.

Check parity by scoring the same sample of traces in both systems. Pick a fixed set of production traces, ideally drawn across the workflows and users that matter most, and run the equivalent evaluator in Arize and in Opik on identical inputs. Compare pass and fail outcomes and score distributions, and record disagreements with the trace IDs so engineers can inspect them. Judge models may differ between the two platforms, so scores will not match exactly. Agree on a documented tolerance before the comparison starts, covering acceptable score deviation and the share of disagreeing traces, and have the evaluation owner approve it in writing. Treat any metric that moves outside tolerance as a blocker until someone explains it.

Cut over only when the team signs off on dashboards and alerts. Rebuild each dashboard and alert rule in Opik, confirm that thresholds fire on the same synthetic or replayed failures, and get sign-off from the on-call, product and compliance owners named for that workload. Keep Arize as the system of record until that sign-off is recorded. Rollback is simple while Arize remains provisioned: repoint the exporters back to Arize, and keep the Arize subscription or self-hosted instance active until decommission is approved. Plan the decommission date only after the retention and export obligations for historical traces are met, and confirm with your data owner how long Arize-held data must remain accessible.

How the migration differs by starting point

A small team usually has a handful of instrumented services, a limited set of prompts and one or two evaluators that matter for release decisions. The migration is mostly a question of how much history you need to keep and whether the team can re-instrument a few services in a short working session. Because the trace volume is modest, the self-hosted footprint is also easier to reason about, though the team still needs someone who can run Docker Compose upgrades and back up the data stores.

Scope of history: Decide whether you need old traces for audits or only for reference. Many small teams export a recent window with the Arize export client and archive the rest in place.
Instrumentation: Re-instrument each service once, preferably with OpenTelemetry so later tooling changes stay cheap.
Evaluators: Rebuild the few LLM-as-a-judge metrics that gate releases first, and retire the rest until someone asks for them.
Infrastructure: Start with the local Docker Compose path described in the Opik README, and confirm with your own environment whether that setup is acceptable for your team's uptime needs.
Operations ownership: Name one person to own upgrades and backups, since no one else may have the context.

Before you cut over, confirm which Opik release you will deploy, check it against the releases page, and agree on who keeps the stores backed up.

What drives the cost and duration of the move

This table lists the factors that change the effort of moving from Arize AX to self-hosted Opik, who typically pays for each one, and whether it is a one-time or recurring cost. Use it to decide which numbers to collect before asking an implementation partner or your own platform team for a plan.

Driver	Why it changes cost or effort	Who pays and one-time or recurring	What to ask for in a quote
Instrumented services and frameworks	Each service using Arize OpenTelemetry or OpenInference exporters must be repointed to Opik, and frameworks such as LangChain or LlamaIndex may need different integration code.	Internal engineers or implementation partner, one-time	A service inventory, the list of frameworks in use, and which services need code changes versus endpoint changes.
Trace volume and retention	Opik stores traces in ClickHouse, MySQL and Redis that you size yourself, so storage, memory and backup needs follow your volume and retention window rather than an Arize span allowance.	Infrastructure budget, recurring; sizing work is one-time	Current daily trace volume, retention targets by environment, and a sizing estimate for ClickHouse, MySQL and Redis with growth assumptions.
Historical data export	Arize history must be pulled with its export client and reshaped before it can be loaded into Opik, which takes more work the more datasets and traces you keep.	Internal staff or partner, one-time	Which datasets, experiments and traces must move, the reshaping steps, and how imported history will be marked in Opik.
Custom evaluators and metrics	Each Arize evaluator, template and judge prompt must be recreated with Opik's LLM-as-a-judge metrics or custom metrics, and complex logic may need new code.	Internal ML or platform staff, one-time; judge model inference is recurring	An inventory of evaluators with complexity ratings, a mapping to Opik metrics, and the judge model costs you will carry.
Prompt library size	Prompts, versions and playground configurations must be exported and recreated in Opik's prompt management, and prompt links to traces and experiments need checking.	Internal product or ML team, one-time	Number of prompts and versions, owners, and how version history and trace links will be preserved.
SSO and access integration	Opik self-hosting must connect to your identity provider, role assignments and workspace structure, which can differ from the Arize access model.	Identity or platform team, one-time plus ongoing access reviews	Confirmation of the SSO protocol supported in your Opik version, role mapping, and the deployment steps for identity integration.
Infrastructure and operations	Running Docker Compose for evaluation or Helm charts on Kubernetes for production adds monitoring, backups, upgrades and on-call duties that Arize AX previously carried.	Platform team and infrastructure budget, recurring	Target environment, backup and restore plan, upgrade cadence, and the monitoring you expect from the partner.
Validation and parity testing	Teams must confirm that traces, scores, evaluator outputs and prompt versions match what Arize produced before cutting over, and keep both systems running for comparison.	Internal QA and domain experts, one-time; partner test effort if scoped	Acceptance criteria per feature, the parallel-run period, and sign-off roles before Arize is switched off.

What usually goes wrong when moving to Opik

Most failed Arize to Opik migrations do not fail in the tooling. They fail in the seams: evaluators that change silently, exporters that keep pointing at the old system, and an archive nobody verified before the old tenant was closed. Each card below names one of these failure points and the check that prevents it.

Evaluator scores drift between judge models

Arize evaluators and Opik's LLM-as-a-judge metrics for hallucination, moderation and RAG may call different judge models, use different prompt templates, or apply different thresholds. Scores from the two systems will not be comparable even when the wording looks the same. Before cutover, run the same labeled sample through both systems, record the judge model and template version in each, and agree on a tolerance for disagreement before you trust the new numbers.

Traces lost in unrepointed exporters

Applications instrumented with Arize's OpenTelemetry or OpenInference exporters keep sending spans to the old endpoint after a team deploys Opik for new services. Traces then split across two systems, and dashboards built on either side show partial pictures. Inventory every service, notebook and batch job that exports traces, change each endpoint and API key in one release, and confirm that trace counts per service match before the old exporter is removed.

Prompt versions detached from traces

Prompt versions stored in one tool and referenced by name in code can drift from the traces they produced. After migration, a trace may show a prompt that no longer exists under that identifier, which breaks root-cause analysis and experiment comparisons. Map each Arize prompt to its Opik prompt, keep a version mapping table, and test that a sample of migrated traces still links to the prompt version that generated them.

ClickHouse undersized for retention

Opik stores trace data in ClickHouse, along with MySQL and Redis, and the README states the platform handles 40M+ traces per day. The retention you need from Arize is a sizing input for your own cluster, not a plan setting you inherit. Ask Arize for your current span volume and retention, estimate storage per day from a sample of real traces, and size ClickHouse disks and backups for the full retention window plus headroom before importing history.

Forgotten SSO and access rules

Arize workspaces, space roles and API keys often grew up around individual users and service accounts that nobody wrote down. A self-hosted Opik deployment starts with its own access model, so users may lose project visibility or service accounts may fail silently after cutover. Export a list of users, roles and service accounts from Arize, map each one to an Opik workspace and project role, connect your identity provider where your deployment supports it, and test each group with a real login before cutover day.

Decommissioning Arize before the archive is verified

Teams often cancel the Arize subscription or delete projects as soon as the new dashboards look right, then discover that historical traces, datasets or evaluation results were never exported. Pull a full export through the Arize client, load it into a separate Opik project, and reconcile record counts and sample trace contents against the source. Keep the export files under your own retention policy and only close the Arize account after that reconciliation is signed off.

Questions teams ask before moving from Arize to Opik

How much effort and cost should we expect when moving from Arize to Opik?

The effort depends mostly on how much of your Arize setup is code you own and how many evaluators you run. Opik itself is Apache-2.0 licensed and its README states the full platform, including server, UI, evaluations and prompt management, can be self-hosted without a commercial license, so there is no license fee to budget for the software. The costs are the infrastructure you run (Opik uses ClickHouse, MySQL and Redis), the engineering time to re-instrument services, rebuild evaluators and reshape exported data, and any support retainer you buy. Infrastructure cost recurs and scales with trace volume and retention. Engineering time is largely one-time. Ask any implementation partner for a written fixed scope that lists services, evaluators, datasets and environments before work starts.

How long does an Arize to Opik migration take?

The timeline is set by the number of instrumented services, the number of evaluators and datasets to rebuild, and how much historical data you need to keep. Opik supports OpenTelemetry and native integrations with frameworks such as LangChain, LangGraph, LlamaIndex and CrewAI, so services already on standard instrumentation move faster than those relying on custom Arize code. Parallel running, where traces go to both platforms during a cutover window, adds time but lowers risk. No duration is set by a researched source for this migration, so ask for a timeline in the written scope and confirm the steps with your own engineers.

What does the internal team need to provide during the move?

You will need people who own each instrumented application, someone who understands your evaluation criteria, and an owner for the self-hosted infrastructure. Application owners change exporters or add the Opik SDK and the @track decorator where custom code is traced. Evaluation owners decide which quality checks must survive, because LLM-as-a-judge metrics in Opik differ from Arize evaluator templates and need to be rebuilt and validated against known outputs. Platform engineers run the Kubernetes or Docker Compose deployment, backups, storage sizing and access controls. Name these owners before scoping so that review and sign-off do not become the bottleneck.

Can our own engineers do the Arize to Opik migration without outside help?

Yes, a team with Kubernetes or container experience and familiarity with OpenTelemetry can do it in-house, since Opik publishes Docker Compose for local use and Helm charts for production. The harder parts are sizing ClickHouse storage for your retention target, rebuilding evaluators so scores are comparable, and planning the cutover without losing traces. Outside help is most useful for a fixed-scope engagement covering those items, hardening, backups and upgrades, or for an ongoing retainer. Whichever path you choose, decide it from your team's capacity, not from the product.

Can Opik take over our Arize evaluators without rebuilding them?

Usually not as a direct import. Arize evaluators are defined in Arize, and Opik has its own LLM-as-a-judge metrics for areas such as hallucination, moderation and RAG, plus online evaluation rules. Opik's README does not describe an automatic conversion of Arize evaluator definitions, so plan to recreate each evaluator in Opik, then run both on a sample of traces to compare scores before retiring the Arize version. Confirm the import options directly with Comet and check the current Opik documentation for any migration helper.

Does the Arize export client return all of our historical data?

Do not assume it does. Arize's export client returns data from the tracing, embeddings and dataset views you query, and you must confirm with Arize which projects, time ranges and fields it covers for your account and plan. Exported data usually needs reshaping before it loads into Opik, so map span fields, inputs, outputs and metadata to Opik's trace structure and test a small range first. Ask Arize to confirm any retention limits that might have removed older spans before you export, and record what was not recovered so stakeholders know the gap.

What does self-hosting Opik mean for uptime and upgrades?

You become responsible for availability, backups, security patches and version upgrades, which Arize's managed AX service otherwise handles. Opik's latest release is 2.2.103, published October 16, 2026, and upgrades should be tested in a non-production environment first, with ClickHouse, MySQL and Redis backed up before each change. Define recovery objectives and an on-call path before cutover. Comet offers Opik as a hosted service on Comet.com if you prefer to hand operations back, so confirm the operational model, support terms and any service levels with Comet before you decide.

How DeployOpen scopes and runs the Arize to Opik migration

DeployOpen plans, implements and hardens self-hosted Opik inside your own cloud account, data center or air-gapped network, so traces, evaluation results and prompts stay under your control from the first day. The engagement covers the Opik deployment itself (Docker Compose for local evaluation, or Helm charts on Kubernetes for production, with its ClickHouse, MySQL and Redis dependencies sized and backed up), the access model for your teams, network and TLS settings, and the upgrade path for each new Opik release. Before any work starts, scope, deliverables and timelines are agreed in writing, so your security, platform and data owners know exactly what will be built, tested and handed over.

On the migration side, DeployOpen rebuilds instrumentation and evaluators rather than copying them blindly. That means repointing applications to OpenTelemetry or the Opik SDKs, mapping exported Arize datasets into Opik datasets, recreating LLM-as-a-judge metrics and online evaluation rules, and testing each evaluator against known good and known bad traces before it is trusted. DeployOpen also prepares the evidence your compliance readiness work will need, such as configuration baselines, access reviews, backup and restore test records, and change logs. DeployOpen prepares these controls and records, but independent auditors and certification bodies issue any audit report or certification. Ongoing support, upgrades and continuous testing are available as retainers after handover.

DeployOpen does not publish a price list. A quote follows from the written scope, and the main drivers are the number of applications being re-instrumented, the number of evaluators to rebuild, the deployment target, and whether an air-gapped install and offline image mirroring are required. Ask for the quote to separate one-time work (deployment, migration, hardening, documentation) from recurring items (retainer support, upgrades, testing), and ask which of your own staff time, cloud or hardware costs sit outside the quote.

Migrate from Arize to Opik