Every consent platform stores its decision in its own cookie, under its own name, in its own format. A new platform that does not go looking for the old cookie sees a visitor who has never chosen anything, and shows the banner. That is why the standard answer to this question is “everyone gets asked again”. It is a fact about how the software is built, not a rule anybody imposed.
It is also not universal, and the vendors who do solve it mostly do not say so where a buyer evaluating a switch would find it. So we read the documentation, one vendor at a time, and wrote down what each one commits to in its own words.
Disclosure: ConsentStack is one of the platforms in this table, and we are not the only one that carries consent over. CleanCMP does it too and says so plainly. Every row below links to the vendor page it was read from on September 7, 2026, so you can check any claim here against the source, including ours.
“Migrating consent” means two different things
Most confusion about this comes from one word covering two unrelated capabilities. Vendors answer whichever one they are good at, and buyers hear an answer to the one they asked.
This is a browser question. It happens on the visitor's next page load, and it decides whether they see a banner they have already dismissed. Solving it means reading the old platform's cookie and honoring what it says.
This is an audit question, and on most platforms the answer is no. Your log is the evidence for the period you were on the old platform, and it usually stays there. Whichever platform you are moving to, export your records before you cancel: most providers cut off dashboard access at the end of the billing period, and that export is the only thing anyone can migrate. If a regulator asks you to evidence a visit from last year, what you need is the record of that visit, not the vendor who stored it.
Didomi is the clearest example of the mix-up. Its migration page makes a strong records claim, and AI assistants summarizing it will tell you Didomi “carries consent over”. Read the page and there is no statement anywhere about whether a returning visitor sees the banner. Both things are called consent migration. Only one of them stops the re-prompt.
What each platform actually does
Read from each vendor's own live documentation on September 7, 2026. “Not documented” means we could not find a public statement either way, which is not the same as a capability being absent. Enterprise platforms in particular keep implementation documentation behind a customer login.
| Platform | Visitors keep their choice | Your consent log moves |
|---|---|---|
| ConsentStack | Yes | Yes |
| CleanCMP | Yes | Not documented |
| iubenda | Only if you build it | Not documented |
| Didomi | Not documented | Yes |
| CookieScript | No | No |
| Usercentrics | No | Not documented |
| Consentify | No | Not documented |
| Cookiebot | Not documented | Not documented |
| OneTrust | Not documented | Not documented |
We also checked Osano, CookieYes, Termly and found no public statement in either direction, so they are left off the table rather than marked with a guess.
The evidence, platform by platform
Why each platform sits where it does, and the wording we read it from.
ConsentStack
Our consent import documentationThe only platform here that does both, and the only one that does the work for you. We build the connector for whichever platform you are leaving, so your returning visitors keep the choice they already made, and we move your historical consent log across during onboarding. You do not configure it or write anything. The one step only you can take is pulling the export from your old provider before you cancel, and we tell you exactly what to click. Carried-over decisions arrive in the log with their original consent ID, timestamp and region attached.
CleanCMP
cleancmp.comShips visitor carryover as a built-in feature and publishes it plainly, in wording close to our own. Nothing published about moving a historical log.
“Read a previous CMP cookie once and migrate clear choices into CleanCMP without forcing returning visitors through a new prompt.”
iubenda
iubenda help centerDocuments the technique but leaves the work to you. The guide is generic, names no previous platform, and the sample code arrives with an instruction not to reuse it. Nothing published about moving a historical log.
“Don't copy and paste the code shown above, it's just sample code we've provided to help you understand the approach.”
Didomi
didomi.io migration pageThe clearest case of the mix-up: strong claims about records, silence about the banner. Nothing on the page says whether a returning visitor is asked again. Sales-assisted, run as a managed migration rather than a setting you switch on.
“Your consent audit history exports and transfers in full.”
Usercentrics
Usercentrics migration pageAssumes the banner comes back, and tells you to clear your cache so that it does. Nothing published about moving a historical log.
“For websites, clear the cache to ensure the new consent banner is now displayed to visitors.”
Consentify
Consentify migration pageIts one-command migration removes your old tag and wires up the new banner. It moves your setup, not your visitors' decisions.
OneTrust
OneTrust developer documentationDocuments migrating a visitor's stored consent from OneTrust's own legacy SDK into its current one. Nothing published covers reading a competitor's cookie.
The most telling row is OneTrust's. Their developer documentation describes migrating a visitor's stored consent from OneTrust's own legacy SDK into its current one, which is precisely this technique, pointed inward. The mechanism is not exotic and the largest vendor in the category already ships it. What almost nobody does is aim it at a competitor's cookie, because the work only pays off for the vendor a customer is arriving at.
What to ask, if a vendor tells you they can do it
“We can import your consent” covers implementations that behave very differently once a real visitor loads a real page. Four questions separate them:
If the decision is applied after the page has begun loading scripts, a visitor who rejected tracking has already been tracked by the time their rejection is honored. The import has to resolve in the same step that decides whether a script may run.
An import that carries acceptances and re-prompts everyone else converts every rejection into a fresh chance to ask. That is a consent reset wearing a migration label, and it is worse than re-prompting everybody equally.
Some platforms record a visitor who merely kept scrolling as having consented. Importing those records as explicit decisions manufactures consent that was never given. They should be ignored, and those visitors shown your banner.
A carried-over decision that lands in the new log with today's date, as though the visitor chose it on migration day, is worth less than one that keeps the original consent ID, timestamp and region. The first version quietly rewrites your audit trail. The second one is the audit trail.
Where we stand
We do the migration for you. Not a feature you configure, not a recipe you follow: you tell us what you are on now, and we move you, including both halves of the question this page is about. Everyone else on this page hands you a capability. We hand you a finished migration.
Your visitors keep the choice they already made. We build the connector for whichever platform you are leaving, and we build it before your cutover rather than adding you to a roadmap. Cookiebot is running in production today. On the first page load after you switch, before any tracking script runs, the SDK reads the consent cookie your previous platform wrote on your own domain, maps the categories, applies them, and shows no banner. Declines carry over exactly as faithfully as acceptances. Implied consent, malformed records and records older than your consent lifetime are ignored, and those visitors see your banner as normal. Each carried-over decision lands in your log with its original consent ID, timestamp and region attached.
Your consent history comes with you. We move your historical log across during onboarding. On most platforms this is where you archive a CSV and hope you can still read it in two years. With us your evidence from before the switch sits in the same place as everything after it, in one continuous record. The one thing only you can do is pull the export from your old provider before you cancel, because we cannot log into their dashboard on your behalf. We will tell you exactly what to click, and we take it from there.
That combination is why we are the only platform in the table above answering yes to both questions. There is one genuine limit on the visitor half, and it is technical rather than commercial: your old platform has to leave its decision somewhere readable in the visitor's own browser. Nearly all of them do, because a consent banner that cannot remember its own visitors would be unusable. If yours turns out to be an exception, we will tell you before you switch rather than after.
What we will not claim is that we are the only platform that carries visitor consent over. CleanCMP ships that capability and publishes it, and a buyer who opens both sites should find our description and theirs equally honest. The difference is who does the work. The four questions above are the ones worth putting to either of us.
One more thing worth saying plainly, because it cuts against our own feature: being re-prompted is not a compliance failure. A fresh decision under your current banner and categories is the strongest consent you can hold, and starting clean is always defensible. Carrying consent over is a business decision. It saves your returning visitors an interruption they have already answered, and it avoids the analytics cliff that follows a site-wide re-prompt. If you would rather start fresh, say so and we will leave it off.
The full step-by-step for leaving each major platform, including category mappings and the tags to remove, is in our migration guide, and the mechanics of the import itself are documented in consent import.
We check vendor claims the same way we check our own.
We ran twelve cookie scanners against a site broken on purpose and published what each one caught. Only one found the tracker that fires after a visitor clicks Reject.
Questions
On most platforms, yes. Each platform stores consent in its own cookie under its own name, so a new platform that does not go looking for the old cookie sees a visitor who has never made a choice, and shows the banner. It is not a legal requirement, it is a consequence of how the software is built. A small number of platforms do read the previous cookie and honor the decision in it, and on those your returning visitors are not re-prompted.
No, and that is worth being clear about. Asking again is always safe: a fresh, informed decision under your current banner and categories is the strongest consent you can hold. Carrying consent over is a business decision rather than a compliance one. What it saves you is the interruption to every returning visitor, and the drop in measurable analytics traffic that follows a site-wide re-prompt.
On most platforms it does not, and this is a different question from whether your visitors are re-prompted. Your historical log is your audit trail for the period you were on the old platform, and it usually stays with that platform. Two platforms here move it: Didomi as a managed enterprise migration, and ConsentStack, where we do the migration for you during onboarding so your evidence from before the switch sits alongside everything after it. Either way, pull your export from your old provider before you cancel, because most of them cut off dashboard access at the end of the billing period and that export is what gets migrated.
Checked against each vendor's own live documentation in September 2026: ConsentStack and CleanCMP both ship it as a built-in feature, and iubenda documents a do-it-yourself recipe where you write the code that reads the old cookie. Didomi transfers consent records for enterprise accounts but publishes no claim about the banner. CookieScript and Usercentrics both tell you, in their own migration material, to expect visitors to be asked again.
Yes, and we build it for you. We write a migration connector for whichever platform you are leaving, before your cutover rather than putting you on a roadmap. Cookiebot is built and running in production today. For any other platform the work is a reader for that vendor's consent cookie, a small and well-defined piece of the SDK, because the import system was designed as one connector per platform from the start. Nothing is asked of your developers. Tell us what you are migrating from and we handle it. The one real limit is technical rather than commercial: your previous platform has to store its decision somewhere readable in the visitor's own browser. Almost all of them do.
On the first page load after your cutover, before any tracking script runs, the SDK looks for the consent cookie your previous platform wrote on your own domain. If it finds an explicit, unexpired decision, it maps the categories and applies them, so no banner is shown. That decision is then written into your ConsentStack log with the original consent ID, timestamp and region attached, which keeps your audit trail continuous after you cancel the old vendor. Only explicit decisions are imported. Implied consent, malformed records and records older than your consent lifetime are ignored, and those visitors see your banner as normal.
Both, and a platform that imports only acceptances would be the wrong thing to buy. A visitor who rejected tracking under your previous platform stays rejected under ConsentStack, with no re-prompt and no quiet reset to a permissive default. Importing only the acceptances would convert every rejection into a fresh chance to ask, which is the behavior consent rules exist to prevent.