CookieYes Migration Checklist: What to Verify After Switching CMPs

Introduction

*Updated for 2026 compliance practices.*

Switching consent management platforms (CMPs) is a significant undertaking for any website owner. Whether you are moving to CookieYes from another provider or upgrading your existing setup, a **CookieYes migration checklist: what to verify after switching CMPs** is essential to ensure ongoing GDPR compliance. A migration is not complete when the new banner appears—it is complete only after you have verified that consent signals are correctly collected, respected, and integrated with your tags, analytics, and privacy disclosures. This guide provides a practical, step-by-step verification framework. It draws on official sources such as the European Data Protection Board and GDPR.eu, as well as technical documentation for Google Consent Mode and GA4 consent. Use this checklist to close common gaps and confirm that your new CMP implementation meets regulatory expectations.

What Is a CookieYes Migration Checklist?

A **CookieYes migration checklist: what to verify after switching CMPs** is a structured set of verification steps that website operators follow after deploying a new consent management platform. The checklist focuses on technical and disclosure elements that directly affect GDPR and ePrivacy compliance. It covers consent defaults (no tracking before consent), banner behavior (clear reject option, no dark patterns), tag management integration (firing rules based on consent state), privacy policy updates (accurate cookie descriptions), and post-migration scanning to detect unauthorised network requests. This checklist is not a one-time activity; it should be revisited after any significant change to your site’s tags, plugins, or CMP configuration. While this guide provides technical implementation guidance, it does not constitute legal advice. Always consult a qualified privacy professional for jurisdiction-specific requirements.

Why Verification After Switching CMPs Matters

A CMP migration introduces risk. Even if your previous setup was compliant, the transition can create gaps that lead to non-consensual data processing. Regulators increasingly scrutinise the technical implementation of consent, not just the presence of a banner. For example, the EDPB’s guidelines emphasise that consent must be informed, specific, and freely given, and that websites must be able to demonstrate compliance. If your new CMP allows tags to fire before consent is obtained, or if your privacy policy does not accurately reflect the cookies in use, you could face enforcement action. Verification is also critical for maintaining data accuracy in tools like Google Analytics 4, where consent signals directly affect modelled data and reporting. A thorough post-migration check protects both user privacy and your business intelligence.

Pre-Migration Preparation: What to Document

Before you switch, document your current state. This baseline will make post-migration verification faster and more reliable.

• **Inventory all tags and cookies**: Use a scanner like GDPRChecker to capture every network request and cookie set by your site. Note which ones are strictly necessary and which require consent.
• **Map consent categories**: Identify which cookies belong to functional, analytics, marketing, and other categories. This mapping will guide your CookieYes configuration.
• **Record consent triggers**: If you use Google Tag Manager, document which triggers are consent-dependent. For example, a GA4 configuration tag should fire only on consent grant for analytics_storage.
• **Save privacy policy and cookie declaration**: Keep a dated copy of your current disclosures. After migration, you will update these to reflect the new CMP’s cookie list.
• **Check existing consent mode setup**: If you use Google Consent Mode v2, note your current default consent states and update commands. This will help you align CookieYes with the required consent signals.

Step-by-Step Verification After Switching to CookieYes

Once CookieYes is live, work through these verification areas systematically. Each section includes specific checks and common pitfalls.

1. Verify Consent Defaults and Pre-Consent Behaviour

The most critical check is that no non-essential cookies or tracking requests fire before the user has given consent. This is a fundamental GDPR requirement.

• **Test in an incognito/private window**: Open a fresh browser session and navigate to your site. Before interacting with the banner, open the browser’s developer tools (Network tab) and reload the page.
• **Inspect network requests**: Look for requests to third-party domains such as google-analytics.com, facebook.com, or any marketing pixels. These should be absent until consent is granted.
• **Check cookie storage**: In the Application tab, examine Cookies. Only strictly necessary cookies (e.g., session IDs, CSRF tokens) should be present. No _ga, _fbp, or similar tracking cookies.
• **Validate Consent Mode defaults**: If you use Google Consent Mode, verify that the default consent state is set to denied for all non-essential consent types. You can check this by typing `google_tag_data.ics` in the console; entries should show `ad_storage: 'denied'`, `analytics_storage: 'denied'`, etc.
• **Common mistake**: A tag management script loads before the CMP, setting cookies before the banner even appears. Ensure CookieYes loads synchronously in the `<head>` and blocks tags until consent is given.

