Migration from Other CMPs

This guide is for site owners moving a website from one consent management platform to another. The actual swap is one script tag out, three tags in (a preconnect hint plus two script tags). The real work is a few minutes of preparation and one decision about your old consent records.

Looking for something else? To update billing details or hand your account to a colleague, use your current provider's admin area, not this guide. If you are a visitor who wants to change a cookie choice on a site you do not run, look for the privacy or cookie settings link in that site's footer.

Jump to your current platform: Cookiebot, OneTrust, CookieYes, Termly, Osano.

Will I lose my consent records when I switch?

Your historical consent log stays with your old provider. Export it before you cancel and keep that file as your audit trail for the period you were on the old platform.

Your visitors' current choices are a separate question, and the answer depends on where you are coming from. If you are leaving Cookiebot, we can turn on consent import for your site, which reads the decision Cookiebot already stored in each visitor's browser and honors it, so people who accepted stay accepted and people who declined stay declined. It is enabled by our team during onboarding, so tell us your previous platform before your cutover. Other platforms are on the roadmap. Without import, ConsentStack starts a fresh log from the day you go live.

That export matters more than the platform you keep it in. If a regulator asks you to evidence consent for a visit that happened last year, what you need is the record of that visit, not the vendor who stored it. A CSV in your own storage answers the question just as well as a dashboard you are still paying for.

From go-live, ConsentStack records every decision with a timestamp and the config version that produced it, viewable in your site dashboard and exportable as CSV. Log retention is 30 days on Pro and 1 year on Business.

Before you start

Take a quick inventory of your current setup. You'll want this information handy when configuring ConsentStack.

• Consent records: Export them from your current provider and store the file somewhere durable. This is the one thing you cannot recreate later.
• Consent categories: List every cookie category your current CMP uses. Note which ones are essential and which are optional.
• Custom integrations: Do you have any scripts that listen for consent events from your current CMP? Note these so you can reconnect them using ConsentStack's JavaScript API.
• Regulation settings: Which regions are you covering? GDPR for Europe, CCPA for California, or others? Write down which consent model (opt-in, opt-out, notice) applies to each region.
• Banner customizations: Note any brand colors, custom text, or layout preferences you've set up. You'll recreate these in ConsentStack's config builder.

This inventory typically takes five to ten minutes and saves time during setup.

Set up ConsentStack

If you haven't already, follow the Quickstart guide to create your account, workspace, and site. Then configure your consent settings to match your current setup:

1. Map your categories: ConsentStack ships with three categories enabled by default: Essential, Analytics, and Marketing. Functional is a standard category too, but it is off until you add it, so switch it on if your current CMP separates preferences or personalization from analytics. Add custom categories if your current CMP uses non-standard groupings. The per-platform tables below give you the mapping.
2. Set up your regions: ConsentStack ships with built-in regions for GDPR, US State Privacy Laws, and a default for everyone else. Review the consent models assigned to each region and adjust if needed to match your current configuration.
3. Customize your banner: Use the config builder to match your brand colors, button styles, and banner text. This is also a good time to improve wording if your current banner language was unclear.
4. Publish your config: Once everything looks right, publish the configuration so it's ready to serve visitors.

The swap

This is the easy part. You're replacing one line of code with another.

Remove your old CMP script tag. Find the script tag for your current provider in your site's <head> and delete it. It looks something like:

Add the ConsentStack tags. Paste these in the same location, replacing <YOUR_SITE_KEY> with your site key from the dashboard:

<link rel="preconnect" href="https://cdn.consentstack.io" />
<script src="https://cdn.consentstack.io/consent.js?k=<YOUR_SITE_KEY>"></script>
<script src="https://cdn.consentstack.io/consent-core.js?k=<YOUR_SITE_KEY>"></script>

Deploy your site. That's the entire swap.

If your old CMP was installed through a plugin or an app rather than pasted into your theme, removing the tag is not enough. Deactivate the plugin too, or it will keep injecting the old script on the next page build.

What to expect after switching

By default, returning visitors will see the consent banner again. ConsentStack uses its own consent storage, so unless consent import is switched on it does not read the cookie your old CMP set, and every visitor starts fresh.

That default is fine for compliance. Fresh consent means your visitors are making informed decisions based on your current banner, not a choice they made months ago under different wording or categories. Auditors and regulators view re-consent favorably, and after a few days the vast majority of your traffic will have provided fresh consent through ConsentStack.

If you are migrating from Cookiebot, you can skip the re-prompt. With consent import enabled, returning visitors who made an explicit choice under Cookiebot keep it, the banner stays hidden for them, and the original decision is written into your ConsentStack log with the old consent ID and timestamp attached. Ask us to switch it on before you cut over.

