How to Retest After Switching CMP Vendors

Not legal advice

This guide explains how to retest a storefront after switching CMP vendors, or after a major banner rebuild. It is not legal advice, not a CMP install or migration tutorial, and not a GDPR, ePrivacy, CPRA, or other compliance certificate. ConsentProbe reports are technical observations of what fired. They do not say what counsel would allow.

Last updated September 26, 2026. The CMP claims guide owns the wider claims-versus-runtime method. The retest-after-fix guide owns a GPC or Reject All fix. The Reject leftovers guide owns a first diagnosis of Reject. The evidence pack and the audit-versus-banner pages own files and the banner-versus-audit distinction. This page stays on the post-switch retest.

Short answer

Switching CMP vendors changes the banner UI and the consent signals the new vendor records. Marketing and analytics can still fire before Accept, and after Reject, from tags, apps, and server hooks the new banner does not control.

Retest the same storefront URL under the same labels you used before the migration. Fresh means no choice. Reject All means the click plus one more navigation. Add Accept, or GPC-on, when those claims are in the ticket. Capture cookies, storage, Network, and a banner screenshot for each label. Diff the hosts that failed before the switch.

Treat the new vendor's copy, including marketing off until Accept, as a claim. Falsify it with the labeled visits. ConsentProbe can produce Fresh and Reject packs with request, cookie, and screenshot links so the before and after packs stay comparable. A free US-baseline re-scan does not prove EU Reject or California GPC behavior. The free versus paid guide draws that line. ConsentProbe does not install a CMP. This page is not a CMP install guide and not legal advice.

Why the swap still needs a retest

Old theme apps, tag-manager tags, and server hooks can still fire outside the new CMP. A vendor swap replaces the banner code. It does not rewrite every script that already loaded on Fresh.

Category names and default states often differ from the previous vendor. A category that was off by default can start on, or the reverse, after the swap. Read the new defaults on a Fresh visit, not from the sales page.

A dashboard status that says the banner is live is not a Fresh or Reject evidence pack. The evidence pack guide lists the files. The CMP claims guide is the wider method for a claim that disagrees with runtime.

Claims and runtime after the switch

Write the finding as a request before Accept after the migration, or a host that still fired after Reject. Leave the legal label with counsel.

Fresh and Reject after the switch

These steps compare the pre-migration failing hosts with a post-switch visit under the same labels. They do not install the new CMP, map categories, or pick a vendor. The CMP claims guide holds the claims-versus-evidence framing. The retest-after-fix guide holds the general loop. The Reject leftovers guide and the marketing-pixels FAQ hold a Reject failure. The audit-versus-banner page holds the case where a banner swap is treated as an audit.

Example of a diff, not a customer capture: before the switch, Fresh showed a marketing host. After the switch, Fresh shows the same host. The banner text changed. The request did not.

1. Keep the pre-migration evidence pack, or the ticket, with the hosts that failed.
2. Use a clean profile. Load the post-switch storefront once. Do not click Accept. Label the pack Fresh.
3. Capture cookies, storage, Network, and a banner screenshot.
4. Open a new clean profile. Click Reject All. Navigate once more. Label the pack Reject.
5. When the ticket includes them, run an Accept control and a GPC-on visit under those labels.
6. Diff before and after for each host that failed. Write one finding sentence per mismatch that remains.
7. Re-open the engineering ticket for hosts that still fail. A completed CMP migration is not a closed finding.

When pre and post packs get slow

Diffing pre-switch and post-switch packs across templates by hand takes a long time. ConsentProbe runs Fresh and Reject on the post-switch URL under the same labels as the original findings. Each finding stays tied to a request, a cookie, or a screenshot.

Use the free US-baseline visit when you want the report format. Use paid EU or California scenarios when those regions are the claims. The free versus paid guide draws that line. ConsentProbe does not install a CMP and does not issue a certificate.

FAQ

Limits of this page

This page tells you how to keep a pre-migration baseline, rerun Fresh and Reject after a CMP switch, and diff the hosts that still fail. It is not legal advice, not a CMP install guide, and not a certificate. ConsentProbe reports stay tied to requests, cookies, and screenshots. A free US-baseline scan is not an EU or California legal conclusion.

Related guides

Open the CMP claims guide for claims versus evidence, the retest-after-fix guide for the general loop, the Reject leftovers guide when Reject still tracks, the evidence pack for the files, and the audit-versus-banner page when a banner swap is treated as an audit.

• CMP claims vs runtime evidence: how do you prove the banner actually works?
• How do you re-test after a GPC or Reject All fix?
• Reject All Still Tracking: What to Check After You Say No
• What belongs in a cookie consent audit evidence pack?
• What is the difference between a cookie consent audit and a cookie banner?
• Pre-Consent Cookie Audit: A Storefront Checklist
• Pre-consent audit checklist: what to verify before Accept
• How do you turn a cookie audit finding into an eng ticket?
• Does Reject All stop marketing pixels?
• Which cookie consent test should you run first?
• What does a free US-baseline cookie audit prove vs paid EU or California scans?
• ConsentProbe methodology
• Pricing and listed regional products