Didomi Migration Checklist: What to Verify After Switching CMPs

Introduction

*Updated for 2026 compliance practices.*

Switching consent management platforms (CMPs) is a significant operational change for any website. When you move to or from Didomi, the migration isn’t complete once the new banner appears. You must verify that consent signals are correctly collected, respected, and communicated to all integrated services. This Didomi migration checklist: what to verify after switching CMPs provides a practical, step-by-step verification framework to help you confirm that your new setup meets GDPR and ePrivacy requirements, maintains data accuracy, and avoids common post-migration gaps.

A CMP migration touches every part of your consent infrastructure: the banner itself, the underlying consent API, tag management triggers, cookie behavior, and the legal disclosures that support valid consent. Even a small misconfiguration can lead to unauthorized data collection, broken analytics, or regulatory exposure. This guide focuses on the technical and operational checks you can perform yourself, using browser tools and the GDPRChecker scanner, to ensure your Didomi migration is complete and compliant.

What Is a Didomi Migration Checklist?

A Didomi migration checklist is a structured set of verification steps that website owners and developers follow after switching their consent management platform to or from Didomi. It covers the technical, operational, and disclosure elements that must be validated to maintain GDPR compliance. The checklist ensures that consent states are correctly propagated, tags fire only when permitted, and all required legal information remains accessible and accurate.

When you change CMPs, the underlying consent model may shift. For example, Didomi uses a specific consent API and data layer that differ from other platforms. Your tag management system (like Google Tag Manager) and analytics tools must be reconfigured to listen to the new consent signals. Without a thorough checklist, it’s easy to overlook critical details such as default consent states, pre-consent network requests, or the correct implementation of Google Consent Mode v2.

This checklist is not a one-time task. After migration, you should periodically re-verify your setup, especially after website updates, new tag deployments, or changes to your privacy policy. Regular scanning with GDPRChecker helps catch regressions and ensures ongoing compliance.

Requirements and Compliance Expectations

After a CMP migration, your website must continue to meet the core principles of GDPR and ePrivacy. The European Data Protection Board (EDPB) emphasizes that consent must be freely given, specific, informed, and unambiguous. Your new CMP must obtain consent before any non-essential cookies or trackers are set, and you must be able to demonstrate that consent was validly obtained.

Key compliance expectations include:

**Prior consent**: No non-essential trackers fire before the user makes a choice.
**Granular consent**: Users can select which purposes they consent to, and your setup respects those choices.
**Easy withdrawal**: Users can change or withdraw consent at any time, and your site must honor those changes immediately.
**Consent records**: You must keep proof of consent, including timestamps and the consent choices made.
**Transparent disclosures**: Your privacy policy and cookie notice must accurately reflect your data practices and the CMP in use.

Google’s Consent Mode v2 adds another layer. It requires that consent signals for `ad_storage`, `analytics_storage`, `ad_user_data`, and `ad_personalization` are passed to Google services. If you use Google Analytics 4 or Google Ads, your migration must ensure that Consent Mode is correctly implemented and that default consent states are set appropriately.

GDPRChecker’s scanning tools help you verify these requirements by checking pre-consent network requests, banner behavior, and disclosure gaps. However, remember that guides like this provide technical implementation guidance, not legal advice. Always consult with a qualified privacy professional for legal interpretations.

Step-by-Step Implementation Verification

1. Verify Consent Banner Behavior

Start by testing the consent banner on multiple browsers and devices. Clear your cookies and site data, then visit your website. The banner should appear immediately and block all non-essential scripts until you interact with it.

**Check default state**: No pre-checked boxes should be present for non-essential categories. The “Reject All” option must be as prominent as “Accept All.”
**Test all buttons**: Click “Accept All,” “Reject All,” and “Customize.” After each action, verify that the banner disappears and the consent state is stored.
**Revisit the banner**: Use the cookie settings link (often in the footer) to reopen the banner and change your preferences. Confirm that changes take effect without a page refresh.

2. Validate Pre-Consent Network Requests

Before consent is given, your site should not fire any non-essential network requests. Use browser developer tools (Network tab) to inspect requests made on page load before interacting with the banner.

**Filter by third-party domains**: Look for requests to analytics, advertising, or social media domains. These should be absent or, if using Consent Mode, sent in a cookieless state.
**Check for stray tags**: Sometimes tags are hardcoded in the page HTML rather than managed through a tag manager. Ensure these are also blocked.

GDPRChecker’s scanner automates this by crawling your site and flagging any requests that occur before consent. This is especially useful for catching edge cases on subpages or after user interactions.

3. Confirm Tag Manager Triggers

If you use Google Tag Manager (GTM), your triggers must be updated to listen to the new CMP’s consent signals. Didomi pushes consent events to the data layer, which GTM can use to fire or block tags.

**Review all tags**: For each tag, check that the firing trigger includes a consent condition. For example, an analytics tag should only fire if `analytics_storage` consent is granted.
**Test in preview mode**: Use GTM’s preview mode to simulate different consent scenarios and verify that tags fire correctly.
**Check Consent Mode defaults**: If you use Google Consent Mode, ensure the default command is set before GTM loads. The default should deny all until consent is updated.

