Consent Log Retention When You Change Vendors: Export First, Cancel Second
Consent platform migrations fail quietly. The new banner ships, the old invoice stops, and eighteen months later a regulator or a litigant asks for proof of what a specific user agreed to in 2024. The records exist, technically, in a cancelled account nobody can log into.
Proof has two halves, the choice and the text it was a choice about. Migrations that export one and not the other produce archives that look complete until the day they are read.
The export checklist nobody writes down
Records export: one row per consent event, including withdrawals and changes, not just a current state snapshot. Notice archive: every version of the banner text, category descriptions, and cookie policy the platform served, with the date range each version was live. Configuration history: which tags were blocked under which categories, because a record saying 'marketing: off' only means something against the category definition of its day.
Ask for the export in a documented, non proprietary format, CSV or JSON with a data dictionary. Then actually load it somewhere and run three spot checks against users your team consented as testers. Vendors under cancellation notice have variable enthusiasm; verify while you still have leverage.
Retention duties outlive the contract
Consent records need to survive for the period your retention schedule sets, typically tied to limitation periods for privacy claims, and that clock does not pause because you changed tooling. The archive becomes your system of record for the old period. Store it with the same access controls and integrity protections as live records, ideally with a hash manifest created at export time so you can show the archive was not edited later. Name an owner for the archive, too. Orphaned exports on a departed employee's drive are the migration failure that only surfaces during a dispute, which is the worst possible moment to go looking.
Renegotiate the sequence if you must: several vendors will extend read only access for a short window after termination for a fee. That fee is trivial next to reconstructing proof you no longer have.
Cutover without a consent gap
Run the new platform in shadow on a staging property first, matching categories purpose by purpose to the old setup. At cutover, migrate current consent states where your legal basis allows it, so existing users are not re prompted without cause, and log the migration as a system event in the new platform. Any purpose whose definition changed materially earns a genuine re prompt, not a silent carry over.
Related reading
These earlier guides cover connected questions in more depth: Consent Log Retention When You Change Vendors: Export First, Cancel Second, Consent and Embedded Video: The Player That Phones Home Before Play, and How Long Should Consent Records Be Kept? Building a Retention Schedule.
Frequently asked questions
What if the old vendor only offers a current state export?
Push back in writing and escalate before cancelling. Current state snapshots lose withdrawal history, which is often exactly what a dispute is about. If the vendor truly cannot export events, document that limitation and retain read only access as long as possible.
Do we need the old banner texts, really?
Yes. Consent is agreement to a specific disclosure. Without the text and category definitions live at the time, a timestamped 'yes' cannot be evaluated, by you or by a regulator.
How long should we keep the archive?
Follow your consent retention schedule, commonly aligned to the limitation period for privacy claims in your main markets. The archive inherits that schedule; vendor changes do not shorten it.
Can we import old consent states into the new platform?
Usually yes for current states, provided purposes map cleanly. Materially changed purposes need fresh consent. Record the import date and source in the new system so the provenance survives.