CMP Migration: The Consent Reset That Costs You Half Your Opt-Ins

A company switches consent management platforms, and the new CMP asks every visitor for consent again. The opt-in rate halves overnight, the analytics gap opens, and the team discovers that consent does not migrate. The old CMP held the records, the new CMP holds nothing, and the visitors who consented last month are strangers again.

Switching CMPs resets consent, and nobody budgets for it

Consent records belong to the CMP that collected them. The records are stored against the CMP's own identifiers, in the CMP's own format, and the new CMP cannot read them. The migration moves the banner, the purposes, and the vendor list, but it does not move the consent, because the consent is a record of a choice made to a specific interface, and the interface has changed. The visitor has to choose again.

The reset costs half the opt-ins, sometimes more. The visitors who accepted the first time do not all accept the second time, because the second ask comes without the context of the first, and because some of them accepted the first time without reading it and refuse the second time on principle. The opt-in rate after a migration is the rate of the visitors who accept twice, and it is always lower than the rate of the visitors who accepted once.

The consent receipts post is the record side of the same problem: the receipts have to show what the visitor chose, when, and to which version of the banner. After a migration, the receipts from the old CMP are the only proof of the old choices, and the new CMP has to keep them, or the proof is gone.

What actually gets lost in the move

Three things get lost. First, the consent state itself: every visitor is unknown again, and the analytics and advertising gaps open until they choose. Second, the granularity: the visitors who chose purpose by purpose, accepting analytics and refusing marketing, lose the detail, and the new banner asks them to choose again from scratch. Third, the history: the record of when consent was given, which version of the banner, and which purposes, which is the proof the regulator asks for.

The history matters most, because it is the proof. Article 7 of the GDPR puts the burden of proof on the controller: the company has to demonstrate that consent was given, not the visitor. After a migration, the old CMP holds the proof, and if the contract with the old CMP ends, the proof can go with it. Export the records before the contract ends, and keep them in a format the new CMP can read, or in a store of your own.

The consent mode pre-consent post is the same gap from the tag side: the tags that fire before consent are the ones that lose their data when consent resets, and the gap in the analytics is the gap in the consent.

The migration order that keeps the most

Migrate in this order. First, export every consent record from the old CMP, with the timestamp, the purposes, the banner version, and the visitor identifier, and store the export somewhere you control. Second, configure the new CMP to match the old purposes exactly, so the visitor who accepted analytics before is asked about analytics, not about a renamed purpose. Third, run both CMPs in parallel for a week, with the new one in shadow mode, and check that the purposes and the vendor lists match.

Then switch, and accept the reset. The opt-in rate will fall, and the fall is the cost of the migration, not a failure of the new CMP. Budget for it: the analytics gap lasts until the returning visitors choose again, which takes weeks, not days. The withdrawal banner post is the same lesson from the visitor side: the banner reappears when the choice is withdrawn, and the reappearance is the system working, not the system failing.

Frequently asked questions

Does switching CMPs reset visitor consent?

Yes. Consent records belong to the CMP that collected them, stored against its own identifiers and format. The new CMP cannot read them, so every visitor has to choose again, and the opt-in rate falls, often by half.

What consent records should I export before migrating CMPs?

Every record, with the timestamp, the purposes chosen, the banner version, and the visitor identifier. Store the export somewhere you control. The old CMP holds the proof, and if the contract ends, the proof can go with it.

How long does the analytics gap last after a CMP migration?

Weeks, not days. The gap lasts until returning visitors choose again, and the visitors who accepted once do not all accept twice. Budget for the gap as the cost of the migration, not as a failure of the new CMP.

Can I run two CMPs in parallel during migration?

Yes, for a short period, with the new one in shadow mode. Check that the purposes and vendor lists match before switching. The parallel run catches the mismatches while the old CMP still holds the records.