4. Inspect Cookie Behavior

After consent is given or denied, check which cookies are actually set in the browser. Use the Application tab in developer tools to view cookies.

**Essential cookies**: These should be set regardless of consent, but only if they are strictly necessary.
**Non-essential cookies**: These should only appear after the user has given explicit consent for the relevant category.
**Cookie duration**: Verify that cookie lifespans match what is declared in your cookie policy.

5. Review Privacy Policy and Disclosures

Your privacy policy must be updated to reflect the new CMP. It should name Didomi as your consent provider, explain how consent is managed, and list all categories of cookies and trackers.

**Link to the cookie settings**: Ensure the policy includes a functional link that reopens the consent banner.
**Update cookie table**: If you maintain a cookie declaration table, update it to match the current cookies and purposes.
**Check for consistency**: The policy should not reference the old CMP or outdated consent mechanisms.

6. Test Reject-Flow and Withdrawal

A common mistake is to test only the “Accept All” path. You must also verify that rejecting consent works correctly.

**Reject all and browse**: After rejecting, navigate through several pages. No non-essential cookies should be set, and analytics should not record the visit (or only in a limited, consent-less mode).
**Withdraw consent**: Use the cookie settings link to withdraw consent. Confirm that previously set non-essential cookies are deleted or blocked.

7. Validate Google Consent Mode v2

If you use Google services, Consent Mode v2 is critical. Verify that the consent state is correctly communicated to Google tags.

**Check the consent state**: In the browser console, you can inspect the `google_tag_data` object or use the Google Tag Assistant extension to see the consent status.
**Test default and update commands**: Ensure that the default command denies all, and that after consent, an update command is sent with the user’s choices.
**Monitor in GA4**: In Google Analytics 4, use the Consent Mode debugging view to confirm that consent signals are being received.

8. Post-Change Scanning with GDPRChecker

After completing manual checks, run a comprehensive scan with GDPRChecker. The scanner will crawl your site and identify:

Pre-consent requests that should be blocked.
Missing or misconfigured consent banners.
Policy links that are broken or outdated.
Cookies that are set without consent.

Use the scan results to fix any remaining issues, then rescan to confirm resolution. Regular scanning should be part of your ongoing compliance routine.

Common Mistakes and How to Avoid Them

Mistake 1: Assuming the Old Configuration Works

After migration, your old GTM triggers or hardcoded scripts may still reference the previous CMP’s API. This can cause tags to fire without consent or not fire at all. Always audit all tag configurations and update them to use Didomi’s consent events.

Mistake 2: Ignoring Pre-Consent Requests

Even if your banner appears, some scripts might load before the CMP initializes. This is common with asynchronous scripts or those placed in the `<head>` without proper blocking. Use GDPRChecker to detect these early requests and adjust your loading strategy.

Mistake 3: Incomplete Reject-Flow Testing

Many teams test only the accept path. A broken reject flow can lead to unauthorized data collection and regulatory risk. Test the reject flow thoroughly, including on subpages and after form submissions.

Mistake 4: Overlooking Consent Mode Defaults

If you use Google Consent Mode, the default command must be set to denied for all storage types. If it’s set to granted by default, Google tags will collect data before consent, violating GDPR. Double-check the default command in your site’s source code.

Mistake 5: Failing to Update Legal Disclosures

Your privacy policy and cookie notice must accurately reflect your current CMP and data practices. An outdated policy can mislead users and regulators. Review and update all legal pages immediately after migration.

How to Validate with GDPRChecker

GDPRChecker provides a dedicated scanning engine that automates many of the verification steps described above. Here’s how to use it effectively after a Didomi migration:

**Run a full site scan**: Enter your domain and let GDPRChecker crawl your pages. The scanner checks for consent banners, pre-consent requests, cookie behavior, and policy links.
**Review the consent report**: The report highlights pages where consent is missing or misconfigured. Pay special attention to any pages flagged for pre-consent requests.
**Check Google Consent Mode integration**: If you’ve enabled Consent Mode, GDPRChecker can verify that the default and update commands are correctly implemented.
**Monitor over time**: Set up recurring scans to catch regressions. After any site update, rescan to ensure compliance hasn’t been broken.

For advanced needs, GDPRChecker’s paid plans offer managed consent banner deployment, runtime protection, and consent records. These features help you maintain a robust consent framework beyond the initial migration.

Implementation Checklist

Use this numbered checklist to systematically verify your Didomi migration. Check off each item as you complete it.

Clear browser data and test the consent banner on desktop and mobile.
Verify that no non-essential cookies are set before consent.
Inspect network requests before consent; block any unauthorized third-party calls.
Update all GTM triggers to use Didomi consent events.
Test “Accept All,” “Reject All,” and “Customize” flows.
Confirm that rejecting consent prevents all non-essential tracking.
Test consent withdrawal via the cookie settings link.
Validate Google Consent Mode v2 default and update commands.
Update privacy policy and cookie notice to reference Didomi.
Run a GDPRChecker scan and resolve all flagged issues.
Document your consent configuration and keep records of consent logs.
Schedule recurring GDPRChecker scans to monitor ongoing compliance.

