Before Replacing BrightEdge, Preserve the Evidence: An AI Visibility Data Handover Checklist

Replacing an enterprise SEO platform is a procurement decision. Preserving AI visibility evidence is a measurement-custody decision. Before any BrightEdge replacement goes live, marketing operations should export the prompt set, raw answer evidence, citation URLs, dates, locales, engine identities, model identities, and score definitions that make old and new visibility numbers comparable.

This is not a vendor scorecard and it is not another competitor list. It is the handover checklist a B2B team should use after the shortlist is built, before leadership starts reading the new dashboard as if it were continuous with the old one.

AuthorityTech's current demand signal for this topic is comparison demand, not proven switching intent. In the August 11-September 8 Google Search Console window captured in the September 11 brief, exact brightedge competitors query-page rows recorded 644 impressions at the current BrightEdge competitors guide, 3,738 impressions at a historical BrightEdge alternatives URL, and 903 impressions at a BrightEdge AI-search-visibility URL. Those are query-page impressions. They are not unique searches, market volume, buyer intent, or proof that a team is replacing anything.

The practical inference is narrower: enough people are comparing BrightEdge that the post-selection data handover problem deserves its own artifact.

AI visibility data handover is a custody problem, not just a software migration

AI visibility data handover means preserving the evidence needed to compare answer-engine visibility before and after a platform change. The handover is not complete when dashboards match at the headline level. It is complete when a reviewer can trace the same question shape, engine, model, locale, answer text, citation URL, timestamp, and scoring rule across the transition.

That distinction matters because AI visibility numbers are highly dependent on the instrument. A platform can report a citation rate, share of voice, visibility score, or answer presence score, but each number is only interpretable if the denominator and collection rules survive the move. The current Machine Relations Index release manifest identifies the September 11 release as mri_score_v2.0+2026-09-11+6fe35eb24eb1, and the related public data covers 15,040 observed answer runs across the May 10-September 11 window. That scale is useful only because the release keeps the question, engine, run, and denominator logic visible enough to inspect.

The same rule applies to a brand's private measurement stack. If the old platform measured one run per prompt and the new platform measures five, the new number may be better measurement without being better performance. Treat the export as a dataset with distribution and metadata fields, in the plain sense reflected by Schema.org Dataset, not as a screenshot of a dashboard. If one platform includes no-citation answers in the denominator and another excludes them, the rate can move even when the underlying answers did not. If one tool stores raw answers and another keeps only aggregate scores, the team loses the ability to audit why the number changed.

Do not ask, "Can we export the AI visibility report?" Ask, "Can we preserve the evidence required to reproduce or reconcile this measurement later?"

The vendor-neutral export request before replacing BrightEdge

A useful export request asks for evidence fields, not for a vendor-specific feature name. Do not assume BrightEdge, the replacement platform, or any other provider supports a particular export format. Ask for the fields your team needs, accept the ones the provider can lawfully and technically supply, and record every missing field before the old contract or workspace access disappears.

Send this request to the incumbent platform owner, the replacement platform owner, and the internal team that owns data retention:

We are preserving AI visibility measurement custody during a platform transition. Please provide the most complete export available for our tracked AI visibility, answer-engine, and search-visibility measurement program. We are not requesting proprietary platform logic. We are requesting the evidence fields needed to reconcile historical and future reporting.

Minimum requested fields:

Field group	Fields to request	Why it matters
Prompt identity	Prompt text, prompt ID, prompt group, business category, tracked entity, tracked competitors	Without the question shape, a score cannot be compared across platforms.
Run metadata	Run date, run timestamp, collection window, retry count, error/refusal state	AI answers vary by time; failed runs must not disappear after the fact, and timestamp fields should be explicit enough to map to standards such as RFC 3339.
Engine and model identity	Engine name, surface name, model name or model family when available, provider configuration, retrieval mode if reported	Engine mix changes the denominator and source set; official model rosters such as OpenAI models, Anthropic models, Google Gemini models, and Perplexity Sonar models show why model identity belongs in the record.
Locale and personalization controls	Country, language, city/region where used, device or session controls where reported	Localized and personalized answers are not interchangeable with global answers.
Raw answer evidence	Full answer text, cited passages if stored, citation URLs, cited domains, citation positions, answer source list	Aggregate scores cannot explain why visibility changed, especially on surfaces where Google says AI features and Search may show different links and responses.
Scoring definitions	Metric name, numerator, denominator, inclusion/exclusion rules, deduplication rule, weighting, confidence or sample-size notes	A score without its formula is not portable.
Taxonomy	Tags, prompt clusters, funnel stage, topic labels, stakeholder labels, campaign labels	Migration often breaks the reporting structure even when raw runs survive.
Provenance	Export date, exporting user or system, file hash if available, source workspace/account, retention policy	The export itself needs an audit trail; use provenance language in the ordinary sense, consistent with frameworks such as the W3C PROV overview and metadata vocabularies such as Dublin Core terms.

