Migrating from CookieYes to CookieScript: A Step-by-Step Guide

Why CMP Migration is More Than Replacing a Banner

A Cookie Banner is only the visible part of a Consent Management Platform (CMP). The important behaviour happens underneath it.

A site can display the new banner perfectly while GA4 fires too early, Meta Pixel remains blocked after consent, or an old GTM variable still controls tags.

Before changing anything, identify what CookieYes currently controls. Then decide how each function should be handled after the switch.

CookieScript needs its own banner settings, cookie categories, scan results, blocking rules, GTM setup and Consent Mode setup.

Before Migrating: Audit Your CookieYes Setup

Start with the current production deployment. Find every location from which CookieYes is loaded.

That may include the site <head>, GTM, a WordPress or other CMS plugin, theme code, a header-injection tool or custom frontend code. CookieYes supports both manual website installation and GTM installation, so checking only one location may leave part of the old CMP active.

Record what actually depends on CookieYes:

installation method and every installation point;
current cookie categories and manually added cookies;
automatic or manual blocking rules and Script URL Patterns;
GTM tags, variables, triggers and custom events;
Basic or Advanced Google Consent Mode;
regional and language settings;
banner wording, buttons, policy links and custom CSS;
consent revisit or withdrawal controls;
embedded video, advertising, analytics, chat and other third-party services.

CookieYes also provides consent revisit controls and configurable consent expiry. If those features are part of the current deployment, record their settings before making changes.

This audit is particularly important on older sites. A site may have CookieYes installed through GTM while still containing a hard-coded CookieYes script left from an earlier deployment. Removing only the GTM tag would not complete the switch.

Export Records and Document the Old Configuration

Save the old records before cancelling the CookieYes account.

CookieYes's Consent Log can be exported as CSV for a selected date range. Depending on the plan and record, the available information can include the Consent ID, consent status, date and time, Proof of Consent and country information.

Where relevant, save Proof of Consent records as well.

Where personal-data processing relies on consent, those records can also have a regulatory purpose. Under Article 7(1) of the General Data Protection Regulation (GDPR), a controller relying on consent must be able to demonstrate that the data subject consented. Preserve the records relevant to your organisation's applicable requirements rather than assuming the new CMP replaces historical evidence.

Preserve the CookieYes exports as a separate historical archive before cutover. Once consent recording is enabled in CookieScript, new consent choices can be recorded and downloaded from the new setup.

Keep three separate concepts clear:

Historical consent records are evidence of choices previously recorded by CookieYes.

Browser-side consent state is the active preference stored for a particular visitor.

New consent collection is what CookieScript begins managing after cutover.

Save settings that cannot be exported easily as well. Screenshots of the banner and preference centre, category settings, custom text, CSS, GTM setup, blocking patterns and regional settings can all be useful during rebuilding and troubleshooting.

Create and Configure your CookieScript Banner

Set up CookieScript before removing CookieYes.

Create the new cookie banner, reproduce the required wording and design, set up preference controls and policy links, and add the languages and regional behaviour the site needs.

CookieScript supports multilingual banners and several language-selection methods. If the old banner uses customised translations, record those rather than assuming the same wording will appear automatically.

The same principle applies to visual customisation. Recreate the intended appearance using CookieScript's banner settings and supported customisation options rather than copying CookieYes-specific CSS selectors.

If the current site includes custom JavaScript, callbacks or consent events, treat those as a separate integration task. CookieScript has its own functions and consent events; old CookieYes-specific function names or state variables should not simply be renamed and reused.

Regional setups require particular care because the applicable rules can differ by jurisdiction. Relevant examples include:

