Replacing Salesforce Orgs That Have Connected Marketing Cloud Instances
I once worked with a client that had a legacy Salesforce org. The org, which had barely been used in years, was filled with managed packages and customizations that had outlived their usefulness. The only reason the org hadn’t been retired was because it was synchronizing its contact data with an instance of Marketing Cloud, which was sending periodic email communications to the subscribers in its database.
After a leadership change, some new stakeholders identified a set of use cases that they thought would be a good fit for Salesforce. They asked me to review their existing org and make a recommendation around whether to replace it or try to remediate all of the technical debt that had built up after many years of poor maintenance.
For a variety of reasons, we ultimately decided that replacing their existing org and migrating all of its data into a new one would be the best approach, but this would still be a challenge. To do an org replacement correctly, you have to follow steps that are similar to the ones you’d follow for a new implementation, but instead of migrating your data from spreadsheets or another legacy system, you migrate it from an existing Salesforce org. This might sound like a small detail, but you shouldn’t underestimate the complexities it can create.
In my customer’s case, even though they were using very few CRM capabilities, they still considered their legacy Salesforce org to be the source of truth for their contact data. The process they were following to add new subscribers to Marketing Cloud was to create the records in Salesforce and then let them replicate via the Marketing Cloud Connector. This approach is perfectly fine under most circumstances, but it can cause issues when it comes to org replacements because of the way that Marketing Cloud uses the IDs associated with contact records that originate in Salesforce.
Understanding the root of the issue: duplicate subscriber records
A subscriber represents an individual in Marketing Cloud’s database, and is roughly the equivalent to a contact in the core Salesforce platform. The ID that Marketing Cloud uses to identify each subscriber is called a subscriber key. Almost every internal process within Marketing Cloud relies on subscriber keys in some way, including:
- Determining which subscribers to send communications to
- Keeping track of previous communications each subscriber received
- Determining which journeys a subscriber should be placed in
- Keeping track of preferences and unsubscribes
If you’re using the standard Marketing Cloud Connector to send contacts from a Salesforce org to Marketing Cloud, the process to sync records between the two systems looks like this: When a contact is created or updated in Salesforce, the data will replicate to Marketing Cloud. If Marketing Cloud finds a subscriber key in its database that matches the Salesforce contact ID, it determines that this is an existing subscriber and update the record. If not, it assumes that the contact is new and adds a new record to its database with a subscriber key identical to the Salesforce contact ID. In either case, the end result is a Marketing Cloud subscriber key that matches the Salesforce contact ID.
This is a straightforward process as long as both systems stay the same. But if you decide to swap out the original org you connected to Marketing Cloud with a new one, then when you migrate your contacts, the new org will create new contact IDs for them. And since Marketing Cloud won’t have any way to know that this is going on, all of the subscribers in its database will still contain subscriber keys that match the IDs from your legacy org.
And at this point, if you connect Marketing Cloud to your new org and sync your contacts, the new IDs won’t match any of the existing subscriber keys, and Marketing Cloud will create new records for them. You will ultimately end up with a set of duplicate subscriber records and no easy way to identify them and merge them.
This leads to a variety of downstream issues, including:
- Subscribers may receive duplicate emails
- The same subscriber can be put into a journey more than once
- People who unsubscribe from your communications may continue to receive messages, which can create compliance issues if your organization is located in an area governed by regulations like General Data Protection Regulation (GDPR) or California Consumer Privacy Act (CCPA).
Three approaches and their tradeoffs
So how can you avoid the problems that stem from duplicate subscriber records? There are three options, and they all have tradeoffs. To choose the best one for your situation, you’ll need to think about how you plan to use your existing data in Marketing Cloud.
Option 1 is to purge all of your existing data from Marketing Cloud before connecting it to your new org. If you do this, Marketing Cloud will still create a new subscriber for each contact that replicates from your new Salesforce org, but that won’t be an issue since the duplicate records won’t exist. The drawback with this approach is that when you purge your data from Marketing Cloud, you’ll also lose all of your historical data, including sends, opens, clicks, and so on. If you’re doing extensive reporting and making decisions based on historical data, this approach might not be ideal.
Option 2 is to keep your existing data in Marketing Cloud, and adjust the queries you use to send communications to make sure they exclude your legacy contacts. This doesn’t require you to purge any existing data, and you’ll still be able to run reports against historical information. The downside with this approach is that it increases your long-term maintenance costs since you have to continue to make sure your legacy contacts are excluded from your queries in perpetuity. Additionally, some privacy regulations require businesses to produce on-demand reports showing all of the data they have about an individual if that person requests it. If your company is subject to any of these regulations, then in order to properly comply with such requests, you’ll have to find a way to combine the information from both the legacy and active subscriber records into a single report.
Option 3 is to pay for a Subscriber Key Migration. This is a paid service offered by Salesforce that will migrate the subscriber records in Marketing Cloud’s All Subscribers table from an old value to a new value based on a mapping file that you provide. This approach comes with a few other caveats as well: a subscriber key migration does not merge, delete or add new subscribers. It simply updates their subscriber keys. It also doesn’t combine subscribers from different lists or combine tracking data from different subscribers. Lastly, you won’t be able to use Marketing Cloud while a subscriber key migration is in process, so if you want to do one, you should plan it during a time when you aren’t going to be sending out a lot of communications. If you want to do a subscriber key migration as part of a legacy Salesforce org replacement correctly, you should follow these four steps:
- Export your existing contact data from your legacy Salesforce org and disconnect it from Marketing Cloud
- Import your contacts into your new Salesforce org and make a note of their new contact IDs
- Contact your Salesforce Account Executive to schedule a Subscriber Key Migration and provide your mapping of old to new contact IDs
- After the Subscriber Key Migration is complete, connect your new org to Marketing Cloud. At this point, the subscriber keys in Marketing Cloud will match the contact IDs in your new org and Marketing Cloud will treat your contacts as existing subscribers.
The client I worked with decided to go with Option 1. Their stakeholders determined that being able to report on legacy Marketing Cloud data wouldn’t create a lot of value for them. So, they downloaded a final set of reports and saved them just in case. Then they made sure to set aside time in their org replacement project to purge their Marketing Cloud data before connecting their new org to Marketing Cloud.
If you find yourself in a similar situation, make sure that all of your stakeholders are aware of the options and the tradeoffs involved before reaching consensus on the best path forward.
