Your CMP Migration Left the Old Consent Records Behind
A team switches consent platforms on a Friday. The new banner looks better, the dashboard is cleaner, and the migration is declared done. On Monday, a returning visitor loads the site, and the new platform has no record of the choice that visitor made last month. It asks again. That is the correct behavior, and it is the part of the migration most teams forget to plan for: the old consent records belong to the old platform, and they do not move.
The gap matters because the record is the product. A regulator asking about a choice made in March wants the record from March, and the new platform, installed in November, has nothing before November. The old platform's export, if anyone exported it, sits in a spreadsheet somewhere, or it was deleted when the contract ended. Either way, the site cannot prove what happened before the migration, and the proof gap covers the exact period a complaint is most likely to concern.
What a migration plan has to include
Four items, and the banner is the last of them. First, export the old consent records before the contract ends, in a format the team can actually read, with the visitor identifier, the choice per purpose, the timestamp, and the banner version. Second, decide the retention window for those records and store them where the team can find them, not in one person's downloads folder. Third, run the new platform in parallel before cutting over, so the consent log has no gap and returning visitors are re-asked cleanly instead of hitting a blank. Fourth, re-scan the site with the new platform and re-categorize every tracker, because the old platform's categories do not transfer either.
The re-scan is where migrations usually fail quietly. The old platform knew that a particular script was analytics. The new platform sees an unknown script and guesses, or leaves it uncategorized, and the banner then asks the visitor about a category that does not match what the script does. The consent collected against the wrong category is not valid consent, and the site has been collecting it for weeks before anyone notices.
The cutover checklist
Budget a day for a small site and a week for a large one. Before cutover, confirm the export is readable and complete, the new platform's categories match the old ones, and the banner copy is right. After cutover, test the re-ask flow as a returning visitor, check the new log for the first day's entries, and confirm the old records are stored and retrievable. Keep the export somewhere the whole team can find it, not in one person's downloads folder, and note the retention window in the same place, so the next person who needs the records does not have to ask where they went. A migration that skips the export has not migrated. It has deleted the proof and bought a prettier banner with it.
Keep reading: Consent Records: What to Keep When a Visitor Says No, The Banner After a Redesign: Why a New Layout Means a New Consent Decision, and The Thank-You Page: Post-Purchase Tracking and the Consent It Forgot cover the nearby cases in this series.
Frequently asked questions
Do consent records transfer when I switch CMP?
No. Consent records belong to the old platform. Returning visitors have to be asked again, and the old records need to be exported before the contract ends.
How long should I keep old consent records after a migration?
Long enough to answer a regulator about choices made before the migration. Export them in a readable format with identifier, choice, timestamp, and banner version, and store them where the team can find them.
Why do I need to re-scan the site after switching CMP?
Because tracker categories do not transfer. The new platform sees unknown scripts and guesses, and consent collected against the wrong category is not valid consent.
How long does a CMP migration take?
A day for a small site and a week for a large one, including the parallel run. The parallel run is what keeps the consent log gap-free.