This request is deliberately vendor-neutral. It does not say any platform must expose raw model outputs, every model ID, or every retrieval setting. It asks the team to find the highest-evidence export available and document the gaps.

For teams that also track organic-search evidence, keep the SEO export separate from the AI-visibility export. Google's own Search Console API documentation defines search-analytics rows around dimensions and metrics such as clicks and impressions, which is why the September 11 demand brief's Google Search Console comparison rows must stay in their lane: query-page impressions, not unique searches or switching intent. They can justify a content question. They cannot be merged into answer-engine visibility as if they were the same instrument.

Field-by-field AI visibility acceptance worksheet

The acceptance worksheet should classify every handover field as accepted, transformed, missing, or non-comparable. Do this before the replacement dashboard becomes the executive source of truth. Once leadership has seen the new trend line, changing the baseline becomes politically harder than documenting the limitation up front.

Use this worksheet during the first data-review meeting:

Evidence field	Acceptance question	Status	Owner note
Prompt text	Can we see the exact natural-language question asked?	Accepted / transformed / missing / non-comparable
Prompt ID	Can the old and new systems map the same question to a stable ID?	Accepted / transformed / missing / non-comparable
Prompt grouping	Can business categories, topics, or funnel labels be rebuilt without changing the denominator?	Accepted / transformed / missing / non-comparable
Tracked entity	Is the brand/entity definition explicit and stable?	Accepted / transformed / missing / non-comparable
Competitor set	Is the competitor list stored per prompt set and date, not just globally?	Accepted / transformed / missing / non-comparable
Run timestamp	Is every answer tied to a date and time or at least a declared collection window?	Accepted / transformed / missing / non-comparable
Engine identity	Is the answer tied to ChatGPT, Claude, Gemini, Perplexity, Google AI Mode, Google AI Overviews, or another surface?	Accepted / transformed / missing / non-comparable
Model identity	Is the model name, model family, or unavailable status recorded?	Accepted / transformed / missing / non-comparable
Locale	Is country/language/region captured where it affects the answer?	Accepted / transformed / missing / non-comparable
Raw answer text	Can a reviewer read what the engine actually returned?	Accepted / transformed / missing / non-comparable
Citation URL	Are exact cited URLs preserved, not only citing domains?	Accepted / transformed / missing / non-comparable
Cited domain	Are domains normalized consistently across old and new systems?	Accepted / transformed / missing / non-comparable
Citation position	Is source order or answer placement retained when available?	Accepted / transformed / missing / non-comparable
Error/refusal/no-answer state	Are failed or uncited runs kept in the denominator instead of silently dropped?	Accepted / transformed / missing / non-comparable
Metric numerator	Does the score say what counted as a success?	Accepted / transformed / missing / non-comparable
Metric denominator	Does the score say what all eligible observations were?	Accepted / transformed / missing / non-comparable
Deduplication rule	If the same URL appears twice in one answer, is it counted once or twice?	Accepted / transformed / missing / non-comparable
Weighting rule	Are engines, prompts, and topics equally weighted or weighted by business value?	Accepted / transformed / missing / non-comparable
Export provenance	Can the team prove when, where, and by whom the export was produced?	Accepted / transformed / missing / non-comparable

The most important statuses are usually not the obvious accepted fields. They are the transformed and non-comparable fields. A transformed field can still be usable if the transformation is documented. A non-comparable field must be excluded from trend claims.

For example, if one platform reports domain-level citations and another reports URL-level citations, do not pretend they are interchangeable. Domain-level continuity may be possible. URL-level continuity may be lost. That does not make the new platform worse. It means the migration changed the measurement unit.

Parallel-run reconciliation example (hypothetical)

A short parallel run is the safest way to separate real visibility movement from measurement-method movement. The example below is hypothetical. It is not a statement about BrightEdge, any named replacement platform, or any vendor's export capability.

Assume a B2B software company tracks 40 AI-visibility prompts across two engines for one week before switching platforms. During the same week, the old system and the new system both collect answers for the same prompt list.

Reconciliation item	Old platform	New platform	Interpretation
Prompts configured	40	40	Prompt count matches. Good start.
Eligible answer runs	80	240	Not comparable as a headline trend; the new system ran three times as many observations.
Runs citing the brand	20	54	Raw count rose, but raw counts follow run volume.
Run-based citation rate	25.0%	22.5%	A small apparent decline may be sampling/method difference, not performance loss.
Cited domains stored	Yes	Yes	Domain-level reconciliation is possible.
Exact citation URLs stored	No	Yes	URL-level analysis starts with the new system; old trend cannot be reconstructed.
No-citation answers retained	Unknown	Yes	Old denominator may be incomplete; trend claim should be qualified.
Locale recorded	Global only	US and UK split	Local reporting improves, but global-to-local trend is not continuous.

The right executive summary is not "visibility fell from 25.0% to 22.5%." A rate is a proportion, and proportion estimates need sample context; the NIST handbook section on confidence intervals is the underlying statistical reason. The right summary is:

