Open-source AI infrastructure
A practical migration guide from LiteLLM to another self-hosted gateway. What moves with a base URL change, what has to be rewritten, what does not carry over at al…
You need a provider it supports and your alternative does not. LiteLLM's coverage is the widest in the category and this can settle the question on its own. Check your model list before anything else. The MIT core covers you. If you do not need virtual keys, budgets, SSO or per-team spend tracking, the enterprise directory never affects you and LiteLLM is free forever. Routing is genuinely the whole problem. Adding…
The endpoint. LiteLLM's proxy is OpenAI-compatible, and so are most alternatives. Applications calling through the OpenAI SDK move with a base URL and key change:
Direct litellm SDK usage. This is the big one, and how much of it you have determines the size of the job.
Historical spend and usage records in the LiteLLM database. There is no importer. Keep the old database readable for as long as you need the history, and plan for a reporting seam at the cutover date. Existing virtual key objects and their budget state. Keys get reissued, and consumed-budget counters restart. Custom router strategies expressed in LiteLLM configuration. LiteLLM-specific request headers and any client…
1. Grep for import litellm first. This single command sizes the whole migration. If it returns nothing, you are doing a configuration port. If it returns hundreds of hits, you are doing a code change and should plan accordingly.
The endpoint change is trivial. The migration cost is proportional to how much you used LiteLLM as a Python library rather than as a service, and to how many custom callbacks you wrote.