GDPRChecker

Home / Knowledge Base / Osano Migration Checklist: What to Verify After Switching CMPs

Website Compliance

Osano Migration Checklist: What to Verify After Switching CMPs

A practical guide for website owners verifying their consent setup after migrating to or from Osano. Covers consent mode, banner testing, policy links, and automated scanning with GDPRChecker.

Author

GDPRChecker Editorial Team

Reviewed by

Privacy & Compliance Research Team

Last updated

August 2026

Reading time

14 min read

Educational guidance for compliance readiness — not legal advice. Requirements vary by jurisdiction and your specific processing activities.

Introduction

Switching consent management platforms (CMPs) is a significant operational change for any website owner. Whether you are moving away from Osano or adopting it as your new CMP, the migration process introduces risks that can silently break your compliance posture. An **Osano migration checklist: what to verify after switching CMPs** is a practical compliance topic for website owners validating consent, tags, and disclosures. This guide provides a technical, step-by-step verification framework to help you confirm that your new setup correctly controls cookies, trackers, and consent signals before you consider the migration complete.

After any CMP change, even small configuration gaps can lead to unauthorized data collection, broken consent mode signals, or missing policy disclosures. GDPRChecker scans help verify pre-consent network requests, banner behavior, and disclosure gaps after changes. By following this checklist, you can systematically close the most common post-migration gaps and build a defensible record of your compliance efforts.

This guide provides technical implementation guidance, not legal advice. Always consult qualified privacy counsel for jurisdiction-specific requirements. For foundational concepts, see our guides on what is GDPR and what is ePrivacy.

What Is an Osano Migration Checklist?

An Osano migration checklist is a structured verification plan that website operators use after replacing or implementing Osano as their consent management platform. It focuses on confirming that the new CMP correctly:

  • Blocks or allows tags and cookies based on user consent choices
  • Displays the consent banner in compliance with regulatory expectations
  • Communicates consent states to integrated services like Google Consent Mode
  • Links to accurate privacy policies and cookie disclosures
  • Preserves evidence of consent for audit purposes

Unlike a generic CMP implementation guide, this checklist specifically addresses the transition risks that arise when you swap one consent tool for another. For example, leftover hardcoded tags from a previous setup may fire regardless of the new CMP’s signals, or your tag manager triggers may still reference the old CMP’s custom events. A thorough **Osano migration checklist: what to verify after switching CMPs** catches these issues before they result in non-compliance.

Why Post-Migration Verification Matters

When you change CMPs, you are essentially rewiring the consent layer of your website. Even if the new banner looks correct to a casual visitor, several invisible failures can occur:

  • **Pre-consent network requests:** Tags or pixels may fire before the CMP has a chance to block them, sending personal data to third parties without consent.
  • **Consent mode misconfiguration:** Google services may default to full data collection if consent signals are not properly updated.
  • **Broken reject flows:** Users who click “Reject All” may still have non-essential cookies set because the CMP does not correctly revoke consent.
  • **Policy link rot:** The banner may point to an outdated privacy policy URL, undermining transparency obligations.

These failures are not hypothetical. They are common outcomes of incomplete migrations, and they can expose your organization to regulatory risk. A post-migration verification process using both manual checks and automated scanning is the only reliable way to confirm that your new CMP is working as intended.

Requirements and Compliance Expectations

Regulatory authorities expect that consent mechanisms are not just present but effective. The European Data Protection Board (EDPB) has emphasized that consent must be informed, specific, and freely given, and that withdrawing consent must be as easy as giving it. After a CMP migration, you must verify that your new setup meets these standards in practice, not just in theory.

Key compliance expectations include:

  • **Prior blocking:** Non-essential cookies and trackers must not be set or accessed before the user has made a choice.
  • **Granular options:** Users should be able to consent to specific purposes, not just an all-or-nothing choice.
  • **Equal prominence:** The “Reject All” option must be as visible and easy to use as the “Accept All” option.
  • **Consent evidence:** You must be able to demonstrate what each user consented to and when.

GDPRChecker’s scanning capabilities can validate many of these requirements automatically. For example, a scan can detect whether cookies are set before consent, whether the banner appears on all pages, and whether the privacy policy link is reachable. However, some aspects—such as the legal sufficiency of your consent language—require human review.

