Switching consent platforms: how to migrate without losing your consent records

October 1, 2026 · ConsentVigil

Switching consent platforms is a data migration problem before it is a banner problem. The banner is the easy part. The hard part is carrying over the history of what every past visitor chose, in a form you can still prove later. Export the old records first, map the old categories to the new ones in writing, run both systems briefly in parallel, and keep the export as your permanent archive even after the new platform is live.

Why migrations happen

Sites switch consent platforms for ordinary reasons: the old vendor raised prices, the banner slowed the site, support went quiet, or a new privacy law needs features the old tool never built. None of those reasons are risky on their own. The risk is treating the switch like a design refresh, swapping one banner for another, instead of treating it like the data migration it is.

Every day your old platform ran, it collected the one asset regulators care about most: timestamped records of what individual visitors consented to. Those records are your evidence in any inquiry. A migration that orphans them, by leaving them in a canceled account you can no longer log into, quietly deletes your proof of compliance for every visit that happened before the switch.

What actually breaks in a migration

Three things break, in order of pain. First, the consent records themselves: the new platform starts with a blank history, and unless you export the old one, there is no bridge between them. Second, the category mapping: your old tool's analytics category and the new tool's analytics category are probably not identical, and vendors you had classified one way may default to another. Third, the integrations: tag managers, mobile SDKs, and server-side endpoints that referenced the old platform's consent state need to be repointed, and every missed reference is a place where tracking runs on stale or missing consent.

The category mapping is the one teams underestimate. Consent platforms do not share a standard taxonomy for purposes, so marketing in the old tool might include vendors that the new tool files under functional, or vice versa. A mapping done casually, or left to the new vendor's onboarding defaults, silently changes what visitors consented to after the switch.

Exporting the old records first

Before anything else, export everything the old platform will give you: the consent log, the banner configuration history, the list of vendors and purposes as they were classified, and the exact banner text that was live at each point. Do this while the account is still active and support still answers. Canceled accounts have a way of becoming read-only, then unreachable, then gone.

Store the export somewhere you control, not inside the new platform. A CSV or JSON archive in your own storage is the permanent record. The new platform's import, if it offers one, is a convenience for continuity, not a replacement for the archive. Regulators ask for records from the period the old platform covered, and they will not accept we switched vendors as an answer.

Mapping categories between platforms

Write the mapping down as a table: old purpose, new purpose, and the list of vendors under each. Go vendor by vendor for anything that touches advertising or analytics. Where the new platform has no equivalent category, make an explicit decision and document it rather than letting the default decide for you.

Pay special attention to vendors the old platform handled with custom rules. Those customizations are institutional knowledge that lives in the old configuration, and they are the first thing lost in a migration. If a vendor was blocked until explicit opt-in under the old system, make sure the new system reproduces that exact behavior, not just a similar-sounding category.

Running both in parallel

For a short window, keep the old platform in logging mode alongside the new banner. The goal is overlap, not a hard cutover: confirm the new platform sees the same consent state the old one recorded before you retire the old one.

Test the three consent choices under the new platform the same way you would audit any banner: accept all, reject all, and necessary-only, watching network traffic each time. Any tracker that behaved one way under the old system and another under the new one is a finding to fix before the old system is removed, not after.

The cutover checklist

• Export of the old consent log, banner configs, vendor classifications, and banner text history, stored in your own storage.
• Written category mapping, reviewed vendor by vendor for advertising and analytics.
• Tag manager, SDK, and server-side references repointed to the new platform's consent state.
• Behavior tested under accept, reject, and necessary-only, with results documented.
• Privacy policy and cookie policy updated to name the new platform where the old one was named.
• Old platform kept in read-only or logging mode for at least one full billing cycle after cutover.

Keeping the audit trail after the switch

After the migration, your compliance story has two chapters: the archived records from the old platform and the live records from the new one. Keep both retrievable. The next time you re-check your setup, and the time after that, verify that the old archive is still readable and the new platform's log is complete. A migration done well is invisible to visitors and boring to regulators, which is exactly the outcome you want.