Subscriber status migrates easily. The evidence behind it — who agreed, when, and to what — is the part that gets left behind, and the part you have to be able to produce.
A migration plan will always have a line for subscriber data. It rarely has one for the evidence sitting behind that data — and the evidence is the half that is hard to reconstruct once the old platform is switched off.
Most migrations move the flag. Subscribed, unsubscribed, bounced — a column that says where someone currently stands. That column is the result of a decision the person made, not evidence that they made it.
Under GDPR Article 7(1), a controller has to be able to demonstrate that consent was given. A boolean in a newly configured platform demonstrates nothing on its own. It says what the system believes today, with no account of how it came to believe it.
The risk is quiet and delayed. If the old platform is decommissioned on schedule and its logs go with it, you can keep every status and still lose the ability to answer a question that arrives a year later.
Four things make a status defensible: when consent was given, through what mechanism, what the person was actually told at the time, and every change since, each with its own timestamp.
The awkward part is that these usually do not live in the subscriber table. They sit in form submission logs, import histories, campaign records and archived page templates — none of which appear in a standard subscriber export.
That is why this belongs in scoping rather than in cutover week. Finding out during the final export that consent history was never in scope leaves two options, both bad: delay, or go live knowing the evidence has been left behind.
Unsubscribes, complaints, hard bounces and legally suppressed addresses are the records where mistakes are most visible and least forgivable. Emailing somebody who explicitly opted out is the failure people remember, and it is entirely preventable.
Import order is the usual culprit. Load the master audience after the suppression list, without the suppression logic in place, and you can resurrect people who left years ago — in a single send, at full volume.
Verify by count and by spot check. Take a set of known unsubscribes from the old platform and confirm each one is suppressed in the new one before any campaign goes out. An import summary reporting success only tells you rows were written.
Topic and frequency preferences are commitments made to a person. Someone chose monthly rather than weekly, or product news rather than everything.
New platforms rarely model preferences the same way, and some granularity usually cannot be carried across exactly. That is a normal constraint. What is not normal is letting it resolve itself silently during a data mapping workshop.
If a preference cannot be honoured after the migration, someone has to decide what happens instead — default to the most conservative option, or re-ask. Collapsing “monthly digest only” into “all email” because the target schema is simpler is a broken promise, made at the scale of the whole database.
GDPR Article 7(3) requires that withdrawing consent be as easy as giving it. In practice that means the unsubscribe path has to work on the new platform on day one, not once someone reports it.
Test it end to end and from a real send: click the unsubscribe link in an actual email from the new platform, confirm the record updates, then run a subsequent send and confirm the address is excluded. Previews and test sends often use different link handling, so passing in preview proves less than it appears.
This is a short test that takes an hour and reliably finds at least one broken assumption about how the new platform writes back.
Put consent evidence in the migration scope with its own acceptance criteria, and agree the old platform's retention window against that, not against the licence renewal date. Status tells you what to send today. The record is what you rely on if anyone ever asks why.
This is delivery practice, not legal advice. How the rules apply to a specific programme is a conversation for your legal team or DPO — the point here is that the migration plan has to leave them something to work with.