Imagine a scenario, where you are realizing using email address as your Contact Key was not that good after all. You should have read this material on how to select the most suitable Subscriber Key for you. But now it’s too late. What are your options now?
What you are looking into is a so-called Contact Key migration. A task which can’t be done within the UI, and requires a paid services engagement by Salesforce. It will basically update the database, replacing the old Contact Keys with new ones, based on a SubscriberKey Data Extension containing the following fields:
- OldSubKey – Text Field
- NewSubKey – Text Field
- MigrationDate – Date Field
The data MUST be validated
- No duplicate keys can exist in the OldSubKey column
- No duplicate keys can exist in the NewSubKey column
- OldSubKey and NewSubkey values cannot be the same for a subscriber across the entire data set.
So you will want to have your email addresses in the OldSubKey column and your new IDs in NewSubKey column.
All OldSubkey values should exist in the Subscriber table. If any OldSubkey is not in the Subscriber table, then those OldSubkey values will not be included in the migration.
If a contact is NOT included in the mapping DE, there will be no update applied to the subscriber. The process will migrate only what exists in the mapping DE.
This is relatively easy. What makes the task more complex is the fact that you CANNOT send during the migration process. Sending includes both Batch Sends and Triggered Sends. You must ensure your API calls are halted (you can’t receive new signups, or do any other data updates in this period) and that the Triggered Send queue is cleared and then paused on the Marketing Cloud side.
Once all of the above has been completed, SFMC Services will need to be engaged to carry out and oversee the actual migration.
To avoid having legacy Contact Keys appear in Marketing Cloud, it is essential to ensure your new identity provider becomes single source of consumer identity and other systems should no longer provide data which in any way reference the legacy Contact Key, being the email address.
Contact Key migration will indeed carry engagement over from the old Contact Keys to the new ones, which applies to both clicks/opens, and Einstein engagement.
But, this might not be your only option. Most of the clients I work with, when looking into migrating to a new Contact Key, are not willing to take on the somehow complex task of Contact Key migration. Their business continuity is seen as too significant – as downtime of up to 24 hours can be expected. Instead they update the data within all relevant data extensions, to include the new Contact Key. This approach is not without drawbacks, as all the historical engagement data in e.g. data views, and tracking reports will be lost, as well as journeys which are set to no-reentry will accept same contacts, as exclusion is based on Contact Key.
But is it possible to avoid doing a Subscriber Key migration, if you change from one subscriber key to another? It is indeed possible. There You can simply upload your existing contacts with new subscriber keys, and delete the old ones. Do keep in mind though, that should you have a complex data model, with a lot of related tables (e.g. orders, appointments, opportunities, etc) you will need to ensure the foreign keys in these tables are updated as well.
You will also not be able to retain your historical engagement (i.e. records in your data views will be gone, since all of the engagement will be anonymized). This anonymization is to keep open and click rates for historical sends, while ensuring no references to the old Subscriber Keys will be kept in the system. You can export all the engagement in Tracking Extract, and store it in data extensions, where you will be able to update the Subscriber Key. Hence allowing you to retain capability of querying engagement history of all your contacts.
Another drawback of this simple “switch” is you no longer being able to ensure contacts who have been through a journey set to “no re-entry”, will not enter it again, since they will enter it with the new Subscriber Key.
in what scenario can the contact key migration carry over send/open/click and engagement data to the new subscriber key?
If performed by Salesforce (as paid engagement) all the engagement data will be migrated to the new subscriber key for that particular contact.
If performed by SF team, yes you can keep all your previous engagements.
On the other hand, you can create suitable data extensions to keep the historical data and handle it. Paying SF is not worth for it. An experienced SFMC TA can handle all the subkey migration process. And you will not lose any data .
As a seasoned marketing cloud TA on both Salesforce and Adobe, all is possible if you can handle your own data.
I agree, that subkey migration is not your only option – which I also write in the article. But it is the only option, if you (for whatever reason) want to keep your engagement data in the original data views etc. referencing your new subscriber key. I have also managed multiple scenarios where this wasn’t done and we indeed relied on extracting engagement data into few data extensions, where the new subscriber key was appended as an additional column.
Can we still do subkey migration without it performed by salesforce (as paid engagement).
No, unfortunately this needs to be done by Salesforce.