The CMP Migration Checklist: Moving Platforms Without Losing Records
Switching CMPs is the project nobody budgets for. The banner is the easy part: a new script, a new design, a week of testing. The hard part is the records. Consent collected under the old platform has to survive the move, or the new platform starts from zero and every returning visitor gets re-prompted for consent they already gave.
The first step is the export, and it has to happen before the old contract ends. Ask the outgoing CMP for a full export of consent records: who, when, what they agreed to, and the banner version they saw. Time how long it takes to produce. If the answer needs a vendor ticket and three days, start the migration a month earlier than planned. A record export that arrives after the contract ends may not arrive at all.
The parallel run
Run both platforms at once, on different pages or different traffic slices, and compare what they record for the same visitor. The strings should match: same purposes, same vendors, same timestamps within seconds. If they do not match, the new platform is configured differently, and the difference is a configuration error, not a rounding error. Fix it before the cutover, not after, because after the cutover the old platform is gone and there is nothing to compare against.
Keep the old platform's records after the move. The new platform's records start on cutover day; anything before that lives in the export. An auditor asking about consent collected in September does not care that you changed vendors in November. The export is the evidence, and it has to be stored where your team can find it without the old vendor's dashboard.
When re-consent is actually required
A platform change by itself does not require fresh consent. What requires it is a change in what is being asked: a new purpose, a new vendor, a new way of processing. If the new platform serves the same purposes with the same vendors, the old consent carries over. If it adds vendors or purposes, the affected visitors have to be asked again, and the prompt has to say what changed. Teams that re-prompt everyone after a migration are not being careful. They are admitting they did not check whether anything changed.
Write the decision down: what changed, what did not, and why no re-prompt was needed, or who got re-prompted and when. File it with the export. The migration is not done when the new banner is live. It is done when the records from both platforms tell one continuous story.
Keep reading: Consent Renewal Intervals: How Often to Ask Again, Preticked Boxes and the Planet49 Rule, and Server-Side Tagging and the Consent Gap It Opens cover the nearby cases in this series.
Frequently asked questions
Does switching CMPs require fresh consent from all visitors?
Not by itself. A platform change does not require re-consent. What requires it is a change in what is being asked: a new purpose, a new vendor, or a new way of processing. If nothing changed, the old consent carries over.
What should a consent record export contain?
Who consented, when, what they agreed to, and the banner version they saw. Export it before the old contract ends, and store it where your team can find it without the old vendor's dashboard.
Why run both CMPs in parallel during a migration?
So you can compare what they record for the same visitor. The strings should match on purposes, vendors, and timestamps. If they do not, the new platform is configured differently, and that is an error to fix before cutover.
How long should I keep the old platform's records?
As long as the consent is the legal basis for processing, plus the limitation period for claims. An auditor asking about September consent does not care that you changed vendors in November.