Skip to main content

Migration guide

Moving from direct provider SDK calls — or from another LLM gateway — to DVARA is intentionally a small change: switch the base URL, swap the API key, ship. Drop-in OpenAI compatibility means governance kicks in on call one, with no client-side rewrite required.

This page covers the three most common migration scenarios end-to-end. Detailed per-language code lives on the Python, JavaScript / TypeScript, and Java integration pages — those are the canonical references. This page focuses on the path through the migration, not the SDK syntax.

From direct OpenAI​

The simplest case. Your application is already calling OpenAI through their SDK; you want governance, audit, multi-provider routing, and per-tenant cost attribution without touching the request shape.

  1. Provision DVARA. Run the Quickstart — pick a deployment topology, set OPENAI_API_KEY so the gateway can call OpenAI on your behalf, and create a tenant + DVARA API key in the Flightdeck.
  2. Change two values in your app. Set base_url (or baseURL / .baseUrl()) to http://your-dvara-host/v1, swap the OpenAI API key for your DVARA API key. Nothing else changes — the request body, streaming semantics, structured-output payloads, tool-calling shape are all OpenAI-compatible verbatim.
  3. Verify. Send a single request and confirm it shows up in the Flightdeck Dashboard's live metrics, in the Audit page (GATEWAY_REQUEST / GATEWAY_RESPONSE events), and in the Cost Dashboard.

After step 3, governance is live: every subsequent request runs through policy, PII scanning, budget enforcement, and the audit trail before reaching OpenAI.

From direct Anthropic / Bedrock / Gemini​

Same shape, with one change in the model field.

  1. Provision DVARA with the upstream credentials DVARA needs (ANTHROPIC_API_KEY, BEDROCK_ENABLED=true plus AWS creds, GEMINI_API_KEY).
  2. Switch your client. The Python and JavaScript pages recommend dropping the provider's native SDK in favour of the OpenAI SDK pointed at DVARA — DVARA translates claude-*, bedrock/*, and gemini-* model strings to the upstream wire format internally. You keep one SDK across every provider.
  3. Verify the same way as the OpenAI path — first request, then dashboard, audit, cost.

Why drop the provider-native SDK? One SDK, multi-provider governance. When you stop spreading three SDKs across the codebase, switching from Claude to GPT to Gemini becomes a one-field change instead of a deploy.

From another LLM gateway (Portkey, LiteLLM Cloud, OpenRouter, etc.)​

Same base-URL swap as the OpenAI path. The only extra step is moving the policy / budget / audit configuration from the old gateway's UI to DVARA.

  1. Provision DVARA. Same as the OpenAI path.
  2. Map the old gateway's config. Most gateways express the same primitives DVARA does — virtual keys, rate limits, model routing. The shape differs but the concepts map directly:
    • Virtual keys → DVARA API keys (per-tenant, Tenants & Users)
    • Routes / model fallback → DVARA routes (Routes & Policies) — strategies include latency-aware, cost-aware, weighted, canary
    • Rate limits / budgets → DVARA budget caps (Cost management) — global / tenant / per-API-key, hard + soft limits
    • PII rules → DVARA PII detection (PII Detection)
    • Logs → DVARA audit trail (HMAC-signed, hash-chained) — exportable to Splunk / CloudWatch / Kafka
  3. Move governance to DVARA that the old gateway didn't have. This is the lift step. Most existing gateways treat governance as an afterthought; DVARA treats it as the architecture. Things you'll likely add now that you couldn't before: Policy-as-Code, immutable audit, MCP proxy governance, agentic loop detection, approval gates, data residency enforcement, structured compliance reports.
  4. Cut over by environment. Run DVARA alongside the old gateway and shift one environment at a time (dev → staging → prod) so you can compare audit events and dashboards side by side before retiring the old surface.

For a side-by-side feature comparison against Portkey or LiteLLM Cloud specifically, see /migrate-from-portkey and /migrate-from-litellm-cloud on the marketing site.

Rollout patterns​

Two patterns work well for production migrations:

  • Per-environment cutover — shift dev / staging / prod sequentially. Lowest risk; mature observability before each step.
  • Per-tenant cutover — point one tenant at DVARA via DNS or feature flag, run for a week, expand. Right when you can't take the whole fleet down at once.

In both cases, keep your old surface running for at least one full audit / billing cycle so you can reconcile usage and spend numbers across the cutover.

What if I need a feature my current setup has?​

If a feature you rely on isn't yet in DVARA, the Provider Setup and Routing pages cover what's currently in scope. For provider-specific gaps — vision on Mistral, tool calls on Cohere — see Provider capability gaps in this release for the workaround tables.

Next steps​

Last updated on