Inventory before you install anything
The outgoing platform is currently gating things. Some of them you know about; some were configured by someone who left. If you remove it before knowing what it was holding, those scripts do not stop: they become ungated.
- 1
List what the old platform gates
Export its configuration, its category mapping and its script list. This is the requirements document for the new one.
- 2
Scan the live site independently
The old configuration records intent; a fresh scan records observed behavior. Compare both, because later theme, app, container or vendor changes can make them diverge.
- 3
Export the consent records
They are evidence about decisions you relied on. Export them before the account closes, whatever the new platform does.
- 4
Find every place the old script is loaded
Theme, plugins, tag manager, platform app. A leftover tag in a container is the classic cause of a lingering second banner.
Cut over cleanly
Do not run both
Two consent systems on one page will disagree, and the records they produce will not explain themselves afterwards. Configure the new one fully, then remove the old one in the same change.
Old consent cookies (`OptanonConsent`, `CookieConsent` and similar) can linger after the old script is gone. Their presence alone does not prove that the former CMP still loads. Verify in a fresh profile and look for new `Set-Cookie` activity, network requests, scripts and DOM behaviour before diagnosing an incomplete removal.
After the cutover
- Scan in each consent state and compare against the pre-migration baseline
- Confirm no second banner renders, in a fresh profile
- Check that scripts the old platform gated are gated by the new one, not merely absent from its list
- Expect a wave of fresh consent decisions: visitors have not made one under the new configuration yet
Common questions
Do existing consents carry over?
Do not assume they do. A migration may be technically possible where the new system can preserve the original evidence and the purposes, vendors, wording, scope and version remain equivalent. If those conditions cannot be demonstrated, export the old records as historical evidence and ask visitors again under the new configuration.
How long should a migration take?
The code installation may be quick, but inventory, mapping, testing and a controlled cutover usually take longer. Estimate the work from the number of properties, tags, vendors, regions and user journeys rather than promising a fixed duration.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- StrongPrivacy verification guide
Product documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.