FAQ

What is a Didomi migration checklist? A Didomi migration checklist is a set of verification steps to ensure your website remains GDPR-compliant after switching to or from the Didomi CMP. It covers consent banner behavior, tag management, cookie controls, and legal disclosures.

Do I need a Didomi migration checklist for GDPR? Yes. GDPR requires that consent mechanisms work correctly and that you can demonstrate compliance. A migration checklist helps you systematically verify that no gaps were introduced during the CMP switch.

How do I implement a Didomi migration checklist? Start by testing the consent banner, then inspect pre-consent network requests, update tag triggers, validate cookie behavior, review legal pages, and scan with GDPRChecker. Follow the step-by-step guide above for detailed instructions.

How can I verify my Didomi migration with a scanner? Use GDPRChecker to scan your website for pre-consent requests, missing banners, and policy gaps. The scanner automates detection of common post-migration issues and provides a report you can act on.

What are common Didomi migration mistakes? Common mistakes include outdated tag triggers, pre-consent network requests, incomplete reject-flow testing, incorrect Consent Mode defaults, and failure to update the privacy policy. Each can lead to non-compliance.

Which cookies and trackers should I check after migration? Check all non-essential cookies and trackers, including analytics, advertising, and social media scripts. Verify they only fire after appropriate consent and that their lifespans match your cookie policy.

How often should I review my Didomi migration checklist? Review the checklist immediately after migration, then re-verify after any site changes, new tag deployments, or privacy policy updates. Regular GDPRChecker scans (e.g., monthly) help maintain compliance.

What evidence should I keep for my Didomi migration? Keep records of your consent configuration, GTM trigger setups, scan reports from GDPRChecker, and consent logs. This documentation demonstrates your compliance efforts to regulators if needed.

Conclusion

A Didomi migration is more than a technical swap; it’s a critical compliance event that requires thorough verification. By following this Didomi migration checklist: what to verify after switching CMPs, you can ensure that consent is properly managed, tags fire only when allowed, and your legal disclosures remain accurate. Use the practical steps and common mistake warnings in this guide to avoid the pitfalls that often accompany CMP changes.

For ongoing assurance, integrate GDPRChecker into your compliance workflow. Its scanning capabilities provide an objective check on your consent implementation, helping you catch issues before they become problems. Remember, while this guide offers technical direction, it does not constitute legal advice. For specific legal interpretations, consult a qualified professional.

For more guidance on related topics, explore our GDPR checklist for small businesses, learn how to use our Google Consent Mode v2 checker, review privacy policy requirements, understand what GDPR is, what ePrivacy is, and what cookie consent entails.

Comparison: common implementation approaches

| Approach | Best for | Evidence to retain | Trade-off | | --- | --- | --- | --- | | A shared consent record | Smaller sites with one banner and a limited set of tags | Consent choice, timestamp, policy version, and affected pages | Requires a reliable process when the banner changes | | A tag-manager based record | Teams that control analytics and advertising tags centrally | Consent defaults, trigger conditions, publish history, and test results | Can miss scripts added outside the tag manager | | A CMP or external consent platform export | Sites with multiple domains, vendors, or regional workflows | Vendor configuration, consent events, retention settings, and audit exports | Adds provider configuration and recurring review work |

Choose the approach that matches the site's tracking complexity, then verify that the stored evidence can explain what a visitor saw and what tags were allowed at that time.

Practical examples

Example 1: A small ecommerce site

A shop changes its cookie banner wording before a seasonal campaign. The operator records the previous and new banner version, tests Reject all and Accept all, and stores screenshots plus the resulting network checks. That creates a clear before-and-after record without relying on memory.

Example 2: A B2B lead-generation site

A marketing team adds a form analytics tag through its tag manager. Before publishing, it documents the consent category, the tag trigger, the privacy notice update, and a test showing that the request does not fire after a visitor rejects optional cookies.

Example 3: A multi-page content site

An editor notices that a new embedded video adds a third-party request. The team scans the affected pages, compares the result with the last scan, updates the cookie disclosure if necessary, and keeps the scan report with the deployment reference.

Article schema

```json { "@context": "https://schema.org", "@type": "Article", "headline": "Didomi Migration Checklist: What to Verify After Switching CMPs", "description": "Practical Didomi migration checklist: verify consent defaults, pre-consent requests, tag triggers, and policy disclosures after switching CMPs. Use GDPRChecker to scan and validate your setup.", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://www.gdprchecker.online/guides/didomi-migration-checklist-what-to-verify-after-switching-cmps" }, "publisher": { "@type": "Organization", "name": "GDPRChecker", "url": "https://www.gdprchecker.online" } } ```

Copyright and editorial notice

This original AI-assisted editorial draft was selected, reviewed, and published by GDPRChecker. All rights are reserved where protected by applicable law. Do not reproduce the article without permission.