How to Implement the Osano Migration Checklist Step by Step

A successful migration verification follows a logical sequence. Below, we break the process into five critical areas, each with concrete actions and verification methods.

1. Close the Consent Mode Gap

Google Consent Mode allows you to adjust how Google tags behave based on user consent. After switching CMPs, you must confirm that consent states are being communicated correctly to Google services.

**Verification steps:**

  • Use Google Tag Assistant or the browser’s developer console to check that `gtag('consent', 'default', {...})` is called with the correct default settings before any tags fire.
  • Verify that the consent update call—`gtag('consent', 'update', {...})`—is triggered when the user makes a choice.
  • Test both “Accept All” and “Reject All” flows to ensure that analytics and ads consent states are set to `granted` or `denied` accordingly.
  • Check that Google Analytics 4 (GA4) is receiving consent signals by reviewing the real-time reports for consent state dimensions.

For a deeper dive, see our Google Consent Mode v2 checker guide.

2. Close the Google CMP Gap

If you are using Google’s advertising or analytics services, your CMP must integrate properly with Google’s consent requirements. While GDPRChecker is not a Google Certified CMP and does not issue CMP IDs or generate TC Strings, it can help you verify that your chosen CMP is correctly signaling consent to Google.

**Verification steps:**

  • Confirm that your CMP is passing the `ad_storage` and `analytics_storage` consent signals to Google tags.
  • If you serve ads to users in the European Economic Area (EEA), verify that your CMP supports the required Google consent signals for personalized advertising.
  • Use the GDPRChecker scanner to check for any Google tags that fire before consent is obtained.

3. Close the Cookie Banner Gap

The consent banner is the most visible part of your CMP. After migration, you must test it thoroughly across devices, browsers, and user journeys.

**Verification steps:**

  • Load your website in an incognito/private browsing window to simulate a first-time visitor. Confirm that the banner appears before any non-essential cookies are set.
  • Test the banner on mobile, tablet, and desktop viewports.
  • Verify that the banner is not obscured by other page elements (e.g., chat widgets, pop-ups).
  • Click “Reject All” and use the browser’s developer tools to confirm that no non-essential cookies are present.
  • Click “Accept All” and verify that the expected cookies and trackers are now present.
  • Test the banner’s behavior after page reloads and navigation to ensure it does not reappear unnecessarily.

4. Close the Privacy Policy Gap

Your consent banner must link to a valid, up-to-date privacy policy that accurately describes your data processing activities. After a CMP change, the policy URL in the banner configuration may be outdated or broken.

**Verification steps:**

  • Click the privacy policy link in the consent banner and confirm it leads to the correct page.
  • Review the privacy policy content to ensure it reflects the new CMP and any changes in data processing.
  • Check that the policy includes required disclosures: identity of the data controller, purposes of processing, legal basis, data recipients, retention periods, and data subject rights.
  • Use the GDPRChecker scanner to verify that the policy page is accessible and contains expected keywords.

For more on policy requirements, see our privacy policy requirements guide.

5. Close the DSAR Gap

Data subject access requests (DSARs) are a core GDPR right. While GDPRChecker does not provide DSAR automation or a portal, your CMP migration can affect your ability to respond to DSARs if consent records are lost or inaccessible.

**Verification steps:**

  • Ensure that your new CMP is logging consent choices with timestamps and user identifiers (where applicable).
  • Export a sample of consent records and verify that they contain all necessary fields: consent ID, timestamp, user agent, consent scope, and choices.
  • Confirm that you can retrieve consent records for a specific user if a DSAR is received.
  • Document your process for handling DSARs that involve consent data.

Common Mistakes and How to Avoid Them

Even experienced teams make errors during CMP migrations. Here are the most frequent pitfalls and how to prevent them.