2. Test the Reject Flow and Granular Choices

GDPR requires that refusing consent be as easy as giving it. Your CookieYes banner must offer a clear reject button (not just a settings link) and respect granular preferences.

• **Reject all and scan**: Click “Reject All” (or equivalent) and then scan the page again. No marketing or analytics cookies should appear. If you use Consent Mode, the consent state should remain denied.
• **Granular consent test**: Use the cookie settings panel to enable only analytics cookies, then save. Verify that analytics requests fire but marketing requests do not. Then switch to enable marketing and disable analytics, and confirm the opposite.
• **Check for dark patterns**: The reject option should be equally prominent as the accept button. It should not require multiple clicks or be hidden behind a link. The EDPB has issued guidance against deceptive design.
• **Edge case**: Some CMPs allow a “legitimate interest” toggle. If you rely on legitimate interest for any processing, ensure users can still object easily. However, for most behavioural advertising, consent is the only valid legal basis.

3. Validate Tag Manager and Consent Triggers

If you use Google Tag Manager (GTM) or another tag management system, your triggers must be updated to fire based on CookieYes consent events.

• **Review GTM triggers**: Each tag that sets cookies or accesses device storage should have a firing trigger that listens for a consent update from CookieYes. For example, a Custom Event trigger for `cookieyes_consent_update` with conditions on specific consent categories.
• **Test with GTM Preview mode**: Enable Preview, then go through the consent flow. Verify that tags fire only after the corresponding consent is granted. Check the “Tags Fired” and “Tags Not Fired” lists.
• **Consent Mode integration**: If you use Google Consent Mode, CookieYes should send an `update` command when consent changes. In GTM, ensure your consent initialisation and configuration tags are set correctly. Use the Consent Overview in GTM to see the consent state for each event.
• **Common mistake**: Tags are still using the old CMP’s consent events. Update all triggers to reference CookieYes-specific events. Also, check that tags are not set to fire on “All Pages” without a consent check.

4. Close the Privacy Policy and Cookie Declaration Gap

Your privacy policy and cookie declaration must accurately reflect the cookies and purposes managed by CookieYes. After migration, the list of cookies may change because CookieYes categorises them differently or because you have reconfigured your tags.

• **Update the cookie list**: CookieYes generates a cookie declaration that you can embed or link to. Ensure this list matches the cookies actually observed on your site. Cross-reference with a GDPRChecker scan.
• **Review policy language**: Your privacy policy should explain what CookieYes does, how users can manage preferences, and the legal basis for each cookie category. Update any references to the old CMP.
• **Link to the cookie policy**: The banner should link to your privacy policy or cookie policy. Test that the link works and that the policy is easy to find.
• **Common mistake**: The cookie declaration lists cookies that are no longer present, or misses new ones. This can happen if you removed a plugin but the declaration still shows its cookies. Regular scanning helps keep this accurate.

5. Check DSAR and Consent Logging

Under GDPR, you must be able to demonstrate that consent was obtained. CookieYes stores consent logs, but you need to verify that logging is working and that you can retrieve records if a user submits a Data Subject Access Request (DSAR).

• **Test consent logging**: Give consent on your site, then check the CookieYes dashboard to see if the consent record appears. It should include the timestamp, consent choices, and an anonymised user identifier.
• **Export logs**: Ensure you can export consent logs in a machine-readable format. This is important for responding to DSARs or regulatory inquiries.
• **Retention period**: Confirm that consent logs are retained for an appropriate period (often the duration of processing plus the limitation period for legal claims).
• **Common mistake**: Consent logging is not enabled, or the CMP is not configured to capture all necessary fields. Without logs, you cannot prove compliance.

6. Validate with GDPRChecker Post-Migration

Automated scanning is the most reliable way to catch issues that manual testing might miss. GDPRChecker can simulate user journeys and detect pre-consent network requests, cookie drops, and disclosure gaps.

• **Run a full site scan**: After completing the manual checks, run a GDPRChecker scan on your site. Configure it to crawl multiple pages, including pages with embedded videos, forms, or social media widgets.
• **Review the pre-consent report**: GDPRChecker will flag any requests that occurred before consent. Investigate each one. Some may be false positives (e.g., CDN requests), but any tracking domain should be blocked.
• **Check the cookie declaration**: GDPRChecker compares observed cookies against your declared cookies. If there are undeclared cookies, update your cookie list in CookieYes and your privacy policy.
• **Schedule regular scans**: Set up recurring scans (e.g., weekly) to catch new cookies introduced by plugin updates or tag changes. This closes the ongoing compliance gap.

