How to migrate from Langfuse to Currai

Migrating from Langfuse to Currai does not require replacing your tracing calls. Currai accepts the Langfuse ingestion format, so an existing Python or TypeScript client can send new telemetry to Currai after you change its host.

This guide covers the operational work around that configuration change: taking a baseline, running a canary, checking the data that arrives, cutting over, and keeping a rollback path.

What changes and what stays the same

The client destination and project credentials change. Your existing calls for traces, spans, generations, scores, tags, sessions, and users stay in place.

Changing the destination affects new telemetry only. It does not copy historical records from a Langfuse project into Currai. Keep the old project available for the retention or export period your team requires.

Before changing production traffic, record a baseline trace in Langfuse. Choose one that contains the structures your application relies on, such as:

• A root trace with input and output.
• At least one span and generation.
• Model parameters and token usage.
• Session ID, user ID, tags, and metadata.
• A score or error observation, if your application sends them.

You will compare the Currai result against this baseline during the canary.

Create a Currai project and keys

Create a Currai project and copy its public and secret keys. Store them in the same secret manager you use for the current Langfuse credentials. Do not reuse a production secret in local scripts or commit either key to the repository.

Use separate environment variables during the canary so rollback is a configuration change rather than a code change:

CURRAI_PUBLIC_KEY=pk-lf-...
CURRAI_SECRET_KEY=sk-lf-...
CURRAI_HOST=https://www.currai.app

Point the Python SDK at Currai

Keep your instrumentation and replace the client configuration:

import os
from langfuse import Langfuse

client = Langfuse(
    public_key=os.environ["CURRAI_PUBLIC_KEY"],
    secret_key=os.environ["CURRAI_SECRET_KEY"],
    host=os.environ.get("CURRAI_HOST", "https://www.currai.app"),
)

Calls made through client now send new events to the Currai host. No trace, span, or generation call needs to change.

Point the TypeScript SDK at Currai

The TypeScript client uses baseUrl for the destination:

import { Langfuse } from "langfuse";

const client = new Langfuse({
  publicKey: process.env.CURRAI_PUBLIC_KEY!,
  secretKey: process.env.CURRAI_SECRET_KEY!,
  baseUrl: process.env.CURRAI_HOST ?? "https://www.currai.app",
});

Keep the previous host and credentials available in your deployment system until the canary has passed and the rollback window closes.

Run a canary before the cutover

Deploy the new configuration to one development, staging, or low-traffic service instance. Send a known request that exercises the same observations as your baseline. Flush the client before the script exits or the serverless response is finalized.

Check the resulting Currai trace field by field:

1. The trace name, input, output, timestamps, and metadata are present.
2. Spans and generations have the same parent-child structure.
3. Model, parameters, prompt input, completion output, and token usage are attached to the generation.
4. Session and user identifiers group requests as expected.
5. Scores, tags, release, version, and environment fields arrive if you use them.
6. Error levels and status messages remain attached to the failed observation.

Also check request logs for authentication errors, rejected payloads, or events left in the local queue. A visually similar trace is not enough if a field used by your dashboards or evals is missing.

Cut over in stages

Move one service or deployment group at a time. After each stage, compare trace volume, ingestion errors, nested structure, token totals, and the fields your team filters on. Keep the stage small enough that you can inspect individual traces instead of relying only on aggregate counts.

Once the canary and first production stage match the baseline, promote the same configuration to the remaining services. Leave the old Langfuse project read-only during the rollback window so historical investigations still have a stable source.

Roll back without changing instrumentation

If validation fails, restore the previous host and credentials and redeploy. The instrumentation code has not changed, so the rollback does not require reverting trace calls throughout the application.

Keep a sample of the rejected or incomplete payload and note the SDK version, runtime, and missing field. That information separates an ingestion compatibility issue from a client lifecycle problem such as a missing flush.

Common migration problems

The request succeeds but no trace appears

Confirm that the public and secret keys belong to the same Currai project. Then flush the client and check that outbound requests can reach the configured host. Short-lived processes often exit while events are still queued.

Traces appear without their children

Check that spans and generations are ended before shutdown. If only some child events are missing, compare their timestamps and flush behavior with the root trace rather than rewriting the parent-child instrumentation.

Cost or token totals differ

Inspect the raw usage fields on the generation. A trace can have the correct shape while missing token usage from the model response. Compare model names and input, output, and total token values before comparing calculated cost.

Historical traces are missing

The host change routes future telemetry; it is not a historical-data import. Use the previous Langfuse project for older records and set its retention or export policy before closing access.

After the migration

Use one of the validated production traces as the first Currai regression case. Add an eval, connect the generation to a managed prompt version, or compare latency and cost across traces. These steps are additive and do not require changing the Langfuse-compatible ingestion path.

Related Currai pages

• Compare Currai as a Langfuse alternative
• Authentication
• Troubleshooting
• OpenTelemetry ingestion