| Mistake | Consequence | Prevention | |---------|-------------|------------| | Leaving old hardcoded tags in place | Tags fire before consent, ignoring CMP signals | Audit all tags and remove any that are not managed through the CMP or a consent-aware tag manager | | Misconfiguring Consent Mode defaults | Google services collect full data until consent is updated | Set `default` to `denied` for all non-essential storage types and test with Tag Assistant | | Forgetting to update the privacy policy link in the banner | Users see a 404 or outdated policy | Verify the link in the CMP configuration and test it after deployment | | Not testing the reject flow thoroughly | Non-essential cookies remain after rejection | Use browser developer tools to check cookies after clicking “Reject All” | | Ignoring regional variations | Banner behavior may differ for EU vs. non-EU visitors | Test with a VPN or geo-spoofing tool to simulate different regions | | Assuming the CMP works on all subdomains | Consent may not be shared across subdomains | Test consent propagation on all subdomains where tags are deployed | | Skipping post-migration scanning | Hidden issues go undetected | Run a GDPRChecker scan immediately after migration and schedule regular follow-ups |

How to Validate with GDPRChecker

GDPRChecker provides a practical way to verify your CMP migration without manual guesswork. Here is how to use it as part of your **Osano migration checklist: what to verify after switching CMPs**:

  1. **Run a full website scan:** Enter your domain and let GDPRChecker crawl your pages. The scan will identify cookies, trackers, and network requests.
  2. **Check pre-consent requests:** Review the scan report for any requests that fired before the consent banner was interacted with. These are flagged as potential compliance issues.
  3. **Verify banner presence:** Confirm that the scan detected your consent banner on all scanned pages.
  4. **Inspect policy links:** The scanner checks whether the privacy policy link in your banner is reachable and returns a valid response.
  5. **Review cookie classifications:** GDPRChecker categorizes detected cookies. Verify that non-essential cookies are not set without consent.
  6. **Test Consent Mode integration:** If you use Google services, the scanner can check for basic Consent Mode signals.
  7. **Schedule recurring scans:** Set up regular scans to catch configuration drift over time.

After addressing any issues found by the scanner, re-scan to confirm that the fixes are effective. This iterative process helps you build a verifiable record of compliance.

Implementation Checklist

Use this numbered checklist to track your post-migration verification. Check off each item as you complete it.

  1. Audit and remove all hardcoded tags that are not managed through the new CMP.
  2. Configure Google Consent Mode with `default` set to `denied` for all non-essential storage types.
  3. Test the consent banner on desktop, mobile, and tablet in incognito mode.
  4. Verify that the “Reject All” button blocks all non-essential cookies and trackers.
  5. Verify that the “Accept All” button allows the expected cookies and trackers.
  6. Confirm that the privacy policy link in the banner is correct and the policy is up to date.
  7. Test consent propagation across all subdomains where tags are deployed.
  8. Use GDPRChecker to scan for pre-consent network requests and cookie leaks.
  9. Review the scanner’s cookie classification report and correct any misclassifications.
  10. Export a sample of consent records and verify their completeness.
  11. Document your migration verification process and scan results for audit readiness.
  12. Schedule recurring GDPRChecker scans to monitor ongoing compliance.

Real-World Examples

Example 1: E-commerce Site Migrating from Osano to a New CMP

An online retailer switched CMPs to gain more granular consent controls. After migration, they ran a GDPRChecker scan and discovered that their Facebook pixel was still firing before consent because it was hardcoded in the site’s header. The team removed the hardcoded pixel and configured it through Google Tag Manager with a consent trigger. A follow-up scan confirmed the issue was resolved.

Example 2: SaaS Company Implementing Osano for the First Time

A B2B SaaS company adopted Osano to manage consent on their marketing website. During verification, they noticed that Google Analytics was collecting full data even when users rejected cookies. Investigation revealed that Consent Mode was not configured. After setting the default consent state to `denied` and updating the CMP to send consent updates, GA4 began respecting user choices.

Example 3: Media Publisher Fixing a Broken Reject Flow

A news publisher found that their “Reject All” button did not remove already-set advertising cookies. The CMP was only blocking new cookies, not clearing existing ones. They worked with their CMP provider to enable the cookie-clearing feature and validated the fix by checking browser storage after rejection.

Comparison: Manual Verification vs. Automated Scanning

