How to switch consent management platforms without breaking your tracking

All posts

Switch in this order: install the new platform alongside the old one, repoint every consent condition onto the new signal, then remove the old platform last. What breaks a migration is rarely the new banner. It is what the old one leaves behind in your tag manager: variables reading cookies that no longer exist, and the exceptions built on them.

Why is the new banner the easy half?

The migration pages published by consent vendors broadly agree on the sequence: audit, export your consent records, deploy the new script, go live. Those pages typically quote three to ten days for it. That sequence is accurate, and it is the half of the job that announces itself when it goes wrong.

The half nobody writes about is what the departing platform leaves inside the container. A consent tool installed in a tag manager is never one tag. It is a template, variables that read its cookies, triggers listening for its events, and, most consequentially, the exceptions other people built on those variables over the following years. Delete the tag and all of it stays exactly where it is, still enabled, still evaluated on every page load.

What does a dead variable do to a blocking rule?

A variable that reads a consent cookie returns the value of that cookie. Once the platform that wrote it is gone, the cookie is gone, and the variable returns undefined on every page.

Now consider the rule built on it. Blocking conditions are written in the negative: block this tag when the consent variable does not contain the category it needs. Against a real cookie that is false whenever consent was given, and the tag fires. Against undefined it is true. Always, for every visitor, including the ones who accepted everything.

An exception that is always true is a tag that never fires again.

On one live estate we audited after a platform change, four tags had been silently blocked this way, including the primary advertising conversion, for roughly eight months. Nobody had touched those tags. The container was valid, the new banner was working, and the Consent Mode signal was correct. The blocking rules were simply pointing at a platform that had left.

How do you switch platforms without a tracking gap?

1. Inventory what the old platform owns

   Export the container to JSON and search it for the old vendor's name. You are looking for four things, not one: its tag template, the variables that read its cookies, the triggers listening for its events, and every exception built on those variables.

2. Write down which signal gates each tag, now and after

   One row per gated tag: the condition holding it today, and the condition that will hold it once the new platform is in. Do this while the old setup is still live and can be read. It is what lets you verify the switch afterwards.

3. Let the new platform own the defaults

   The new platform goes on Consent Initialization and sets the denied defaults for ad_storage, analytics_storage, ad_user_data and ad_personalization. Google's consent mode guide asks for those defaults before any tag sends measurement data. Retire the old defaults in the same version: two competing default commands is a real risk, not a belt and braces safety net.

4. Rebuild the exceptions before you delete anything

   Every blocking rule built on the old platform's variables gets rewritten against the new consent state first, while the old variables still return real values and you can compare behaviour. This is the step migrations skip, because the exceptions live elsewhere in the container.

5. Delete the old variables and templates last

   Only once nothing references them. A tag manager will tell you what still points at a variable, so work until that list is empty, then remove the variables and the vendor's template. An orphan template stays registered.

6. Verify by what fires, not only by what leaks

   On a fresh profile, reject everything and confirm no advertising or analytics cookies are set. Then accept, and walk your list from step two confirming each tag actually fires. Finally compare this week's conversions against the week before the switch.

The reject side of that verification is worth running properly rather than quickly: the full pre launch sequence is here, and the two reads that confirm the Consent Mode signal are here.

What survives a migration that should not?

Orphan variable templates. Deleting a vendor's tags does not uninstall its templates. They stay in the container, unused but registered, and easy to miss. Remove them with the variables.

All or nothing consent mappings. Older setups often gate everything on a single accepted everything event rather than on categories. If that is what you are migrating, every visitor who accepted some categories and refused others was already invisible, independently of the switch. You are touching every gated tag anyway, so move to per category conditions rather than reproduce the old shape in a new tool.

Scripts that were never in the container. A vendor script pasted straight into the site head was not gated by the old platform either, and the new one will not reach it unless you move it in or wrap it. Whether a given script can move is worth settling one script at a time, and a migration is the natural point to do it.

What happens to the consent visitors already gave?

Plan for visitors to be asked again. A platform reads its own stored decision, so unless the new one is set up to read the old one's cookie, returning visitors see the banner once more after the switch.

Keep the old records. Under Article 7(1) of the GDPR, where processing rests on consent the controller has to be able to demonstrate that the visitor gave it. That duty does not end when the tool that logged it is removed. Export the old platform's consent log before the contract ends, and note the date the new platform took over. What a usable consent record holds is covered here.

How can you tell if this already happened to you?

If you changed platforms in the past and never ran step six, two reads will tell you where you stand.

In the container, search for the previous vendor's name. Anything that returns a result is residue. Any exception built on a variable reading a cookie no platform writes any more is blocking its tag right now. It has been since the day the old tool came out.

In the data, pick your most important conversion and look at a twelve month trend rather than a thirty day one. A silent block does not look like a decline. It looks like a clean step down to near zero on a single date, holding flat afterwards, a shape no audience or market change produces. Check that date against when the platform changed. The other causes of an overnight drop are here; this one is the slowest to be noticed, because the tags that lost their gate are a subset and the total falls without vanishing.

Velo is often the platform being switched to, so this is self interested advice. It is still the advice: the residue belongs to the tool you are leaving, and no new banner can clean it up for you. Budget the container work, not only the install.