Skip to main content
Migration guide

Migrate from LiteLLM to DVARA.
Keep the cutover reversible.

LiteLLM and DVARA can both sit in your environment and accept OpenAI-compatible requests. The real migration is not the base URL. It is rebuilding identity, routing, limits and governance so the new path behaves the way your applications expect.

Set up DVARACompare DVARA and LiteLLM

What changed about the migration premise?

LiteLLM no longer presents “LiteLLM Cloud” as a separate managed service. Its former Cloud address now leads to its self-hosted Enterprise offering. This guide therefore covers moving from a current LiteLLM Proxy or Enterprise deployment to DVARA—not moving from hosted SaaS to self-hosted software.

Map what you use before changing traffic

There is no one-click import. Use the current LiteLLM configuration as an inventory, then rebuild and review each control in DVARA.

In LiteLLMIn DVARAMigration action
Model list, aliases and model groupsProviders, ordered routes, model patterns and optional pinned model versionsRecreate each public model name deliberately. DVARA patterns and provider capability checks do not import LiteLLM aliases.
Virtual keys, users and teamsWorkspaces, roles and DVARA API keysCreate new keys and rotate clients to them. Do not copy or reuse existing key material.
Budgets and rate limitsWorkspace and API-key limits, with budget controls in the Enterprise platformRebuild the limits and test their boundary behavior. Similar names do not guarantee identical accounting windows or denial responses.
Guardrails and callbacksPolicies, configured PII and guardrail checks, audit evidence, metrics and integrationsRecreate each control and test both allowed and denied requests. Controls that are off or permissive by default must be enabled explicitly.
Retries, load balancing and fallbackRoutes plus retry, circuit-breaker and failover settingsRebuild the provider pool and test real failures. Model compatibility, tool use, structured output and stream state can prevent a fallback.

Move one workload in six steps

Start with a representative workload, not the easiest request you can find. It should include the models, streaming mode, tools and failure cases that matter in production.

  1. 1

    Write down the current contract

    Record the endpoints, public model names, providers, keys, limits, routes, guardrails and callbacks in use. Save a small set of successful and failed responses for comparison.

  2. 2

    Choose the DVARA operating model

    DVARA Open Source provides a file-configured LLM data plane. The Enterprise platform adds Flightdeck, central persistence, workspaces and managed governance workflows. Deploy the same shape you intend to operate after the test.

  3. 3

    Rebuild configuration; do not translate it blindly

    Add provider credentials, preserve only the public model names your clients need, create new DVARA keys, and rebuild routes and governance controls. In a multi-workspace deployment, setDVARA_LLM_GATEWAY_REQUIRE_API_KEY=true; it isfalse by default.

  4. 4

    Send one complete governed request

    Replace the host, key and model with values from your test deployment. The response is OpenAI-compatible; its content and token counts depend on the selected provider.

    Request
    curl https://<your-dvara-host>/v1/chat/completions \
  -H 'Authorization: Bearer <your-dvara-key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Summarize the refund policy."}
    ],
    "temperature": 0
  }'
    Representative response
    {
  "id": "chatcmpl-01JQ4P8F6A2M9K7W3T5Y",
  "object": "chat.completion",
  "model": "gpt-4o-mini",
  "choices": [{
    "index": 0,
    "message": {
      "role": "assistant",
      "content": "Refunds are available within 30 days."
    },
    "finish_reason": "stop"
  }],
  "usage": {
    "prompt_tokens": 16,
    "completion_tokens": 9,
    "total_tokens": 25
  }
}

    In the Enterprise platform, confirm the request under the expected workspace in Flightdeck. In Open Source, confirm it in the audit sink you configured. Check the selected provider, policy outcome, status and token usage.

  5. 5

    Run the tests that expose incompatibility

    Test non-streaming and streaming calls, tool use, structured output, unknown models, bad keys, rate and budget boundaries, policy denials, provider errors and failover. DVARA can retry and fail over when configured, but it does not continue a stream on another provider after response delivery has begun.

  6. 6

    Cut over in stages

    Put the gateway URL and key behind runtime configuration. Move one workload, watch the agreed error, latency, cost and denial thresholds, then expand. Keep LiteLLM available until the acceptance window and usage reconciliation are complete.

Define rollback before cutover

Keep separate LiteLLM and DVARA URL/key pairs behind a feature flag or deployment setting. Roll back when a response contract, error-rate, latency or governance threshold fails. Do not mirror sensitive production prompts to both systems unless that data handling has been reviewed and approved.

Review DVARA resilience
FAQ

Questions before you migrate

Is this still a migration from LiteLLM Cloud?

Not as a separate managed product. LiteLLM now presents its gateway and Enterprise offering as self-hosted, and the former Cloud URL redirects to the Enterprise page. This guide covers a current LiteLLM Proxy or Enterprise deployment. The old page URL remains as a redirect so existing bookmarks keep working.

Is changing the base URL enough?

It is enough to prove a simple OpenAI-compatible request can reach DVARA. It does not move keys, teams, budgets, routes, callbacks or guardrails. Recreate those controls and validate the request paths your application actually uses before production cutover.

Can DVARA import a LiteLLM configuration file?

No. There is no supported automatic importer. Treat the LiteLLM configuration as an inventory, then author and review the corresponding DVARA workspaces, keys, routes and governance controls.

Which DVARA distribution should I use?

Use DVARA Open Source for a file-configured LLM data plane. Use the Enterprise platform when you need Flightdeck, central persistence, managed workspaces and advanced governance workflows. MCP and A2A are Enterprise planes and require a production licence to activate.

How do I roll back safely?

Keep the LiteLLM deployment available during the acceptance window and keep the base URL and API key in runtime configuration. If the agreed error, latency, response-contract or governance thresholds fail, restore the previous URL and key, then investigate before trying the cutover again.

Prove one real workload first.

Rebuild its controls, test its failure paths, and keep the old endpoint ready until the results are clear.

Start the quickstartBook a migration review

Last updated