| Aspect | Manual Verification | Automated Scanning (GDPRChecker) | |--------|---------------------|-----------------------------------| | **Coverage** | Limited to pages you manually test | Crawls entire site, including deep pages | | **Consistency** | Prone to human error and oversight | Repeatable and consistent | | **Speed** | Time-consuming for large sites | Fast, even for hundreds of pages | | **Pre-consent detection** | Difficult to catch without network monitoring | Automatically flags requests before consent | | **Evidence** | Screenshots and notes | Dated, exportable reports | | **Ongoing monitoring** | Requires manual re-testing | Scheduled scans detect drift |

While manual testing is essential for user experience checks, automated scanning provides the breadth and reliability needed for a defensible compliance program. Combining both methods gives you the most complete picture.

FAQ

What is Osano migration checklist: what to verify after switching CMPs?

It is a structured verification plan that website owners follow after changing their consent management platform to or from Osano. The checklist covers consent defaults, pre-consent network requests, tag manager triggers, policy disclosures, reject-flow testing, and post-change scans to confirm the new CMP is working correctly.

Do I need Osano migration checklist: what to verify after switching CMPs for GDPR?

Yes. Under GDPR, you are responsible for ensuring that your consent mechanism is effective. A CMP migration can introduce gaps that lead to unauthorized data collection. Verifying your setup with a checklist helps you meet accountability obligations and reduces regulatory risk.

How do I implement Osano migration checklist: what to verify after switching CMPs?

Start by auditing all tags, configuring Consent Mode, and testing the banner across devices. Then verify reject and accept flows, check policy links, and confirm consent record logging. Finally, use an automated scanner like GDPRChecker to detect hidden issues such as pre-consent requests.

How can I verify Osano migration checklist: what to verify after switching CMPs with a scanner?

Run a GDPRChecker scan on your domain. The scanner identifies cookies, trackers, and network requests, flagging any that fire before consent. It also checks banner presence, policy link validity, and basic Consent Mode signals. Review the report, fix issues, and re-scan to confirm.

What are common Osano migration checklist: what to verify after switching CMPs mistakes?

Common mistakes include leaving old hardcoded tags in place, misconfiguring Consent Mode defaults, forgetting to update the privacy policy link, not testing the reject flow thoroughly, and skipping post-migration scanning. Each can lead to non-compliance and should be addressed systematically.

Which cookies and trackers should I check for Osano migration checklist: what to verify after switching CMPs?

Check all non-essential cookies and trackers, including analytics, advertising, social media, and any third-party embeds. Essential cookies (e.g., session cookies for login) may be exempt, but you should still verify that they are correctly classified and disclosed in your cookie policy.

How often should I review Osano migration checklist: what to verify after switching CMPs?

Review the checklist immediately after migration and then on a regular schedule—at least quarterly or whenever you make significant changes to your website, tags, or CMP configuration. Regular GDPRChecker scans can help you catch issues between manual reviews.

What evidence should I keep for Osano migration checklist: what to verify after switching CMPs?

Keep dated scan reports, screenshots of banner behavior, consent record exports, and a log of any issues found and remediated. This documentation demonstrates your accountability and can be invaluable if you ever need to respond to a regulatory inquiry.

Conclusion

Migrating your consent management platform is a high-stakes operation that demands careful verification. An **Osano migration checklist: what to verify after switching CMPs** helps you systematically confirm that consent defaults, tag controls, policy links, and consent records are all functioning correctly. By combining manual testing with automated GDPRChecker scans, you can close the gaps that often appear after a CMP change and maintain a strong compliance posture.

Ready to validate your CMP migration? Run a GDPRChecker scan today and get a detailed report on your website’s consent implementation.

Article schema

```json { "@context": "https://schema.org", "@type": "Article", "headline": "Osano Migration Checklist: What to Verify After Switching CMPs", "description": "A practical Osano migration checklist covering consent defaults, pre-consent requests, tag triggers, policy disclosures, and scanner verification steps after switching consent management platforms.", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://www.gdprchecker.online/guides/osano-migration-checklist-what-to-verify-after-switching-cmps" }, "publisher": { "@type": "Organization", "name": "GDPRChecker", "url": "https://www.gdprchecker.online" } } ```

GDPRChecker guides are educational resources and do not constitute legal advice. Use them to understand technical and operational privacy requirements, and consult qualified counsel for legal interpretation.

Check Your Website in Under 60 Seconds

  • No signup required
  • GDPR-focused checks
  • Cookie banner detection
  • Privacy policy verification