How to Migrate Your CMP Without Losing Existing Consent Records

Why Organizations Switch CMPs

Consent management platforms aren't forever. What worked when you first set up a cookie banner two years ago might be costing more than it should, missing features you now need, or falling behind on compliance.

The most common reasons teams decide to migrate CMP consent records in 2026:

• Cost: Enterprise CMP contracts often balloon at renewal. Some vendors charge per pageview or per domain, and pricing that looked reasonable at 50K monthly visitors becomes painful at 500K.
• Feature gaps: Your current platform might lack server-side consent enforcement, regional consent rules, automated cookie scanning, or proper Google Consent Mode v2 support.
• Compliance drift: If your CMP still doesn't support one-click reject, granular purpose-level consent, or the latest TCF 2.2 requirements, you're carrying legal risk on every page load.
• Vendor lock-in: Proprietary cookie taxonomies, opaque consent storage formats, and no export option. You realize you can't leave without losing everything.

The decision to switch is usually straightforward. The hard part is executing the migration without losing the consent records you've already collected.

The Consent Migration Problem

GDPR Article 7(1) requires that you be able to demonstrate that a data subject consented. Those consent records are your legal proof that you had permission to process data.

When you remove an old CMP without migrating consent state, two things break:

1. You lose accountability. If a regulator asks you to prove consent was given and your evidence lived entirely in the old vendor's system, you have a gap. This is the scenario that GDPR enforcement actions target.
2. Every returning visitor gets re-prompted. The new CMP doesn't recognize the old consent cookie, so it shows a fresh banner to everyone. For a site with millions of returning visitors, this means a mass re-consent event that tanks analytics and drops consent rates as users who previously accepted now hit reject.

A proper migration carries the user's existing choices forward so they aren't asked again, while preserving your consent audit trail.

Pre-Migration Checklist

Before touching code, gather this information. Rushing the technical steps without it is how teams trigger a full re-consent event on launch day.

Step 1: Export Existing Consent Data

Most CMPs store consent in at least two places, and you need to capture both before doing anything else.

Client-side (browser): The consent cookie that controls which categories the user accepted. Common examples: CookieConsent (Cookiebot), OptanonConsent (OneTrust), euconsent-v2 (TCF string). Some CMPs also store detailed per-purpose preferences in localStorage.

Server-side: Timestamped consent logs in the CMP vendor's database. These are your GDPR Article 7(1) accountability records. Most enterprise CMPs offer an API or dashboard export. Request a full export in CSV or JSON before you terminate the agreement. If your vendor doesn't provide an export path, that gap should be documented as part of your migration record.

The critical fields to preserve: a user identifier (even pseudonymous), the timestamp of consent, consent state per category (accepted or rejected), and the version of the banner or privacy policy that was shown. Archive these in your own infrastructure. Accountability obligations can extend beyond the consent's active lifetime. For retention guidance, see our piece on consent expiry and re-consent.

Step 2: Map Old Categories to New CMP Categories

No two CMPs use identical taxonomy. One platform's "Performance" is another's "Analytics." One groups social widgets under "Marketing"; another calls them "Functional."

Three principles:

• Never widen scope. If a user consented to "Analytics" only, don't map that to a broader category that includes marketing cookies.
• Err toward re-asking. If a clean mapping isn't possible for a category, re-prompt for it rather than assuming consent the user never gave.
• Document the mapping. This becomes part of your compliance record.

Step 3: Run Both CMPs in Parallel

Don't cut over in a single deploy. A parallel run lets you validate migration logic on real traffic.

1. Install the new CMP's script alongside the old one, configured to not show a banner by default.
2. Write migration logic (Step 4) that reads the old consent cookie and sets the new CMP's state programmatically.
3. Only show the new banner to users who have no existing consent cookie from the old CMP (first-time visitors).
4. Monitor for one to two weeks: returning users shouldn't see a banner, analytics tags should fire correctly, Consent Mode signals should remain intact.

During the parallel period, both cookies coexist. The old is read-only; the new is written based on mapped state. This is where you catch mapping errors before they affect your entire user base.

Step 4: Migrate Consent State for Returning Users

This is the core technical step. When a returning user has a consent cookie from the old CMP but not the new one, your migration script should:

1. Read the old consent cookie and parse it into structured per-category state.
2. Apply the category mapping from Step 2.
3. Set the new CMP's consent state via its API or by writing its cookie in the expected format.
4. Fire consent signals (Consent Mode gtag('consent', 'update', ...), TCF string) so downstream tags behave correctly.

A simplified example:

const oldConsent = JSON.parse(
  document.cookie.match(/OldCMPConsent=([^;]+)/)?.[1] || '{}'
);