**Ready to verify your migration?** Run a GDPRChecker scan to detect pre-consent requests and undeclared cookies automatically.

Common Mistakes and How to Avoid Them

Even experienced developers make these mistakes during CMP migration. Being aware of them can save you time and reduce compliance risk.

• **Mistake 1: Forgetting to update hardcoded scripts**. If you have analytics or marketing scripts hardcoded in your HTML, they will fire regardless of CMP settings. Move all such scripts into a tag manager and apply consent triggers.
• **Mistake 2: Ignoring iframes and embedded content**. YouTube videos, Twitter embeds, and other third-party iframes often set cookies. CookieYes can block these until consent, but you must enable the relevant service in the CMP settings.
• **Mistake 3: Not testing on all subdomains**. If your CMP is configured for the main domain only, subdomains may not show the banner or may set cookies independently. Ensure the CMP script is loaded across all relevant subdomains.
• **Mistake 4: Overlooking server-side tracking**. If you use server-side GTM or other server-side tracking, consent signals must still be respected. Verify that your server-side setup receives consent state and blocks data flow accordingly.
• **Mistake 5: Assuming the default configuration is compliant**. CMPs provide a framework, but you must configure categories, services, and blocking rules to match your actual cookie usage. A default setup rarely covers all edge cases.

Comparison: CookieYes vs. Manual Consent Management

Some website owners consider building a custom consent banner instead of using a dedicated CMP. The table below compares the two approaches on key verification factors.

| Factor | CookieYes (Dedicated CMP) | Manual Consent Management | |--------|---------------------------|---------------------------| | Pre-consent blocking | Automatic blocking of known tracking scripts; configurable per service. | Requires custom JavaScript to prevent all non-essential scripts from loading. | | Consent logging | Built-in dashboard with exportable logs; timestamps and consent choices recorded. | Must be built from scratch; risk of incomplete or lost logs. | | Cookie declaration | Auto-generated list based on scan; updates with new cookies. | Manual maintenance; prone to inaccuracy as site changes. | | Google Consent Mode integration | Native support; sends default and update commands automatically. | Requires manual implementation of the Consent Mode API; complex to maintain. | | Granular consent UI | Pre-built preference centre with toggles per category. | Must design and code UI; accessibility and dark pattern risks. | | Ongoing compliance | Regular updates to blocking list; support for new regulations. | Full burden on the website owner to monitor and adapt. |

For most website owners, a dedicated CMP like CookieYes reduces the risk of technical non-compliance and simplifies the verification process. However, even with a CMP, the checks in this guide remain necessary.

Real-World Examples of Post-Migration Verification

**Example 1: E-commerce site migrating from a basic cookie notice** An online store replaced a simple “we use cookies” banner with CookieYes. After migration, a GDPRChecker scan revealed that the Facebook pixel was still firing before consent because it was hardcoded in the theme. The developer moved the pixel to GTM and applied a consent trigger. A rescan confirmed no pre-consent marketing requests.

**Example 2: SaaS blog with embedded YouTube videos** A software company’s blog used CookieYes but noticed in GA4 that some users from the EU had unusually high bounce rates. Investigation showed that YouTube iframes were blocked by default, but the placeholder was not loading correctly on mobile. After adjusting the placeholder settings, video engagement returned without compromising consent.

**Example 3: News publisher using Google Consent Mode v2** A news site migrated to CookieYes and enabled Consent Mode. Initial testing showed that `ad_storage` was still set to `granted` by default due to a misconfiguration in the GTM consent initialisation tag. Correcting the default to `denied` and verifying with the console command `google_tag_data.ics` resolved the issue. The site then saw accurate modelled data in GA4.

Implementation Checklist

Use this numbered checklist to systematically verify your CookieYes migration. Tick each item only after testing.

1. Document pre-migration cookie inventory and consent triggers.
2. Install CookieYes script in the `<head>` of all pages, ensuring it loads before any tracking scripts.
3. Configure cookie categories and map each tag/cookie to the correct category.
4. Set default consent state to denied for all non-essential categories (if using Consent Mode, verify `ad_storage`, `analytics_storage`, etc. are denied).
5. Test in incognito: no non-essential network requests or cookies before consent.
6. Verify reject flow: clicking “Reject All” prevents all non-essential cookies and requests.
7. Test granular consent: enable only one category at a time and confirm corresponding tags fire.
8. Update GTM triggers to use CookieYes consent events; test with Preview mode.
9. Update privacy policy and cookie declaration to match the new CMP’s cookie list.
10. Confirm consent logging is active and logs are exportable.
11. Run a full GDPRChecker scan and resolve any pre-consent requests or undeclared cookies.
12. Schedule recurring GDPRChecker scans and review consent logs monthly.

