Guide · June 17, 2026
Switching from Cookiebot/OneTrust to Vietnam CMP without disruption
Guide to migrate from Cookiebot/OneTrust to a local CMP: move cookie configurations, keep consent history, minimize disruption.
Quick answer
What should you prepare when switching from Cookiebot OneTrust to a Vietnam CMP?
You need to prepare four data sets before changing platforms: the catalog of cookies/tags, your classification policy, stored consent history, and banner display scenarios by language/device. Missing any one of these can break the chain of consent evidence or trigger the wrong tags before a user gives consent.
For Vietnamese businesses, the biggest risk isn’t “whether you have a banner,” but whether the new banner records who consented, when they consented, under which notice version, and for which cookie groups. Under the Personal Data Protection Law (Law 91/2025/QH15), organizations must comply with the principles of personal data processing; when a data breach occurs, the notification deadline is 72 hours from discovery, and the enforcement authority is the Ministry of Public Security (A05).
| Item | Cookiebot/OneTrust | What a local CMP must keep when migrating | |
|---|---|---|---|
| Cookie catalog | Cookie, purpose, duration | Map to equivalent groups, do not change the meaning | |
| Consent log | Timestamp, region, policy version | Export and retain history for reconciliation | |
| Banner UI | Cookie banner, preference center | Keep display logic; only change the interface if needed | |
| Tag firing | Block/allow by category | Re-test each tag before go-live | |
| Audit trail | Evidence of consent | Store policy versions and consent events |
How do you migrate cookie configurations without losing data?
The safest way is to “translate” configurations from the old platform to the new one based on functional equivalence, not copy them verbatim mechanically. Start with the cookie/tag inventory, then create a category mapping table and re-test activation behavior.
Export the inventory from the old platform:
Download the list of cookies, vendors, purposes, retention periods, and consent status. This ensures you don’t miss scripts currently running on your website/app.
Map to the local CMP’s cookie groups:
Consolidate cookies with the same purpose into equivalent groups, e.g., “analytics,” “advertising,” “functional.” Don’t rename groups arbitrarily in ways that change their meaning.
Carry over policy versions and timestamps:
Retain the banner/policy version in effect at the time the user consented. This is what allows consent to be auditable.
Enable pre-consent blocking:
Before go-live, verify that all analytics/ads/remarketing tags are blocked until the user makes a choice.
Run in parallel for a short period:
For 1–2 weeks, keep logging on both sides to reconcile consent events and detect configuration drift.
Finalize the cutover and keep records:
Once stable, lock the old configuration, save the export and the change log to support internal audits or regulatory checks.
How do you preserve consent history when changing CMPs?
You should treat consent history as compliance data, not “auxiliary” data to discard when changing tools. In practice, many companies lose evidence of consent because they only migrate the UI while the consent log remains in the old system and gets deleted early.
The practical approach is to export the entire consent log in a verifiable format, including at minimum: user/session identifier, timestamp, accept/decline status, policy version, source of access, and selected categories. If needed, store a hash or reference code to prevent tampering. For legacy data, you can keep it in a read-only archive; you don’t have to import it into the new system if structures differ—the key is being able to retrieve it when needed.
One important note: if you use cookies for measurement or remarketing, continuing to fire tags after switching CMPs must depend on new consent or existing consent that remains valid under your internal rules and published policy. When uncertain, ask legal counsel to review how you record and retain consent.
How do you avoid disruption when switching platforms?
No disruption means the website/app keeps running, the banner still displays correctly, and tags don’t “leak” during the transition window. To achieve that, don’t change everything at once: banner, policy, tag manager, and logging pipeline.
A practical approach for SMEs is:
- Keep your domain and policy page unchanged in the initial phase.
- Install the new CMP in test/preview mode before enabling production.
- Make a list of critical tags: GA4, Meta Pixel, TikTok Pixel, chat widget, heatmap.
- Test each scenario: user rejects all, accepts only functional, accepts all.
- Monitor issues on mobile, Safari/iOS, and browsers with strict cookie blocking.
If you have multiple sites or subdomains, prioritize a “pilot” domain first. Once stable, replicate the configuration. This reduces the risk of banners showing the wrong language, consent desynchronization across subdomains, or tag firing in the wrong order.
What is the technical checklist for devs when migrating a CMP?
Devs should check five items: script load order, default blocking mechanism, consent update events, log export API, and policy versioning. If the local CMP supports webhooks or APIs, integrate them with your CRM/CDP to store timestamps and consent status.
At a minimum, your release checklist should include:
- The tag manager loads only after the CMP initializes.
- Analytics cookies are blocked before consent.
- “Reject” and “Manage preferences” buttons are clearly visible.
- The consent log captures the banner version.
- A rollback path to the previous configuration if there’s a production issue.
If your organization processes personal data at scale or has cross-border elements, review your process under the Personal Data Protection Law (Law 91/2025/QH15) and seek legal advice before cutover. Serious violations can be criminally prosecuted; specific penalties will be set out in the Government’s implementing decree.
- Not necessarily, but you must export and store the consent log before turning off the old system. Without an export, it will be very hard to prove that prior consent was recorded.
- Often yes, if the policy version, cookie categorization, or the consent storage mechanism changes. The safe approach is to reassess consent validity against your policy and actual configuration.
- It can, if it covers the banner, preference center, logging, APIs, and pre-consent tag blocking. Test it on your website/app—don’t just compare feature lists and pricing.
- When you process sensitive data, involve many third parties, or need to determine consent log retention periods and how policies are published. For any uncertain legal points, seek legal advice.
If you’re deploying consent across multiple websites/apps, consent.vn can help standardize cookie banners, retain consent evidence, and the DSAR flow so the migration doesn’t break your data.
Source: the Personal Data Protection Law (Law 91/2025/QH15), Decree 13/2023/ND-CP, Ministry of Public Security (A05): thuvienphapluat.vn, bocongan.gov.vn
Get started — set up in 5 minutes.
Deploy PDPL solutions for your business?