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.