FAQ

What is CookieYes migration checklist: what to verify after switching cmps? It is a set of verification steps to ensure your website remains GDPR-compliant after moving to CookieYes. The checklist covers consent defaults, pre-consent network requests, tag manager triggers, privacy policy updates, and post-migration scanning. It helps you confirm that no tracking occurs without valid consent and that your disclosures are accurate.

Do I need CookieYes migration checklist: what to verify after switching cmps for GDPR? Yes, if you process personal data of EU/EEA users and rely on consent as a legal basis. GDPR requires that you implement consent correctly and be able to demonstrate compliance. A migration can introduce technical gaps that lead to non-consensual tracking, so verification is essential to meet regulatory expectations.

How do I implement CookieYes migration checklist: what to verify after switching cmps? Start by documenting your pre-migration state. After deploying CookieYes, test in an incognito browser to check for pre-consent requests. Verify the reject flow, granular choices, and tag manager triggers. Update your privacy policy and cookie declaration. Finally, run a GDPRChecker scan to catch any missed issues.

How can I verify CookieYes migration checklist: what to verify after switching cmps with a scanner? Use GDPRChecker to scan your site after migration. The scanner simulates user journeys and detects network requests and cookies set before consent. It also compares observed cookies against your declared list. Review the pre-consent report and resolve any flagged tracking domains or undeclared cookies.

What are common CookieYes migration checklist: what to verify after switching cmps mistakes? Common mistakes include forgetting to update hardcoded scripts, ignoring iframes that set cookies, not testing on subdomains, overlooking server-side tracking, and assuming the default CMP configuration is sufficient. Each of these can result in non-consensual data processing and should be explicitly checked.

Which cookies and trackers should I check for CookieYes migration checklist: what to verify after switching cmps? Check all non-essential cookies and trackers, including analytics (_ga, _gid), advertising (_fbp, _scid), social media widgets, and embedded content (YouTube, Vimeo). Also verify that strictly necessary cookies (session IDs, CSRF tokens) are still set correctly and are not blocked by the CMP.

How often should I review CookieYes migration checklist: what to verify after switching cmps? Review the checklist immediately after migration, then whenever you add new tags, plugins, or change your CMP configuration. Additionally, schedule recurring GDPRChecker scans (e.g., weekly or monthly) to catch new cookies introduced by third-party updates. Regular reviews help maintain ongoing compliance.

What evidence should I keep for CookieYes migration checklist: what to verify after switching cmps? Keep dated records of your pre-migration inventory, post-migration test results (screenshots of network tabs, console logs), consent log exports, and GDPRChecker scan reports. This documentation demonstrates your verification process and can be crucial if you need to prove compliance to a regulator.

Conclusion

A **CookieYes migration checklist: what to verify after switching CMPs** is not a luxury—it is a necessity for any website that values user privacy and regulatory compliance. By methodically testing consent defaults, reject flows, tag triggers, and disclosures, you close the gaps that often appear during CMP transitions. Remember that compliance is not a one-time event; it requires ongoing monitoring. Use tools like GDPRChecker to automate scans and catch issues before they become liabilities. For further reading, explore our guides on Google Consent Mode v2, privacy policy requirements, and what is cookie consent. If you are new to the regulations, start with what is GDPR and what is ePrivacy.

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.

> This guide is technical implementation guidance for website owners. It is not legal advice.

Article schema

```json { "@context": "https://schema.org", "@type": "Article", "headline": "CookieYes Migration Checklist: What to Verify After Switching CMPs", "description": "A practical guide to verifying your CookieYes migration. Learn step-by-step checks for consent defaults, pre-consent requests, tag triggers, policy disclosures, and how to validate with GDPRChecker.", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://www.gdprchecker.online/guides/cookieyes-migration-checklist-what-to-verify-after-switching-cmps" }, "publisher": { "@type": "Organization", "name": "GDPRChecker", "url": "https://www.gdprchecker.online" } } ```

Copyright and editorial notice