How to migrate from Arize to Langfuse without losing trace history
If a renewal, a data residency requirement or a licensing concern is pushing you off Arize AX, plan for two kinds of work: repointing your OpenTelemetry and OpenInference exporters at a new endpoint, and rebuilding datasets and evaluators on the Langfuse side. Trace history does not move on its own, so it needs a deliberate export plan that starts before you cut over. Most teams run this as a joint effort between platform engineering, the ML or LLM application team that owns the instrumentation, and a named data owner who decides what history must be kept, for how long and who may read it. Self-hosted Langfuse is more than one container. The deployment runs Langfuse Web and Langfuse Worker, backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Your platform team owns sizing, backups, network policy and upgrades for all four stores, and the scaling guide's minimum figures for ClickHouse are the starting point for storage planning. Before you commit, confirm how much trace history you need to carry over, because ClickHouse disk headroom drives the bill more than anything else.
On effort and risk, the instrumentation change is usually the smaller part when your code already emits OpenTelemetry spans, since the change is mostly endpoint and credential configuration in the exporter. Datasets, evaluators and annotation workflows take more care because their logic has to be re-expressed, and any human review steps need owners in the new tool. Confirm the export options for your own Arize tenant, including what format and fields come out and whether your plan includes bulk export, because the path you can use determines how much history is practical to bring across. Run both backends in parallel for a short window, compare span counts and evaluator scores on the same traffic, and keep the Arize data read-only until the agreed retention period ends. Ask any implementation partner for a written scope that lists which history is migrated, which is archived and which is dropped, since that decision matters more to auditors and data owners than the tooling itself.
Which Arize AX capabilities map cleanly to Langfuse and which need rework
This table maps the main Arize AX capabilities that teams rely on to their Langfuse equivalents and marks each as clean, needs rework or gap. Read it as a planning checklist: rework rows describe work your team will carry out, while gap rows need a decision before cutover. Features not listed here must be confirmed with Arize before you commit.
| Capability | Langfuse equivalent | Status |
|---|---|---|
| Tracing and OpenTelemetry ingestion | Langfuse accepts OpenTelemetry traces over its OTLP endpoint, so spans from OTel SDKs can be sent to Langfuse with exporter settings changed | Clean |
| OpenInference-instrumented spans | Langfuse maps common LLM attributes, but OpenInference span attribute names should be tested on sample traces before cutover | Needs rework |
| Datasets and experiments | Langfuse datasets and experiment runs must be recreated; Arize dataset exports need reshaping into Langfuse item format | Needs rework |
| LLM-as-a-judge evaluators | Langfuse LLM-as-a-judge evaluators need prompts, judge models and variable mappings rewritten and checked against scores from Arize | Needs rework |
| Annotation and human review | Langfuse annotation queues cover basic review, but reviewer workflows and score schemas from Arize will need redesign | Needs rework |
| Prompt management | Langfuse prompt versions and labels cover versioning, but links from prompts to historical traces must be re-established | Needs rework |
| SSO and SCIM provisioning | Langfuse SSO is available, while project-level RBAC roles and SCIM need the enterprise license key | Needs rework |
| Data retention policies | Langfuse retention policies require the enterprise license key, and storage must be sized in ClickHouse for the retention you need | Needs rework |
| Data residency | Self-hosted Langfuse keeps data in your own infrastructure and region, so residency depends on your cloud or data center choice | Clean |
What data and integrations move, and which paths are documented
Not every part of an Arize AX workspace has a documented path into Langfuse. Trace history, instrumentation, datasets and evaluators, and access controls each move differently, so plan them as separate workstreams. The cards below separate what you can repoint from what you must export, reshape or rebuild by hand.
Trace and span history
Historic traces are the data teams most often want to keep, but Langfuse's documented path is ingestion of new telemetry. Confirm with Arize which export path your plan and deployment offer, then confirm whether Langfuse has a direct import for that format. Usually you reshape spans into Langfuse's trace and observation model. Check that token usage, model names, timestamps and user or session identifiers survive the reshape, because cost and filtering views depend on them. Decide early how much history you need on day one.
Application instrumentation
Services that send traces to Arize through OpenTelemetry exporters can be repointed to Langfuse's OpenTelemetry endpoint, which Langfuse documents in its OpenTelemetry guide. Keep OpenInference attributes on spans only where Langfuse maps them, and test a sample of each span type before cutover. An OpenTelemetry Collector can sit between your services and both backends during a parallel run. Confirm the attribute mapping for each framework and language your teams use.
Datasets and evaluators
Plan to recreate datasets and evaluators in Langfuse, and do not assume a direct transfer. Export dataset items, expected outputs and evaluator definitions from Arize, then rebuild them in Langfuse and compare scores on a sample before you rely on them. Human-labeled data, such as annotations and review scores, needs its own export and mapping because it is tied to specific traces. Record which evaluator version produced each historic score so later comparisons stay honest.
Identity and access
SSO for self-hosted Langfuse is covered in its authentication and SSO guide, so confirm that your identity provider is supported before cutover. Some administration features need an Enterprise license key, including project-level RBAC roles, audit logs, data retention policies and SCIM through the organization management API. Map existing Arize workspace roles to Langfuse projects, and check whether the open-source access model meets your audit requirements. Review the key-gated features with your security team before inviting users.
The sequence to migrate from Arize to Langfuse, step by step
This sequence moves LLM tracing and evaluations from Arize AX to a self-hosted Langfuse deployment in controlled stages, so each service is proven before production traffic is switched. Each step ends with a written output that the next step depends on.
Inventory services, exporters and evaluation assets
Platform engineering and the application teams list every service that sends traces to Arize AX, including the OpenTelemetry or OpenInference instrumentation and SDK versions in use, the exporter endpoints and credentials, and each dataset, evaluator, prompt and online evaluation rule. For each item, record the retention period your compliance and audit teams require, because retention drives ClickHouse sizing later. The output is an inventory register with one row per service and asset, an owner for each row, and a retention requirement signed off by the compliance lead.
Stand up Langfuse for a pilot service
Choose one non-production service with moderate trace volume and deploy Langfuse in a test environment using Docker Compose on a single VM, which the Langfuse self-hosting documentation describes for testing only and without high availability. Point the pilot service's exporter at Langfuse through its OpenTelemetry endpoint and confirm that traces, sessions and scores appear. The output is a pilot sign-off record listing the Langfuse version, the instrumentation used, the issues found and the decision to proceed or repeat the pilot.
Rebuild datasets and evaluators in Langfuse
Recreate the datasets, LLM-as-a-judge evaluators, annotation queues and prompt versions from the inventory in Langfuse, using the Arize exports as input where the formats allow. Keep the evaluator prompts and scoring scales identical so results can be compared. Where Arize evaluation logic cannot be reproduced exactly, document the difference and the human review step that replaces it. The output is a mapping sheet that links each Arize evaluator and dataset to its Langfuse counterpart, with the known differences recorded.
Run dual export through an OpenTelemetry Collector
Deploy an OpenTelemetry Collector between the production services and both backends, so that each trace is exported to Arize AX and to Langfuse at the same time. The Collector's configuration is version-controlled and its exporter credentials are managed through the Collector's authentication options. Run both backends in parallel until dashboards, trace counts and evaluator scores agree within the tolerance the evaluation owners set in advance. The output is a comparison report covering trace volume, latency, token usage, evaluator scores and any gaps, signed off by the evaluation owners.
Cut over production exporters
During an agreed change window, switch each production service's exporter from Arize AX to Langfuse through the Collector, and confirm that new traces arrive in Langfuse and that alerts and dashboards built on Langfuse data fire as expected. Freeze writes to Arize AX by removing its exporters from the Collector configuration, so no new data is sent there after cutover. Keep the Arize project readable for the rollback period the operations team defines. The output is a cutover record listing each service, the time of switch, the verification checks passed and the rollback owner.
Decommission Arize and document retention
Once the rollback period has closed, export the final Arize history through the Arize client, store it in the retention location the compliance lead approved, and confirm the export is complete and readable. Revoke Arize API keys and remove any remaining credentials from Collectors, CI pipelines and secrets stores. Record how long traces, scores and exports are kept in Langfuse and in the archive, and which ClickHouse and object storage settings enforce that. The output is a retention record and a decommission checklist, filed with the inventory register so auditors can trace where each dataset now lives.
Repointing exporters without breaking traces during the parallel run
Run the parallel period through an OpenTelemetry Collector rather than editing each service's exporter twice. The Collector is the safest place to fan out, because one pipeline can receive spans from your services and export them to both Arize AX and self-hosted Langfuse. Services keep a single OTLP endpoint, and switching the Arize exporter off later becomes a Collector configuration change instead of a code release across every team. Langfuse ingests traces over OpenTelemetry, so the Collector's OTLP exporter is the natural path, but confirm the Langfuse endpoint, authentication headers and project keys against the Langfuse OpenTelemetry guide before you wire it in.
Keep trace IDs and attributes identical on both sides before you compare anything. Both backends should receive the same trace and span IDs, and the same OpenInference attributes that carry prompts, model names, token counts and tool calls. Check that the Collector does not rewrite these fields in a processor, and that resource attributes such as service name and environment are set the same way for each team. Mismatched names are the most common reason a dashboard in the new tool looks empty even though data is arriving. Pilot with one service first: point a single low-traffic service at the Collector, confirm that its traces appear in both backends with matching IDs and attributes, then move the shared pipelines once that check passes.
Treat the Collector as supply chain software and review it before production. Collector releases ship the contrib distribution with signed artifacts, SHA256 checksums and SBOM files, so verify the signature and checksum of the binary you deploy and record the SBOM in your inventory. Pin a release version rather than tracking latest. Next, review the stability of each component in your configuration, because core Collector components have mixed stability levels documented in each component's README. Use the OpenTelemetry status page as a starting point. Finally, remember that OpenTelemetry is not a storage backend. It moves telemetry but does not keep it, so Langfuse still needs its own PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage tier sized for your retention target, and that tier is a separate cost and capacity decision.
What drives migration cost and duration, and how to keep each one down
This table lists the factors that move effort when moving Arize AX tracing and evaluations to self-hosted Langfuse, why each one matters and what reduces it. Use it to scope the work and to check that a quote covers each driver. No time or cost figures are given here, so ask for them in the written scope and quote.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of services and SDK versions | Each service emitting traces needs its exporter repointed, and mixed Arize, OpenInference and OpenTelemetry SDK versions multiply the test matrix. | Inventory every instrumented service before scoping. Standardize on OpenTelemetry exporters with a shared configuration, and migrate in waves by service owner. |
| Volume of history to carry over | Arize exports and reshaping take effort in proportion to the trace history kept. Most teams carry only a recent window plus active datasets. | Agree a retention cutoff with compliance early. Export only the traces and datasets still used for audits, debugging or regression tests, and archive the rest in place. |
| Evaluator and annotation complexity | Evaluation templates, judge prompts, scoring scales and human annotation queues must be recreated and checked against known results in Langfuse. | Count evaluators and split them into automated judges and human review. Retire unused evaluators first and keep a baseline set of scored examples to confirm parity. |
| Enterprise features needed (RBAC, retention policies, audit logs, SCIM) | Project-level RBAC, data retention policies, audit logs and SCIM provisioning need an Enterprise license key in self-hosted Langfuse, which affects both licensing and configuration work. | List required controls before design. Confirm with Langfuse which features need the license key, and ask the quote to state whether it covers them or only the open-source build. |
| ClickHouse sizing and backfill headroom | ClickHouse is the main storage component. Retention length and ingest rate set disk size, and Langfuse advises about 3x ClickHouse disk headroom when backfilling historic data. | Model trace volume and retention before provisioning. Reserve backfill headroom in the design, and load history in batches so ingestion for live services is not delayed. |
| Upgrade path to Langfuse v4 | The v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and moves to an observations-first data model, so older installs need planned migration work. | Start on a supported version and check the v3 to v4 guide against your current stack. Test the migration on a copy of production data before cutover. |
| Residency and air-gapped approvals | Where traces and prompts must stay in a region or off the internet, approvals for hosting, image mirroring and offline upgrades add review steps before any build starts. | Get residency and network approvals in writing before design. Confirm which container images, documentation and evaluator models must be mirrored in advance. |
| Scope definition and written quote | Unclear boundaries between migration, evaluator rebuilding, training and ongoing support are the most common source of overruns. | Agree scope, deliverables and timelines in writing before work starts, and ask the quote to itemize each driver above as in or out of scope. |
What usually goes wrong in an Arize to Langfuse migration
Most failed Arize to Langfuse migrations fail on sequencing rather than software. The history path, evaluator fidelity, storage sizing, enterprise features, upgrade prerequisites and the end date of parallel running all decide whether the cutover holds. Each card below names one risk and the check that prevents it.
Losing history before the export path is proven
Teams often start the Langfuse build before confirming how historical traces, datasets and evaluation results can leave Arize AX. Export formats differ from Langfuse's import model, so spans may need reshaping before they can be loaded. Ask Arize in writing which export methods your plan and region support, run a sample export of one project end to end, and confirm that trace IDs, timestamps and metadata survive the round trip before any production switch.
Silent drift in evaluator scores
When LLM-as-a-judge evaluators are recreated, the prompt wording, judge model, temperature and output parsing can change without anyone noticing. Scores then look comparable on dashboards while measuring something slightly different. Before cutover, run the old and new evaluators over the same frozen set of traces, record the score differences, and agree a tolerance with the team that owns the quality thresholds.
ClickHouse sized for the wrong retention
ClickHouse holds the trace and observation volume, so storage grows with span count and the retention you choose. Teams that size the cluster from current daily volume often discover that a longer audit or evaluation window needs much more disk. Write down the retention period your compliance and debugging needs require, measure real span sizes from a pilot, and ask your platform team to size memory and disk against that figure rather than against the default test setup.
Enterprise features missing at cutover
Some capabilities that regulated teams rely on sit behind a Langfuse enterprise license key, including project-level RBAC roles, data retention policies, audit logs, server-side data masking and SCIM provisioning. If these were used in Arize or are required by your security review, they must be confirmed before go-live. Make a list of current access controls and audit needs, map each to the open-source version or to the enterprise key, and get the license decision signed off before the migration date.
Upgrade surprises from v3 to v4
Langfuse's v3 to v4 guide moves the data model to observations first and requires newer infrastructure: ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later. Backfilling historic data needs roughly three times ClickHouse disk headroom. If the platform is built on older database versions, or the team plans to upgrade after go-live without a test, the upgrade can stall. Check your database versions and disk headroom in a staging copy before choosing the v4 path.
Parallel runs that never end
Teams often keep Arize and Langfuse both receiving traces for months because nobody owns the decommission decision. Costs continue on both sides, dashboards diverge, and engineers stop trusting either source. Set an explicit cutover date tied to named criteria, such as parity on agreed evaluators and completed history import, assign an owner for switching off Arize exporters and archiving data, and record the decommission in the change log.
How the migration differs by starting point and team size
Teams on the managed Arize AX service with a small set of instrumented applications usually have the shortest path. The work centers on repointing exporters: applications already emitting OpenTelemetry or OpenInference spans can usually send the same spans to a Langfuse OpenTelemetry endpoint, so the main code change is endpoint and credential configuration rather than re-instrumentation.
- Sequence: stand up a non-production Langfuse instance first, send one service's traces to it in parallel with AX, then move the remaining services.
- Data work: export only the datasets and evaluation records you still need, and recreate evaluators in Langfuse rather than expecting them to carry over.
- Approvals: the security team should sign off on where Langfuse stores traces, since ClickHouse and object storage will hold the prompt and completion content.
- Storage planning: size ClickHouse for the retention window you need, not for the span count you see today.
- Parallel running: keep AX active until dashboards and alerts have been rebuilt and checked against the new backend.
Before starting, confirm with Arize the export formats and the data retention terms on your current plan, and confirm with your internal security team which trace fields may leave the AX region.
Teams already using Arize Phoenix are typically self-hosting its tracing tool and want an OSI-licensed option. Phoenix and Langfuse both accept OpenTelemetry data, so the instrumentation layer often survives the move. The licensing question matters here: Phoenix is licensed under the Elastic License 2.0, while Langfuse code outside its ee directories is MIT licensed.
- Sequence: deploy Langfuse alongside Phoenix, route a copy of spans to both, and compare trace structure before cutting over.
- Data work: Phoenix stores its own trace and evaluation tables, so plan a reshaping step for any historical data you want to keep.
- Approvals: legal or procurement should confirm the license change is acceptable, and that enterprise features used in Langfuse, such as data retention policies or audit logs, are either not needed or covered by an enterprise key.
- Operations: Langfuse adds PostgreSQL, ClickHouse, Redis or Valkey and object storage, so the platform team must own more components than with Phoenix.
- Evaluators: rebuild LLM-as-a-judge evaluators in Langfuse and validate their scores against a sample of known results.
Confirm the Langfuse license scope with your legal team and check the enterprise feature list against your access control requirements before you commit.
Teams running self-hosted Arize AX on Kubernetes under an enterprise contract already operate a cluster and have a support relationship with Arize. The migration is less about tooling and more about contract timing, data ownership and cluster capacity. Arize documents self-hosting on Kubernetes across several cloud and private platforms, which means the cluster may be ready to host Langfuse with new namespaces, storage classes and secrets.
- Sequence: deploy Langfuse with Helm into a separate namespace, sized to the components in its scaling guide, before moving any workload.
- Capacity: ClickHouse needs the largest share of memory and disk, and backfilling history can require extra disk headroom, so review storage before the first import.
- Approvals: the platform owner, the cluster operator and the contract owner should agree on the cutover date and on how the AX contract ends.
- Data work: export AX datasets and evaluations early, because access can change at contract end.
- Operations: add Langfuse upgrade windows to the existing change calendar, since major versions require their own migration steps.
Ask Arize for the exact exit steps and data export rights in your contract, and confirm with your platform team whether the cluster has the spare capacity you need.
Teams in regulated sectors or on networks without internet access face the most work before any trace moves. Every container image, Helm chart, and dependency must be mirrored into an internal registry, and upgrades must be staged through that same path. Langfuse runs on PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and each of these needs an internal source and a tested version.
- Image mirroring: list every Langfuse container and each backing service, then mirror them with signatures and checksums your security team accepts.
- Upgrades offline: plan major upgrades as separate projects, because they follow dedicated migration guides and require specific ClickHouse, PostgreSQL and Redis versions.
- Approvals: involve the information security office, data protection officer and change board before pilot data is sent, and document where prompts and completions are stored.
- Access control: check which features used in your access model need an enterprise license key before go-live.
- Evidence: keep records of configuration, retention settings and approvals for your compliance readiness file, noting that independent auditors make the assessment.
Confirm with your internal security team which data classes may be stored in each region, and confirm with Langfuse which license terms apply to your deployment before you schedule the cutover.
How to plan ClickHouse storage for the retention you need
Retention in self-hosted Langfuse is a sizing decision before it is a setting. ClickHouse is the analytical store that holds the trace and observation data Langfuse queries, so the number of days you keep traces drives disk, memory and backup planning from day one. The Langfuse scaling guide lists minimum resources of 2 CPU and 8 GiB of memory for ClickHouse, and recommends at least 16 GiB of ClickHouse memory for larger deployments. Those are floors for a pilot, not a production answer. Treat them as the starting point for the sizing exercise, alongside PostgreSQL at 2 CPU and 4 GiB and Redis or Valkey at 1 CPU and 1.5 GiB.
Size from your own numbers. Measure average trace size and daily trace volume from a pilot that sends real Arize traffic through the new exporters for a representative period, then multiply by the retention window your compliance and evaluation needs require. Include evaluation runs and any backfilled history, since those write data too. If you are moving to the v4 data model, plan for the upgrade cost as well: the v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, and it requires ClickHouse 25.12 or later (26.4 recommended). Confirm the exact disk and memory figures with Langfuse for your volume rather than relying on these minimums.
Retention policies themselves are gated. Per-project data retention policies are one of the self-hosted features that need an Enterprise license key, so if you need automatic expiry rather than manual cleanup, price that key into the plan. Ask for a written sizing review as part of the fixed scope, covering the pilot measurements, the ClickHouse and PostgreSQL sizing, backup and restore of ClickHouse, the upgrade headroom and the retention policy approach, so that storage decisions are documented and signed off before production cutover.
How much effort does a migration from Arize to Langfuse take?
What drives the effort of moving from Arize AX to self-hosted Langfuse?
The effort depends mostly on how many services emit traces, how many datasets and evaluators you rebuild, and how much history you need to carry over. Instrumentation changes are usually the bulk of the hands-on work, because each exporter must point at the Langfuse OpenTelemetry endpoint and be tested. Infrastructure is a separate workstream: you run PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, and each needs sizing, backups and monitoring. Whether your team can do it internally depends on Kubernetes and data platform experience, available engineers and a test window. Ask any implementation partner for a written breakdown by workstream, so you can see which parts your staff can own.
Can we move our Arize trace history into Langfuse?
Historical traces can usually be exported from Arize and reloaded, but the work is a data reshaping exercise, not a copy. Arize's Python export client returns data that must be mapped to Langfuse's trace, observation and score structures before import. Expect to decide which history matters for audits and which can stay in the Arize archive for a defined period. Datasets and evaluation results need the same review. Confirm with the vendors the export limits and formats that apply to your Arize plan and Langfuse version before you commit to a full backfill.
What does the migration require from our team?
Plan for named owners in four areas: platform engineering for the cluster and data stores, application teams for instrumentation changes, an evaluation owner for datasets and evaluators, and a security or compliance contact for access and retention decisions. You will need administrative access to your Kubernetes cluster and cloud accounts, API access to the Arize workspace including export rights, and a test window in which both platforms receive traffic. Confirm with Arize, in writing, that your contract and plan allow the export you need before the project starts.
Do we need a Langfuse enterprise license to self-host it?
No. Core Langfuse features and APIs are available in the MIT-licensed open source version, and self-hosted deployments use the same codebase as Langfuse Cloud. An enterprise license key is needed only for certain features in the ee directories, such as project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, and the SCIM and instance management APIs. Check which of these your governance requirements depend on, because they determine whether the Enterprise plan is needed. The Self-Hosted Enterprise plan also adds a named support engineer, solutions architect access and a support SLA, and its price is set by quote.
What does a Langfuse upgrade require, and how is it planned?
Updates within a major version are designed to be non-disruptive, and database migrations run automatically at startup. Major upgrades follow dedicated migration guides, and the v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later. It also moves to an observations-first ClickHouse data model and advises about 3x ClickHouse disk headroom when backfilling historic data, so storage must be sized before the upgrade. Build a test environment, rehearse the upgrade against a copy of your data, and schedule it. Ongoing upgrades can be covered by a support retainer or handled by your internal team.
How does a fixed-scope engagement differ from ongoing support?
A fixed-scope engagement covers a defined set of deliverables, such as the Langfuse deployment, instrumentation changes for named services, dataset and evaluator rebuilds, and handover documentation. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Ongoing support is a retainer for work that recurs, such as upgrades, continuous testing, backups checks and incident response. Ask for the boundary between the two in writing, including who owns the cluster after handover and which upgrades are included. DeployOpen does not publish a price list.
How DeployOpen scopes, runs and supports an Arize to Langfuse migration
DeployOpen plans and implements self-hosted Langfuse inside your own cloud account, data center or air-gapped network, and hardens it, backs it up and documents it. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every Arize AX tracing project, dataset, evaluator and prompt that must carry over to Langfuse.
- Agree in writing which exporters, SDK calls and OpenInference mappings will be repointed to Langfuse.
- Define the trace retention window and the ClickHouse sizing approach the written scope will cover.
How we build
- Deploy self-hosted Langfuse with its web, worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage components.
- Repoint OpenTelemetry and OpenInference exporters, then verify traces arrive with the expected attributes.
- Recreate datasets and LLM-as-a-judge evaluators in Langfuse and test them against sample traces before cutover.
How we hand over
- Document the deployment, configuration keys, exporter changes and rollback steps for your platform team.
- Walk through evaluator definitions, dataset ownership and how each Langfuse feature maps back to Arize.
- Deliver backup and restore procedures, along with upgrade notes for future Langfuse major versions.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Langfuse version upgrades, including dedicated major-version migration guides.
- Confirm with us during scoping which support level, including any Langfuse enterprise license needs, fits your team.