const migrated = {
  analytics: oldConsent.performance === true,
  marketing: oldConsent.advertising === true || oldConsent.social === true,
  preferences: oldConsent.functional === true
};

newCMP.setConsent(migrated);

gtag('consent', 'update', {
  analytics_storage: migrated.analytics ? 'granted' : 'denied',
  ad_storage: migrated.marketing ? 'granted' : 'denied',
  ad_personalization: migrated.marketing ? 'granted' : 'denied',
  ad_user_data: migrated.marketing ? 'granted' : 'denied',
  functionality_storage: migrated.preferences ? 'granted' : 'denied'
});

The critical constraint: this script must run before the new CMP initializes. If the new CMP checks for its cookie first and finds nothing, it shows a banner. Your migration code has to write that cookie before the check.

Step 5: Remove the Old CMP and Verify

After the parallel run confirms seamless migration:

1. Remove the old CMP's script tag.
2. Keep the migration script running for the old cookie's full lifetime. If it has a 12-month expiry, users might return after months with only the old cookie.
3. Optionally expire old consent cookies after migration to reduce cookie bloat.

Verification matters. Systematically confirm the migration works:

• Manual testing: Set the old consent cookie in DevTools with known values. Load the page and confirm no banner appears.
• Consent Mode: Check dataLayer events for correct consent_update values. Google Tag Assistant shows real-time consent state.
• Analytics continuity: Compare GA4 session data before and after. A sudden drop means Consent Mode signals broke.
• Consent logs: Confirm new entries are written for migrated users, noting that consent was migrated rather than freshly collected.

Common Migration Pitfalls

Losing consent records entirely

The old CMP vendor's logs live in their system. Cancel your contract without exporting and you lose your accountability evidence. Always export before terminating.

Triggering mass re-consent

The new CMP doesn't find its own cookie, so every returning visitor gets a banner. The migration script from Step 4 prevents this, but it must run early enough in the page lifecycle to beat the new CMP's initialization.

Breaking Google Consent Mode

Consent Mode depends on gtag('consent', 'default', ...) firing before Google tags load. If the default state and migrated update don't align during transition, tags fire without proper consent signals. This creates data gaps in GA4 behavioral modeling and compliance exposure. See our Consent Mode v2 failures guide.

Category mapping errors

Mapping "Social Media" into "Analytics" because both seem like non-marketing tracking accidentally grants analytics consent to users who only accepted social widgets. Review mappings against the actual cookies in each category, not just the names.

Ignoring TCF string migration

If you run IAB TCF, the euconsent-v2 string encodes vendor-level consent. Dropping the old string means losing granular vendor consent and potentially affecting ad revenue.

The Zero-Downtime Migration Pattern

The full deployment sequence:

1. Week 1-2: Export server-side records. Document cookie formats and category mappings. Build and test the migration script in staging.
2. Week 3: Parallel deploy. New CMP alongside old. Migration script reads old cookies and writes new state before initialization. New visitors get the new banner; returning visitors are silently migrated.
3. Week 4-5: Monitor re-consent rates (should be near zero for returning users), Consent Mode signal accuracy, and analytics continuity.
4. Week 6: Remove old CMP script. Keep migration script active for old cookie lifetime.
5. Ongoing: Archive old consent records. Update privacy/cookie policies. Remove migration script once all old cookies have expired.

This works because there's never a moment when neither CMP is active, and returning users are never shown a banner they've already responded to. The total timeline varies with traffic volume and how long old cookies persist, but most teams complete the full cycle in under three months.

Migrating to CookieBeam

If you're switching to CookieBeam, the same pattern applies with a few specifics.

Consent cookie: CookieBeam stores consent in a structured _cb_consent cookie with per-category choices. Your migration script reads the old CMP's cookie, applies category mapping, and writes CookieBeam's consent state before its loader initializes. A pre-populated cookie prevents the banner from appearing.

Categories: CookieBeam uses four standard categories: Necessary, Analytics, Marketing, and Preferences. Map old categories following the "never widen scope" principle. The cookie categorization guide covers what belongs in each.

Consent Mode: CookieBeam natively fires Consent Mode v2 signals including ad_user_data and ad_personalization. When migrated state loads from the pre-populated cookie, CookieBeam sends the correct signals automatically. No separate gtag call needed in your migration script.

Consent logging: CookieBeam logs every action with timestamp, pseudonymous ID, per-category state, and banner version. After client-side migration, new log entries are created as migrated users interact. Maintain archived records from the old CMP alongside CookieBeam's logs during the transition.

Cookie scanning: Enable CookieBeam's automated scanner to catch any cookies from the old setup that were missed in category mapping. The scanner flags uncategorized cookies before they become a compliance gap.

For a broader comparison of what CookieBeam offers versus other platforms, see our 2026 cookie consent tools comparison.