European Union (EU): website tracking may engage the GDPR where personal data is processed, alongside the ePrivacy Directive rules governing storage of, or access to, information on users' devices.
United Kingdom (UK): the Privacy and Electronic Communications Regulations (PECR) apply to relevant storage and access technologies such as cookies, while the UK GDPR also applies where their use involves processing personal data.
United States (US): requirements vary by state. The California Consumer Privacy Act (CCPA), for example, includes requirements concerning opt-out preference signals.
Canada: the Personal Information Protection and Electronic Documents Act (PIPEDA) sets federal rules for how covered private-sector organisations collect, use and disclose Personal Information in the course of commercial activities.
China: the Personal Information Protection Law (PIPL) can apply where website tracking involves the processing of Personal Information, including requirements around consent and its withdrawal.

With geo-targeting, the site can present different consent behaviour according to location. Geo-targeted CookieScript code must be installed directly in the website <head> rather than through GTM. Global or non-geo-targeted CookieScript code can be installed through GTM.

Map CookieYes Categories to Your CookieScript Setup

Do not migrate cookie categories by matching labels alone.

CookieYes uses categories including Necessary, Functional, Analytics, Performance, Advertisement and Uncategorized. CookieScript uses Strictly Necessary, Functionality, Performance, Marketing and Unclassified.

Some names look similar, but that does not create an automatic migration rule.

An Analytics cookie in the old CMP, for instance, should not be moved into a CookieScript category solely because one label appears to be the closest match. Review what the tracker actually does, which vendor sets it and how that technology is intended to be controlled.

The new classification should reflect the site's current tracking behaviour and CookieScript's cookie category structure.

This is also a useful point to find classifications that are no longer accurate. A cookie may have changed purpose, an integration may have been removed, or an old manually entered item may no longer exist.

Run a Fresh Cookie Scan

Run a new Cookie Scanner scan rather than copying the existing CookieYes cookie list and treating it as authoritative.

Several things may have changed since the old scan:

trackers or vendors may have changed;
cookies may have been renamed or removed;
new third-party services may have appeared;
manually entered entries may be stale;
some trackers may only appear on certain pages;
the category structure now being used is different.

After scanning, review the detected cookies, domains, descriptions, durations, categories and unclassified entries where relevant. CookieScript also allows cookie information to be reviewed and adjusted where required.

Some technologies appear only during checkout, after login, after opening a video, following an interaction or on a particular landing page. Compare the scan with what actually happens in the browser.

The site's cookie declaration may need updating at this point as well. If a CookieYes-generated cookie table is still embedded in the website, do not leave it indefinitely as the apparent source of truth after CookieScript becomes the active CMP.

Rebuild Script Blocking and GTM Rules

Existing CookieYes blocking rules do not become CookieScript blocking rules automatically.

CookieYes may currently control scripts through automatic blocking, manual blocking, Script URL Patterns, GTM conditions or a mixture of those methods. Record the current behaviour first, then decide which mechanism should control each tracker after cutover.

CookieScript supports script blocking, including automatic and manual approaches. GTM can also control consent-aware tags.

Avoid creating two independent blocking layers for the same script. A GA4 or advertising tag might already be waiting for an appropriate GTM consent condition; if CookieScript is also independently preventing that same script from loading, troubleshooting becomes harder because either mechanism may be responsible for the result.

Open the GTM container and identify:

CookieYes CMP tags;
consent-initialisation triggers;
CookieYes-specific variables;
category-based conditions;
manually blocked tags;
custom consent events;
default consent-state code.

Remove or replace only the CookieYes-specific parts that are no longer required. Do not delete unrelated analytics, advertising or ecommerce tags.

CookieScript provides Google Tag Manager integration, including consent-related events and state information that can be used when setting up GTM.

Migrate Google Consent Mode v2 Correctly

Google Consent Mode needs to be rebuilt separately.

First establish how CookieYes currently handles it. Determine whether the site uses Basic or Advanced Consent Mode, whether CookieYes is installed through GTM, whether gtag.js is also configured directly, and whether any default consent commands exist outside the CMP.

Then rebuild the intended setup with CookieScript.

For GTM installations, CookieScript provides a dedicated Google Consent Mode v2 setup. The CookieScript GTM template should load on the appropriate Consent Initialization trigger so the consent state is available at the correct point in the tag lifecycle.

