Migrate model traffic to DVARA

Move one representative workload first. A client that already uses supported OpenAI-compatible operations usually needs a base URL and key change. From 1.8.5 so does an Anthropic Messages client, such as Claude Code or the Anthropic SDK, which DVARA serves at /v1/messages. A native Bedrock or Gemini client also needs its request shape moved to an OpenAI-compatible client.

DVARA is an AI governance platform, so the real migration is larger than the network cutover: configure the controls you need, send allowed and refused requests, and verify the resulting evidence before moving production traffic.

Inventory the traffic you are moving

Record what the application uses today:

Check	Why it matters
Endpoint and request fields	DVARA implements specific OpenAI-compatible operations, not every provider feature
Streaming and disconnect behavior	Streaming has its own enforcement posture and retry boundary
Structured output and function calling	Support depends on the DVARA endpoint and selected provider
Model identifiers	DVARA preserves the requested model name during routing and fallback
Retries and timeouts	Client retries can multiply DVARA and provider attempts
Provider credentials	DVARA, not the application, presents the upstream credential after cutover
Existing policies, budgets, and logs	Their meaning and defaults must be mapped, not copied by name

Use the LLM API overview as the current 1.8 compatibility boundary. Test every request shape your application sends; one successful text completion does not prove tools, images, streaming, files, or batches.

Choose the distribution and deployment

DVARA Open Source provides a self-managed LLM Gateway with file configuration. The Enterprise platform adds Flightdeck, central persistence, fleet operations, and advanced LLM governance. The MCP and A2A Gateways are Enterprise planes.

Follow Choose a deployment, then complete the matching quickstart. Use the same topology you intend to operate after the pilot so network, secret, and storage behavior are representative.

Register the upstream provider

Configure the provider and credentials DVARA will use. Send a test request with the exact model identifier your application needs. GET /v1/models is a best-effort view of models returned by reachable registered providers; it is not a guarantee that every optional request field works on that model.

Provider credentials now belong at the DVARA boundary. Remove them from the application only after the DVARA path is proven and rollback no longer depends on the direct path.

Issue the application key

Every /v1 call requires a DVARA workspace API key. For a key with a nonempty scope list, grant only the endpoint families the application uses:

Workload	Required scope
Chat Completions, Responses, or legacy completions	completions:write
Embeddings	embeddings:write
Model discovery	models:read
Files and batches	batches:write

A key with no scopes is unrestricted. See Authentication before replacing an existing 1.7 key, because 1.8 enforces nonempty scope lists.

Change an OpenAI-compatible client

Keep the request shape and change the connection values. For example, Python:

import os
from openai import OpenAI

client = OpenAI(
    base_url=os.environ["DVARA_BASE_URL"],  # for example, https://dvara.internal.example.com/v1
    api_key=os.environ["DVARA_API_KEY"],
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Reply with: governed"}],
    max_tokens=10,
)
print(response.choices[0].message.content)

Expected body content:

governed

The wording is model-dependent. Capture the response's X-Trace-ID header in your real client so support and governance reviewers can connect a failed or successful application action to DVARA evidence. The language-specific guides show the raw-response pattern for Python, JavaScript and TypeScript, and Java.

Change a provider-native client

Do not point a Bedrock Converse or Google GenAI client at DVARA's Chat Completions URL. Those native request shapes are not DVARA endpoints. An Anthropic Messages client needs no change of shape from 1.8.5: point its base URL at the Gateway and see Govern Claude Code.

Move the application call to an OpenAI-compatible client, map the prompt and messages, then use the exact model identifier served by the registered DVARA provider. Re-test tool definitions, image input, structured output, token limits, streaming, and error handling because provider SDK abstractions do not map field-for-field.

Recreate controls from another gateway

Do not import names and assume equivalent behavior. Map the outcome, default, and failure mode:

Existing concern	DVARA destination	1.8 boundary to verify
Virtual key or tenant key	Workspace API key	Scopes are enforced only when the list is nonempty
Provider routing or traffic split	Routing and load balancing	Match order and strategy are explicit; the model identifier is preserved
Retry or fallback	Resilience	Fallback uses compatible registered providers, not a route-scoped model mapping
Content or data rule	Policy as Code, PII, and guardrails	Defaults differ; for example, PII detection defaults to LOG, not redaction or blocking
Spend control	Cost management	Persistent budgets and Flightdeck reports are Enterprise capabilities and depend on usage and pricing data
Request log	Audit and compliance	GATEWAY_RESPONSE is written when audit storage is configured; HMAC signing and hash chaining expose later changes

If your current gateway changes model names during fallback, keep that mapping in the application or experiment system during the 1.8 migration. DVARA's automatic fallback preserves the requested model identifier.

Verify an allowed and a refused request

For the allowed request, confirm:

1. The application receives the expected response and X-Trace-ID.
2. The selected provider and model are the ones you intended.
3. When audit storage is configured, GATEWAY_RESPONSE exists for the trace.
4. Usage and cost appear only when the response supplies usable usage and a matching price is configured.

Then send a safe request designed to trigger one configured control. Confirm the HTTP status and exact DVARA error.code, confirm the provider was not called when the control is pre-dispatch, and find the refusal evidence by trace ID. Never test a production denial with real sensitive data.

Cut over with a rollback path

Run DVARA beside the current path and move one environment or workload cohort at a time. Keep the previous base URL and credential available through your normal secret rollback process until the new path has passed its latency, error, governance, usage, and cost checks.

Rollback means restoring the old connection values. It does not undo provider calls already made or merge two systems' audit and cost records. Record the cutover time and cohort so reviewers know which system owns each interval.

Continue the migration

• Check provider capability gaps.
• Review DVARA headers for trace and request context.
• Use Error handling to update application branches.
• Review the 1.8 upgrade guide when moving an existing DVARA deployment.