Consent Records When Your Store Rebrands or Changes Domain

A rebrand renames the store and often moves the domain. Your consent records, and the choices shoppers already made, need a plan for the move.

Rebrands are planned for months around design, redirects, and search rankings. The consent records rarely make the plan, and they should, because a domain change is one of the few events that can orphan them. The records name the old store and domain, the consent cookies live under the old domain, and the new store opens its doors unable to prove what millions of past choices were or to honor them.

Nothing about this is hard to handle if it is in the migration checklist. Left out, it surfaces later as a compliance question nobody can answer cleanly. This guide covers what a rebrand does to consent records, what carries over, and the decisions to document before launch day.

What a domain change actually breaks

Two separate things. First, the records: your consent log documents choices made at a named site under a named privacy notice. A rebrand usually updates the notice, the store name, and the domain at once, so the historical records now reference documents and an identity that no longer exist at those addresses. The records are not invalid, but their chain of meaning needs a bridge: what the old name became, when, and under which notice versions.

Second, the live choices. Consent cookies are domain bound. A returning shopper's carefully recorded choice under the old domain does not exist under the new one, so the new store asks again, which is correct behavior and also a visible annoyance if the migration was supposed to feel seamless. Expect it, and do not try to engineer around it by importing state you cannot verify.

Keep the historical records readable

Preserve the pre rebrand records intact and add a mapping document, not edits: old store name, old domain, old privacy notice versions with their dates, the new identity, and the date the change took effect. An auditor or a counsel reviewing a two year old choice should be able to follow the chain from the record to the notice that governed it in under five minutes.

Archive the old notice versions themselves, not just their dates. Notices get overwritten in content systems during rebrands precisely because everyone is updating everything. A record that points to 'privacy notice version 6' is evidence only if version 6 still exists somewhere retrievable. Export it before the migration, while someone still knows where it lives.

Decide how the new store asks

The new domain starts with an empty consent state for everyone, including your most loyal returning shoppers. Decide how the new store handles that first visit: a straightforward fresh ask is the honest default. Resist the temptation to treat an old domain choice as carried over, since the shopper made it at a differently named store under a different notice, and your records could not prove the mapping for an individual anyway.

Communicate it plainly where it helps. A short line in the rebrand announcement, 'you may be asked about cookies again on our new site', costs nothing and converts a suspicious looking re-ask into an expected part of the move. Shoppers forgive administration they were told about.

Put consent in the migration checklist

The checklist items are small and specific: export and archive historical consent records and notice versions, write the identity mapping document, configure consent tooling on the new domain before launch with the new notice linked, brief whoever answers privacy questions on the re-ask, and verify after launch that new records are being written correctly under the new identity.

Add a post launch audit a month later: sample new records, confirm the fields and notice references are the new ones, and confirm the old records remain retrievable. Migrations declare victory at launch; records problems declare themselves at the first serious question, months later, when the migration team has scattered. The one month check is cheap insurance against that timing.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: Consent Records for Phone and Chat Orders, What to Keep When a Consent Tool Contract Ends, and Cookiebot Alternatives Compared Side by Side.

Frequently asked questions

Are consent records from before a rebrand still valid evidence?

Yes, if their chain of meaning is preserved: the records themselves kept intact, the old privacy notice versions archived, and a mapping document connecting old name, domain, and notices to the new identity with dates. What breaks records is not the rebrand; it is losing the documents the records refer to.

Can we carry shoppers' consent choices to the new domain?

Not reliably or provably. Consent cookies are domain bound, and a choice made at a differently named store under a different notice should not be silently imported as if nothing changed. The honest pattern is a fresh ask on the new domain, explained in the rebrand communications so it does not surprise anyone.

What should we archive before the migration?

The full historical consent records, every prior privacy notice version with effective dates, and the consent tool configuration as it stood. Rebrands overwrite content systems aggressively; anything not exported beforehand may be unrecoverable when a question about an old choice arrives months later.

What consent checks belong after launch?

Verify new records are being written under the new identity with correct fields and notice references, confirm old records remain retrievable, and sample both about a month after launch. Assign the check at migration time, because the team that would remember will have moved on by the time it matters.