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.

The new banner is 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, on timelines those pages typically quote as three to ten days. 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 a dead variable does to a blocking rule

The mechanism is worth understanding rather than memorising. 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.

Switching without the 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. 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 and keeps being evaluated.

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.

Three things that survive a migration and should not

Orphan variable templates. Deleting a vendor's tags does not uninstall its templates. They stay in the container, still evaluated, and are easy to miss because nothing visibly depends on them any more. Remove them alongside 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.

How to 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, and any exception built on a variable reading a cookie no platform writes any more is blocking its tag right now, and 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.

Across Amplio Data client implementations we have measured 34% of sessions hidden by consent, and 20% to 40% of lost conversions recovered once the wiring is correct. Those are measured ranges across Amplio Data client implementations, not a guarantee. A migration done without step six spends that recovery quietly, on tags that are still listed as active.

Velo is often the platform being switched to, so this is self interested advice, and 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.