Migration guides
Parameter mappings, step-by-step ports, and an honest list of what does not carry over. Every guide has a section naming what you will lose, because a migration guide that claims a clean swap is not one.
Migrating off the Bing Web Search API
The Bing Search API was retired in August 2025, taking Web, Image, News, Video, Entity, Autosuggest, Spell Check and Custom Search with it. Microsoft’s designated successor requires adopting Azure AI Foundry.
Microsoft retired the Bing Web Search API on 11 August 2025.
9 parameters mapped · 5 steps · 3 known gaps
Read the guide →The Brave Search API free tier ended — what now
Brave replaced its long-running free developer tier with a monthly credit in February 2026, so anything built on it now needs a card on file to keep running.
Brave retired its perpetual free developer tier in February 2026.
8 parameters mapped · 4 steps · 3 known gaps
Read the guide →Migrating from Tavily after the Nebius acquisition
Tavily was acquired by Nebius in February 2026. The service continues, but acquisitions prompt re-evaluation — and Tavily never owned a web index.
Nebius Group acquired Tavily for $275 million in February 2026.
9 parameters mapped · 4 steps · 3 known gaps
Read the guide →Moving off Google Search grounding to cut cost
Google Search grounding is excellent retrieval priced accordingly, and one prompt can trigger several billed queries. What the move costs, and what it saves.
Grounding with Google Search costs $14 per 1,000 queries on Gemini 3.x, and $35 on Gemini 2.5.
5 parameters mapped · 4 steps · 3 known gaps
Read the guide →What a search migration actually costs
Rewriting the HTTP client is a day. It is never the part that runs over. The cost lands in everything that quietly grew around the previous provider's ranking: prompts written because the old ranker put the best result first, a result limit tuned against its precision, extraction code that assumes a particular snippet length, evaluation thresholds calibrated against one distribution of scores. None of that is written down, and all of it shifts the day the ranker changes.
The second cost is the filter vocabulary. Every provider invents its own names and value sets for content type, language, recency and site scoping. An agent carrying hardcoded names breaks silently rather than loudly, because a filter the new provider does not recognise is usually ignored rather than rejected — the agent keeps answering and quietly stops filtering. That is the failure mode worth engineering against, since nothing alerts on it. Each guide below maps the parameters one by one for exactly this reason.
Before you commit to the next one
Keep a replay set: two hundred real queries from production with the outputs your current stack produced. Compare candidates on what your product actually promises — did the answer cite two independent sources, did the passage contain the claim, did the recency bound hold, did latency stay inside budget — rather than on whether the same URLs came back. They will not, and that is expected.
Run it on a free tier before any commercial conversation, and measure coverage against your own seed list rather than against a vendor's claim about the size of its index. Two longer pieces go through both in detail:designing retrieval that survives a provider being retired, andmeasuring an index before you depend on it. The second is the one to run first, because a coverage gap is the only finding that cannot be tuned away afterwards.
Nothing here argues that a migration is cheap. It argues that the expensive parts are predictable, and that knowing which they are is what turns a quarter into a fortnight.
Port it on the free tier
10,000 credits a month, no card. Run both APIs against your own queries before you change anything in production.