Migrating 2.3M Contacts from Email-Key to CRM-ID Contact Key
A B2C retailer has 2.3 million contacts in Marketing Cloud. For six years the Contact Key has been the email address. The CRM now provides a stable 18-digit customer ID, and the business wants to adopt it to unify 410,000 contacts who use multiple email addresses. Existing journeys use email address as the entry source, and 38,000 historical sends reference email-based subscriber keys. The team cannot take a multi-week sending freeze. They ask whether to change Contact Key in place or create new contacts, and how to avoid double-sending during the transition.
1. Evaluate in-place Contact Key change versus creating new contacts with CRM IDs. What are the consequences for tracking history, All Contacts, and journey entry?
Read the worked answer
Marketing Cloud does not support changing an existing Contact Key in place. The Contact Key is the immutable identifier behind tracking, journey history, and All Contacts. Editing it would require creating a new contact, and the old tracking history would remain tied to the old key. So choose a controlled re-key: create new contacts with the CRM ID as Contact Key, store email as an attribute/relationship, and leave old contacts in place until journeys and reporting are reconciled. Expect historical tracking to be split across old and new keys; reporting must join on email or a mapped legacy key. Do not delete old contacts early-you would lose the only link to historical sends.
2. The team wants to deduplicate the 410,000 multi-email contacts before cutover. What matching logic and data model should they use, and what should they do when two email addresses have conflicting opt-in statuses?
Read the worked answer
Match on CRM ID, not email, because email is the attribute being deduplicated. In Contact Builder, model CRM ID as Contact Key and email as a related attribute; use a data extension with one row per email if a contact can have multiple addresses. For conflicting opt-ins, apply the most restrictive status per email address, not per contact: an unsubscribe on one address should suppress that address, while a second opted-in address may still receive if the business has a lawful basis. Do not collapse an opt-out into a contact-level "active" flag. Use publication lists or per-address subscription data to preserve the distinction.
3. What should the admin do about the 38,000 historical sends and active journeys during migration?
Read the worked answer
Do not inject re-keyed contacts into active journeys. Journey Builder entry is by Contact Key, so new contacts would start the journey from the beginning while old contacts continue, causing duplicates. Let active journeys finish on old keys, and create new versions with the CRM-ID entry source for the cutover. For the 38,000 historical sends, keep the old contacts and use send logs for reconciliation; do not rewrite history. Set a cutover date, exclude new contacts from old journey entry sources, and monitor sends for the same email appearing under both keys during the overlap.