Skip to main content
Use this guide when your application calls a LiteLLM proxy through an OpenAI-compatible client. Swap the proxy boundary first, then map aliases, routing rules, and shared defaults deliberately.

What changes

1

Inventory the proxy configuration

List every model alias, fallback, provider rule, retry policy, budget, callback, and environment variable used by the current LiteLLM deployment. Identify which settings are shared policy and which belong to a single application.
2

Replace the proxy endpoint

Keep the OpenAI-compatible request code and change its base URL and key.
3

Map aliases and routing rules

Verify every production model against GET /v1/models. If callers rely on internal aliases, normalize them in one application boundary instead of editing every request.Move reusable prompt, parameter, and provider restrictions into Presets. Configure provider ranking and fallbacks through Routing and Fallbacks.
4

Validate the production workflows

Test streaming, tools, structured outputs, retries, error mapping, and any callback-driven observability your LiteLLM deployment handled. Compare latency, output, token usage, and cost before moving traffic gradually.

Migration checklist

  • LiteLLM URLs, keys, and deployment dependencies have been identified.
  • Every production model and alias has an explicit Phaseo mapping.
  • Shared defaults have moved to presets or one application boundary.
  • Streaming, tools, and structured outputs pass in staging where used.
  • Required callbacks and telemetry have an intentional replacement.
  • Rollback remains a configuration-only endpoint and key change.

Next steps

Last modified on July 26, 2026