Verify your migration

Once the new script tags are live, confirm everything is working:

1. Check the banner: Open your site in a browser (or an incognito window). You should see the ConsentStack banner appear.
2. Scan the live site: Run your URL through the free cookie checker to see which trackers fire before consent. This is the fastest way to catch a leftover tag from your old CMP.
3. Review consent logs: Head to your site dashboard and check that consent decisions are being recorded.
4. Enable debug mode: Add data-debug="true" to the core script tag temporarily to see detailed console output about category resolution, script blocking, and consent state.
5. Test across regions: If you have a VPN, test from different locations to verify the correct consent model appears for each region.

For a complete verification walkthrough, see the Testing & Verification guide.

Migrating from Cookiebot

Remove: the script referencing consent.cookiebot.com, plus the WordPress plugin if you installed it that way. Cookiebot also loads a hidden consentcdn.cookiebot.com frame, which disappears with the main tag.

Map your categories:

Watch for inert script tags. If you ran Cookiebot in auto-blocking mode, it rewrote your third-party tags in place, changing src to data-cookieblock-src and type to text/plain so the browser would skip them. Those rewrites can persist in cached pages, in templates a developer hand-edited to match, and in any tag you copied from a Cookiebot support article. A tag left in that state stays dead after Cookiebot is gone, so a script you expect to fire silently never does. Our teardown of how script blocking works decodes the full attribute set and its ConsentStack equivalent.

If you were relying on Cookiebot's auto-scan, ConsentStack's built-in script blocking with 900+ known tracker patterns provides equivalent coverage, with no tag rewriting on your pages. Side-by-side detail is on the Cookiebot comparison.

Migrating from OneTrust

Remove: the script referencing cdn.cookielaw.org (EU accounts use eu1.cdn.cookielaw.org), and any OptanonWrapper function you defined in your own code.

Map your categories:

Rewire your custom code. OneTrust integrations tend to accumulate references to OnetrustActiveGroups, the OptanonConsent cookie, and the OptanonWrapper callback. Search your codebase and your tag manager for those three names, then reconnect each one to ConsentStack's JavaScript API. Anything you miss will read a cookie that no longer exists and quietly behave as if consent was never given.

Category IDs are the other thing to check. OneTrust setups often carry custom groups beyond C0005, and those need a matching ConsentStack category before you publish. See the OneTrust comparison for a feature-level view.

Migrating from CookieYes

Remove: the script referencing cdn-cookieyes.com or cdn.cookieyes.com. If you installed CookieYes as a WordPress plugin, deactivate the plugin as well. Deleting the tag alone leaves the plugin free to re-inject it.

Map your categories:

Two categories collapse into one. CookieYes splits Analytics and Performance, and most sites end up using them for the same class of tracker. Merging both into ConsentStack's Analytics is usually right. If you genuinely gave visitors a separate choice for each, create a custom category so nobody's earlier preference gets widened by the move.

Export your consent records before you cancel. CookieYes offers a CSV export of consent logs from the dashboard, and that file is your audit trail for the period before the switch. The CookieYes comparison covers the rest of the differences.

Migrating from Termly

Remove: the script referencing app.termly.io, including the resource blocker tag if you use Termly's Auto Blocker.

Map your categories:

Check whether you have records to export at all. Termly gates consent logs to its Pro tier and above. On the Free and Starter plans there is no consent log to take with you, so your audit trail effectively begins the day you go live on ConsentStack. Worth knowing before you tell an auditor otherwise.

Deal with Unclassified before you publish. Termly's scanner leaves cookies it cannot identify in an Unclassified bucket, and sites often let that bucket sit for months. Do not carry it across. Assign each cookie to a real category, because an unassigned tracker on a GDPR page is the exact thing an enforcement action looks for. The Termly comparison has more.

Migrating from Osano

Remove: the script referencing cmp.osano.com.

Map your categories:

Two of those are not really categories. Osano's Opt-Out and Storage switches belong to IAB frameworks rather than to your cookie taxonomy. Opt-Out is the "Do Not Sell or Share" control that US state laws require, which ConsentStack expresses as the consent model on your US State Privacy Laws region. Storage only applies if you enabled TCF. Neither needs a ConsentStack category.

You may have nothing to export. Osano's free tier does not include consent storage, so if you were on it, there are no historical records to move. Paid plans do store consent, and you should pull that export before the subscription lapses. See the Osano comparison for the wider picture.

What's next

• Testing & Verification guide. Confirm your migration is working correctly.
• Categories & Regions. Fine-tune your consent rules.
• How script blocking works. Decode the blocking attributes your old CMP left behind.
• Dashboard guide. Explore banner customization and consent logs.