Use one intended CookieScript installation method. Do not unintentionally install the same banner directly in the site and through GTM at the same time.

Google Consent Mode works with signals including:

analytics_storage
ad_storage
ad_user_data
ad_personalization

Google distinguishes Basic and Advanced implementations. With Basic Consent Mode, Google tags are prevented from loading until the relevant consent is granted. In Advanced Consent Mode, Google tags can load with denied defaults and adjust their behaviour when the consent state changes.

Follow Google's Consent Mode documentation when deciding which mode is appropriate.

Consent Mode does not replace consent controls for non-Google technologies such as Meta Pixel, Microsoft tags, chat tools, affiliate scripts or embedded video.

Even if Consent Mode worked correctly before, test it again once CookieScript becomes the active CMP.

Test CookieScript Before Removing CookieYes

Test the new setup in staging or another controlled environment where practical.

Then test production again after cutover. A staging site may use a different hostname, GTM container, CDN setup, checkout flow, geo-targeting result or collection of third-party integrations.

Work through the main consent states rather than checking only whether the banner appears.

First visit: confirm the correct banner, language and regional settings. Check that only the expected technologies run before the visitor makes a choice.
Reject all: inspect cookies, network requests and GTM behaviour. Non-essential technologies should remain controlled according to the setup.
Accept all: confirm that permitted analytics, advertising and other scripts can load.
Category-level choice: enable selected categories only and verify that the relevant trackers respond accordingly.
Change or withdraw consent: reopen the preference controls, alter the selection and check that the new state is applied.
Reload and navigate: confirm that the preference persists as intended.
Private browsing: repeat the first-visit test without an existing stored preference.
Mobile and major browsers: check the banner, preference centre, scrolling and consent-changing flow.
Regional variants: where geo-targeting is used, verify the intended regional versions separately.

Browser DevTools are useful here. Inspect cookies, local storage, loaded scripts, network requests and console errors where relevant rather than relying only on what the CMP dashboard displays.

For Google tags, use Tag Assistant to inspect consent defaults, updates and timing.

Cut Over from CookieYes to CookieScript

Once the new setup has passed controlled testing, make the production change deliberately.

Preserve the CookieYes consent records and settings you need.
Save or version the current GTM container.
Prepare the tested CookieScript setup.
Remove or deactivate CookieYes at the production installation points.
Remove obsolete CookieYes GTM tags, variables, triggers and custom integration code where applicable.
Activate the intended CookieScript installation.
Remove obsolete CookieYes-generated preference controls or cookie declarations.
Clear relevant CMS, page, CDN and browser caches.
Test the live site immediately.
Run another scan where appropriate and update the site's cookie declaration.

Do not leave CookieYes and CookieScript operating as two independent CMPs over the same consent layer as the normal production architecture.

Two banners are the obvious problem. Less visible conflicts can include two sets of blocking rules, competing Consent Mode commands, a script released by one system but still blocked by the other, or old CookieYes variables continuing to influence GTM.

A controlled cutover may briefly involve both systems in some architectures. Test that overlap carefully and remove the old consent layer once the new one is active.

Post-Migration Checks

Capture a baseline before cutover where practical. Useful reference points include GA4 traffic, important conversions, consent rate, known cookies and expected GTM behaviour.

Then watch the live site after launch.

Unexpected changes in analytics or advertising data deserve investigation, but they do not automatically mean CookieScript is malfunctioning. A difference might be caused by changed consent choices, corrected blocking, category changes, Consent Mode settings, obsolete CookieYes code or a tag that no longer fires when it should. It may also mean tracking that previously ran before consent is now correctly controlled.

If CookieYes still appears after removal, inspect what the site is actually delivering. Old CMP code can survive in GTM, a CMS plugin, a theme file, cached HTML or CDN output.

Managing Consent with CookieScript After Migration

Removing the old CMP is only part of the job. Once CookieYes has been removed, the wider cookie consent setup still needs to cover what loads outside Google, how visitor choices are stored, how those choices affect third-party technologies and what happens when a visitor later changes or withdraws consent.

