Search embedded analytics versioning and the first page answers a vendor's question. The results explain how to roll out a breaking change safely: semantic version numbers, canary traffic, feature flags, deprecation windows. That is useful if you are shipping the analytics platform.
If you have embedded someone else's analytics, you are on the other side of that transaction. You do not choose the rollout pattern. You inherit it, and the only part you can inspect before you sign is what the vendor has written down.
The Six-Month Rule Is Advice, Not Something We Found in a Vendor Document
One widely-circulated guide, d23.io's rollout piece from April 2026, puts it plainly: "Give customers at least 6 months notice, preferably 12." It is sensible advice and it is easy to find.
We went looking for it in the vendors' own documentation instead of in the advice. Reading two embedded analytics vendors' public version pages, we did not find a stated notice period in either. The two documents turned out not to be the same kind of document at all.
Two Vendors Publish Two Different Kinds of Promise
Metabase's modular embedding SDK version page publishes a coupling rule. On Metabase 56 and earlier, "the SDK major version must match the Metabase major version," and "Metabase Cloud upgrades your instance automatically as new versions roll out." That is a statement about which pieces have to move together.
Looker's API versioning page publishes a lifecycle instead. Endpoints are stable, beta, or deprecated, and a deprecated endpoint is one that is "still supported and can still be used at the moment, but will be deleted in a future release." That is a statement about what state a thing is in.
Both are legitimate, and they answer different questions. One tells you what must line up, the other what is on its way out. Neither says how long you have.
A Lifecycle Label Tells You What Will Happen, Not When
Looker's own wording is direct about the consequence: "When a future release of Looker removes support for that endpoint, any code that is still using it will break." The support policy page is equally direct about the current state, saying "Only API 4.0 is Looker supported," with 3.0 and 3.1 listed as removed.
Read together, those give you a clear picture of direction and no picture of timing. You can tell that a deprecated endpoint is going to disappear. You cannot tell whether that means one release or six.
That gap matters more for embedded analytics than for a backend integration, because the thing that breaks is a surface your own customers are looking at.
What We Could Not Find Is Not the Same as What Does Not Exist
We looked for a published version-support or breaking-change policy for the Power BI client library that embeds Power BI content, and did not find one in the places we searched. That is a report about our search, not a finding about Microsoft.
The distinction is worth keeping because it is the same mistake a version audit makes easy. An absent answer and an answer you failed to locate look identical from the outside, and only one of them is the vendor's fault.
The Questions That Belong in the Contract, Not the Changelog
A changelog records what already happened. A support policy records what the vendor owes you next time, and only the second one is a commitment you can hold anyone to.
Four questions separate them, and each one has a written answer or it does not:
- Which version pairs are supported together? Metabase answers this explicitly for 56 and earlier. Looker's pages do not state it.
- Can the server side move without a release on your part? Metabase Cloud says it upgrades the instance automatically, which is worth knowing before rather than during.
- Where does a mismatch surface for you? A build error, a type error, and a component that renders the wrong number are three very different incidents.
- Is there a stated survival period for a deprecated version? If that is answered anywhere, it sits in a support policy rather than a version scheme.
The mechanics of pinning a package to an instance, and what pinning transfers to you, are worked through in our SDK-first analytics guide rather than repeated here.
Ask for the Policy Before You Ask for the Roadmap
A roadmap tells you what a vendor intends. A version support policy tells you what they have already agreed to when those intentions change, which is the document that matters at renewal.
If you are evaluating embedded analytics software, ask where its version policy lives and read it before the demo. A vendor that publishes a coupling rule and a vendor that publishes a lifecycle are both being transparent, and you still own the job of noticing which one you got.
What This Page Does Not Cover
We read three documents: two Looker pages and one Metabase page, on 30 August 2026. We did not survey the wider vendor market, and we did not test whether any of these policies is honoured in practice.
This does not establish what a typical notice period is across the category. It establishes that in the documents we could read, the number the advice literature repeats was absent.
Where to Go Next
- Headless BI architecture: where the metric contract sits when the front end is yours.
- API-first analytics implementation: what changes when analytics configuration lives in version control.
- Architecture articles: every article in this cluster.
Ready to launch customer-facing analytics?
Stop losing customers to competitors with better analytics. Sumboard's customer-facing analytics platform lets you launch self-service dashboards in days, not months.
