Migration
Retrieval that survives a provider shutting down
Search providers in this category are young, well funded and consolidating, which is a combination that produces both good products and abrupt terms changes. Planning for a provider to go away is not pessimism about any particular vendor — it is an acknowledgement that three of them changed materially in a year and a half, and that the teams who had thought about it in advance spent days rather than months.
Verified 21 September 2026
What actually happened, and to whom
Microsoft retired the Bing Web Search API on 11 August 2025 — the whole family, including Custom Search. The detail that matters for planning is that new API creation had been quietly disabled the previous March, so by the time the notice landed the decision was already irreversible and nobody could start a migration onto a like-for-like Microsoft product.
Brave replaced its long-running free developer tier with a monthly credit against paid usage in February 2026. The index did not change and the API did not change. What changed is that every hobby project, internal tool and evaluation harness built on the free tier suddenly needed a card on file, which for a large organisation is a procurement event rather than a click.
Tavily was acquired by Nebius in the same month. Acquisition is not shutdown, and the service continued — but its search has always run on an upstream provider rather than an index it owns, and an acquirer inherits the freedom to change that relationship. All three events are on our landscape timeline with sources, and none of them was a surprise to anyone who had been tracking where each provider's index actually came from.
What actually breaks in a search migration
The client is a day of work. Authentication header, query string, response mapping — this is the part teams imagine when they picture a migration, and it is the part that never causes the overrun.
What causes the overrun is everything that grew around the old provider's ranking. Prompts that say "the first result is usually the best one" because that was true of the old ranker. A hardcoded limit of five that was tuned against a ranker with different precision. Extraction code that assumes snippets are two sentences. Evaluation thresholds calibrated against one distribution of scores. None of this is written down anywhere, and all of it shifts the day the ranker changes.
Second is the filter vocabulary. Every provider invents its own names and value sets for content type, language, recency and site scoping, and agents that hardcode those names break silently rather than loudly — a filter the new provider does not recognise is frequently ignored rather than rejected, so the agent keeps working and quietly stops filtering. This is the failure mode worth engineering against, because nothing alerts on it.
Write down a capability floor, not a vendor preference
A capability floor is a short list of behaviours your product cannot lose, written before anyone is shopping and phrased without a vendor's name in it. Four or five items, each one testable. "We must be able to bound results by publication date, not only by crawl date." "We must be able to require an exact identifier to appear." "We must be able to tell a user why a source they expected is absent."
The discipline is in keeping it short and honest. Every capability on the floor narrows the field, and a floor with fifteen items on it has stopped being a requirements document and become a description of the incumbent. If a capability is on the list, somebody should be able to name the feature that would break without it.
The floor also does work at purchase time. Comparing search APIs on price is how teams end up rebuilding in six months, because the categories have genuinely different failure modes: a SERP reseller inherits the deprecation risk of the engine behind it, a retrieval layer inherits the pricing of whoever it queries, and an own-index provider carries the cost of its own crawl. The floor is what makes a cross-category comparison mean something.
The abstraction boundary worth building
The useful boundary is not a generic search client. It is a narrow interface expressed in your own domain terms — find_sources(question, freshness, must_contain, min_corroboration) — with one adapter per provider translating into that provider's actual grammar. Your application never learns a vendor's parameter names, and the translation lives in one file you can read in a sitting.
Resist the instinct to make the interface the intersection of every vendor's features. An adapter that only exposes what all providers support is an adapter that has deleted the reasons to choose one, and you will have paid the abstraction cost to end up with the commodity product. Model the capability, let an adapter declare it unsupported, and let the application degrade explicitly rather than silently.
Where a provider publishes its own capability surface, read it at startup rather than hardcoding it. unlob serves /describe unauthenticated with the current filter grammar and every enumerated vocabulary, which means an agent can discover valid content types and topics instead of carrying a copy that goes stale. A provider that offers nothing equivalent should have its vocabulary pinned in the adapter with a comment saying when it was last checked.
# No key needed: the filter grammar and every controlled vocabulary.
curl -sS "https://api.unlob.com/describe" | jq '{
content_types: .vocabularies.content_type,
topics: .vocabularies.topic | length,
sorts: .vocabularies.sort
}'Keep a replay set so a swap can be measured
A replay set is two hundred real queries drawn from production, with the outputs your current stack produced, stored. It costs almost nothing to maintain and it is the only thing that turns a migration from an argument into a measurement.
What you compare is not whether the same URLs came back — they will not, and that is expected. Compare the things your product actually promises: did the answer cite at least two independent sources, did the cited passage contain the claim, did the recency bound hold, did latency stay inside the budget. Those are properties of your output, not of the vendor's ranking, and they are the ones a user would notice.
Run the replay set against a candidate on its free tier before any commercial conversation. On ours, 10,000 credits a month is 50 runs of a two-hundred-search set, which is more than enough to see whether the gap is a tuning problem or a capability problem — and that distinction is the whole decision.
Dual-sourcing: when it pays and when it is theatre
Running two providers in parallel is genuinely worth it in one situation: when a gap in one index is a business incident rather than a degraded answer. Regulated research, monitoring obligations and anything with a contractual completeness commitment qualify. The second provider is insurance against absence, and the cost is running two adapters and reconciling two result shapes forever.
Everywhere else it is usually theatre. Two providers means two ranking behaviours to tune against, two sets of rate limits, two bills, and a merge step that has to decide which of two disagreeing result sets to believe — and that merge is where the quality goes. Most teams that describe themselves as dual-sourced are in fact running one provider with a failover that has never been exercised, which is a fire drill they have not done rather than a redundancy they have.
The cheaper version of the same insurance is a maintained adapter for a second provider, tested in CI against the replay set, switched off in production. You get the ability to move in a week without paying the merge cost every day. If the second adapter has not been run this quarter, it does not work, and you should find that out on a Tuesday rather than during an outage.
What designing for portability costs you
Every abstraction boundary is a tax, and this one is not free. You lose direct access to whatever is distinctive about the provider you actually chose, unless you deliberately let capabilities through the interface — and the moment you do that, the abstraction stops being portable in the way the design promised.
You also lose some speed of iteration. A new filter is a change in two places rather than one, and a capability that only one vendor has needs a decision about how the adapter declares its absence. In a small team shipping fast this is a real drag, and the honest answer is that it is not worth it until the product has a user who would notice the retrieval getting worse.
And portability does nothing about the risk that actually ended Bing's API: a provider deciding the business is not worth being in. No amount of adapter hygiene moves that. What it changes is how long you have to react — days rather than a quarter — which is the difference between a planned migration and an incident.
Frequently asked questions
Is it worth building an abstraction layer before I have a second provider?
A narrow one, yes — the value is in stopping vendor parameter names spreading through the codebase, and that is cheapest on day one. A full plugin architecture before you have ever swapped anything is speculative work that usually abstracts the wrong axis.
How do I tell whether a provider owns its index?
Ask directly, and read the answer for hedging. A provider on its own index will say so plainly; one reselling or layering on an upstream engine tends to describe its retrieval rather than its corpus. Our landscape page records the answer for twenty providers with sources.
Does an own-index provider remove the shutdown risk?
No — it removes one layer of it. An own-index provider cannot have its supply cut off by an upstream engine, which is what happened to products built on Bing. It can still change its prices, its terms or its mind, and a small one carries more business risk than a large one.
What is the first thing to do when a provider announces a retirement?
Check whether new accounts can still be created. Bing's creation path closed five months before the announcement, and that is the signal that determines whether you are migrating on your schedule or theirs.
Try it against your own queries
10,000 free credits a month, no card. Everything in this guide works on the free tier.