Switching Consent Platforms Without Losing Your Consent Records
Changing consent platforms looks like a tooling project and behaves like a records project. The new banner is the easy part. The risk sits in the history: hundreds of thousands of stored choices that must arrive in the new system meaning the same thing, and a cutover where a misconfiguration can silently reset or ignore them.
This guide lays out a migration sequence that protects the records: inventory and export, category mapping, cutover discipline, and the verification pass most teams skip because the new banner looks right on the homepage.
Export before you evaluate
Start the migration while the old contract is healthy, not in its final week. Export every consent receipt with timestamps, notice and banner versions, categories, and the source of each choice, and store that export in your own systems in an open format. That export is your insurance if the migration stalls, the vendor relationship sours, or the new tool interprets history differently than expected. Run a test query against the export, pulling one person full history, before you rely on it for anything.
Map categories in writing
Two platforms rarely model purposes identically. One tool marketing category may cover what another splits into advertising and personalisation. Write the mapping down, old category to new category, with a decision for every mismatch, and have privacy review sign it. Where an old category bundles more than the new one can represent, the honest answer is often to re-ask affected visitors rather than guess. Silent remapping turns a considered choice into your interpretation of it, which is exactly what an audit will pull apart.
Cutover without double banners or resets
The classic cutover failures are both tools firing at once and the new tool starting from a blank state. Deploy the new banner behind the same tag conditions as the old, remove the old loader in the same release, and seed the new tool with migrated states so returning visitors keep their choices. Test the four paths before launch: new visitor, returning accepter, returning refuser, and partial choice, on desktop and mobile. A migration that respects refusers is the one that survives scrutiny, so test the no path twice.
Verify for a full cycle afterward
Do not declare success on launch day. For the first weeks, compare consent rates and category splits against the old tool baseline; a sudden jump in acceptance usually means refusers were reset, not that the new banner is charming. Spot check receipts in the new system against the export for a sample of long standing visitors. Keep the old export and the mapping document with your other consent records, because future questions will be about the transition period as much as about either tool.
Related reading
These earlier guides cover connected questions in more depth: Cookie Walls and Paywall Choices: When Access Depends on Consent, Preference Centers: Making It Easy to Change a Consent Choice, and Consent and A/B Testing: Running Experiments Without Breaking the Rules.
Frequently asked questions
Can we just start fresh with a new platform?
Starting fresh means asking everyone again and having no usable record of earlier choices during the gap. For a small site that may be acceptable if planned openly; for an established audience it destroys proof you may still need.
What if the old vendor cannot export receipts?
That is a contract and leverage problem to solve before signing the new tool, not after. Escalate early, use whatever reporting or API access exists, and document what could not be recovered and why.
Should we tell visitors we changed platforms?
The banner vendor is rarely material to visitors, but changes to wording, categories, or how choices are stored can be. If choices carry over unchanged, no announcement is needed; if anything about the choice itself changes, ask again.
How long should we keep the old export?
Keep it on the same retention schedule as the receipts themselves. The export is a copy of your consent records, so it inherits their retention and access controls.