CookieScript is a Consent Management Platform (CMP) that Google includes among the CMP partners available for Consent Mode setup. CookieScript is also a Google-certified CMP with Gold tier status.

Depending on your plan and setup, relevant tools include:

a customisable cookie banner and automatic third-party script and cookie blocking, so the new consent choices can control advertising, analytics and other tracking technologies outside Google;
cookie scanning and automatic monthly scans, helping keep the cookie inventory current after the initial scan and surface tracking technologies added later;
visitor consent recording, providing records of the choices collected through CookieScript after cutover. Historical CookieYes consent records should remain separately retained where needed;
support for Global Privacy Control (GPC) and IAB TCF 2.3 where those requirements are relevant to the site's consent setup;
cross-domain and subdomain consent sharing for suitable multi-site setups;
integrations for platforms including Wix, Shopify and Webflow, plus the CookieScript API for more customised deployments;
cookie banner sharing for organisations managing consent across multiple CookieScript accounts; and
a Cookie Policy and Privacy Policy Generator for the disclosure side of the wider privacy setup.

CookieScript also provides a 14-day free trial of its Plus plan without requiring a credit card.

Conclusion

A successful CMP migration preserves the records that need to be retained, rebuilds consent enforcement around the new platform and removes the old implementation cleanly.

Do not judge the result by whether the new banner appears. Test consent state, browser requests, blocking behaviour, GTM, Google Consent Mode and the visitor's ability to change their choice. Only after those checks pass should the CookieYes implementation be considered fully retired.

Frequently Asked Questions

Can I transfer my existing CookieYes consent records to CookieScript?

Export your CookieYes Consent Log before closing the old account and retain the records separately where required. Preserve those historical records as a separate archive. After cutover, CookieScript can begin recording new consent activity according to the new setup and plan. Historical CookieYes evidence and new CookieScript consent records should therefore be treated as separate datasets.

Will users have to consent again after switching from CookieYes?

Do not plan the cutover on the assumption that an existing CookieYes browser-side preference will carry over. Test first-visit and returning-visitor behaviour after CookieScript becomes active and decide how the new consent state should be handled. Changing CMP provider alone should not be presented as a universal legal requirement to collect consent again.

Can CookieYes and CookieScript run at the same time?

Only during a carefully controlled cutover if the deployment genuinely requires temporary overlap. Leaving both CMPs independently managing the same production consent layer can create duplicate banners, blocking conflicts, duplicated controls and competing Consent Mode behaviour. The final implementation should have one clearly defined consent-management layer.

Do CookieYes cookie categories map directly to CookieScript categories?

No. Similar names do not make the categories interchangeable. Review what each cookie or tracker actually does and classify it according to CookieScript's current cookie categories. The migration is also an opportunity to correct stale or inaccurate classifications from the previous setup.

Do I need to rescan my website after moving to CookieScript?

Run a new Cookie Scanner scan. The old CookieYes inventory may contain stale information, and trackers may have changed since the last scan. Compare the results with real browser behaviour and important site workflows rather than assuming the scan represents every tracker on the site.

What happens to Google Consent Mode when I remove CookieYes?

Consent Mode needs to be configured for the new CookieScript implementation. Review the old CookieYes setup first, then configure CookieScript's Google Consent Mode v2 integration and test the default and updated consent states. Do not assume previous GTM tags, consent defaults or CookieYes-specific variables continue to provide the correct behaviour after CookieYes is removed.

How do I know CookieYes has been completely removed?

Check every location identified during the pre-migration audit. Inspect the site source, GTM container, CMS or plugins, theme or template code, header-injection tools and browser network activity. Clear relevant caches as well.

Should I delete my CookieYes account immediately after migration?

No. First preserve the historical consent records and old configuration information you need. Complete the production cutover, verify CookieScript's behaviour, confirm that the old CookieYes implementation is no longer being delivered and determine which historical records still need to be retained. Only then should the old account be considered for closure.

Guides

Menu