Hypothetical reconciliation result: the replacement platform collected three times as many eligible runs, retained exact URLs, and split locale more granularly. Domain-level direction is usable with caution. URL-level and locale-level trend lines start at migration. No-citation handling in the old system is unresolved, so the team should not claim a pre/post performance decline from this week alone.

That is the point of the parallel run. It does not make the data perfect. It prevents the first post-migration report from confusing a measurement upgrade with a market signal.

What to preserve from Machine Relations Index-style measurement

The Machine Relations Index shows why question shape and denominator belong in every AI visibility handover. In the September 11 public release, the AI Visibility & GEO/how_choose stratum recorded YouTube citations in 29 of 113 observed answer runs, or 25.66%, across seven observed dates. That sentence is useful because it names the question shape, observed answer-run denominator, cited-domain numerator, and date coverage.

It does not prove YouTube is the best platform for a buyer. It does not say a migration improves citations. It does not recommend BrightEdge, a replacement platform, or any other software. It is a measurement example: the rate is readable because the denominator is readable.

The same release also keeps its limitations visible. The full window spans May 10-September 11, 118 observed dates, and all six MRI engines were healthy globally at release time. But per-stratum balanced engine coverage is not established. A responsible handover copies that posture: preserve what was observed, say where coverage is incomplete, and do not turn a bounded metric into a platform recommendation.

The September 11 AuthorityTech synthetic panel creates another useful boundary. Because model and deployment names can differ across providers, including Microsoft's own Azure OpenAI model documentation, the handover should preserve the provider-specific label rather than normalizing everything to a generic family name. The panel boundary still matters: AuthorityTech was absent across six monitored configurations for the ai visibility prompt. That is a bounded competitive gap for that prompt and panel. It is not organic demand, general invisibility, or evidence that a software change would fix the absence. Treat synthetic-panel absence as a diagnostic gap, not a conversion claim.

Machine requests need the same restraint. Cloudflare documents bot traffic as its own class of web request in its Bot concepts material; that category difference is why request counts should not be turned into human demand. The September 11 Cloudflare snapshot counted 484 classified requests to AuthorityTech /blog/ paths, and the August 13-September 11 rollup counted 11,002 blog requests across 24 observed days, including 8,174 AI_ASSISTANT requests. Those are machine requests. They are not people, leads, conversions, or authenticated citation events.

Where software procurement ends and earned-evidence execution begins

Replacing an SEO or AI-visibility platform can improve measurement operations, but it does not by itself earn third-party evidence. Software can help a team collect prompts, compare engines, preserve answers, and report metrics. AuthorityTech's role is different: earning and structuring the outside evidence that answer engines can retrieve, trust, and cite.

That distinction should appear in the migration memo. A procurement team can choose a better platform and still have the same evidence problem if the brand lacks credible third-party corroboration. A communications team can earn better corroboration and still need disciplined software to measure it. The two jobs touch, but they are not substitutes.

Machine Relations is the discipline that connects earned authority to machine-mediated discovery. For a platform migration, its practical lesson is simple: preserve the measurement evidence first, then improve the evidence base the engines can cite. If you reverse the order, the new dashboard may look cleaner while the underlying citation problem remains unchanged.

AuthorityTech does not replace enterprise SEO software. It helps teams diagnose and execute the earned-evidence layer that software can measure but does not automatically create. That is why the handover checklist should live with marketing operations, not only procurement.

FAQ

What should a B2B team export before replacing BrightEdge?

Before replacing BrightEdge or any enterprise SEO platform, export the prompt text, prompt IDs, tracked entities, competitor sets, run dates, engine and model identities, locales, raw answer text, citation URLs, score definitions, denominator rules, and export provenance. Do not assume any vendor supports every field; document what is available and what is missing.

Does an AI visibility platform migration prove visibility improved or declined?

No. A migration changes the measurement instrument. A pre/post chart is only meaningful when the prompt set, run count, engine mix, locale, numerator, denominator, and exclusion rules are comparable. If those fields changed, label the chart as a new baseline or a qualified reconciliation, not a clean performance trend.

Are Google Search Console impressions the same as AI visibility demand?

No. Google Search Console query-page impressions are search-result observations for a page and query. The September 11 demand brief's BrightEdge rows are useful as comparison exposure, but they are not unique searches, market volume, AI answer citations, or evidence that a buyer intends to switch platforms.

Can AuthorityTech replace BrightEdge or another SEO platform?

No. AuthorityTech is not a replacement for enterprise SEO software. The software job is measurement, workflow, and reporting. AuthorityTech's job is earned-evidence execution: building the credible third-party authority that answer engines can retrieve and cite, then helping teams understand where that evidence is or is not showing up.

How should a team report the first month after an AI visibility tool migration?

Report the first month as a reconciliation window. Show which fields are accepted, transformed, missing, and non-comparable. Publish trend lines only where the denominator and collection rules match. For everything else, declare a new baseline and keep the raw handover evidence attached to the migration record.