Dynamics to Salesforce Migration:
Our Personal Tale
We weren’t the first organization to switch from Dynamics 365 to Salesforce… and we aren’t the last. Yet somehow, there is very little out there from those that blazed the trail, sharing trials and tribulations to help others. And as we all know, the devil’s in the details.
TL;DR: D365 to SFDC FTW!
When Smartbridge migrated from Dynamics 365 Customer Engagement to Salesforce Sales Cloud, we were no different than our own clients – cautious, deliberate and thorough. Our data is sacred, and mitigating the risk of losing precious data when migrating from one CRM to another is the name of the game.
Here’s an overview of the gotchas, pitfalls and pain points that we think most organizations will also encounter.
“Business Process Flows” vs “Paths”
(vs lead status, vs status…vs…)
In our first planning meeting, we evaluated the requirements for Leads, Contacts and Accounts. Most out-of-the-box (OOB) fields we used in Dynamics are present in Salesforce, perhaps with a few minor picklist changes here and there. The key here is to identify all the custom fields and field level security rules.
The main difference comes with Business Process Flows. In Dynamics, the OOB field called Lead Status, the action of disqualifying a lead, and choosing the reason, and the Business Process Flows (the progress bar that moves a record through stages) are all independent of each other. In Salesforce, they’re not.
Farewell old friend!
When a record is disqualified in Dynamics, it is essentially an inactivated record. It exists almost in purgatory, not deleted, but never surfacing in views or reports by default. You have to choose a Lead Status of Disqualified to include them with Open (or active) records in a query. The record is locked for editing.
There’s no such thing in Salesforce. There is an ‘Unqualified’ stage (in our case we changed the name to ‘disqualified’) within the business process flow that acts as a disqualifier, yet these records will remain active, so to speak, when a salesperson is reviewing the leads assigned to them. Views will need to have filters turned on to exclude the leads in the Unqualified stage.
We recommend moving the disqualification status reasons over to become selections for the Unqualified stage. Some of the reasons we were used to include: left company, competitor, bad email, no longer interested, and a few others. These now become selectors to sub-categorize your Unqualified leads. This is helpful, as not all disqualifications are created equal. Creating a report or view for leads that have ‘left the company’ may be opportunities in disguise. Periodically checking LinkedIn may reveal that this person has found a better position at a target company – no sense starting from scratch! Reference previous interactions with them to re-introduce yourself and you may find you have a new opportunity again.
And competitors…well. Perhaps a report will show one particular competitor is snoop-ier than others… or maybe recognize them for their diligence with competitive intelligence! This could also be a great opportunity for practicing your Flow skills. If a lead is disqualified as a competitor, a new competitor record could be created.
What a difference a name makes
(Just some of the things that stood out)
Dynamics 365 | Salesforce | |
---|---|---|
Entity | is known as | Object |
Sub-Grid and Associated Views | do the same thing as | Related Lists |
Marketing Lists | don’t exist, but you can still achieve the same thing with | Campaigns and Campaign Members |
Status Reasons | typically translate to | Stages, or simply Status |
Business Process Flow | is known as | Path |
Custom IDs and Traceability
It’s best practice to capture a legacy ID within the new Salesforce record. If you’re fortunate enough to keep Dynamics active for a while longer, or export your database for archival reasons, you may find that you need to reference it. If you failed to migrate a key field, or chose to ignore deactivated/inactive/disqualified records and need to reference them, this legacy ID will be helpful.
The other reason it’s valuable is simply to ensure you’re mapping related records correctly. If you match a name of a person or account, that presents a risk of wrongly associating say, a campaign, or opportunity. In most cases, entities in Dynamics have a GUID (you will always see it as the hidden Column A in your exports). This is the value of the name field, which always surfaces with its display or named value. So, if you need to export associated records, it is difficult to find a way to get the GUID, and not the name, on those reports. Campaigns have a Campaign Code, which is a unique ID and can be included in related reports, such as opportunities and leads (when you need to map a source campaign, grabbing this code ensures precise mapping).
There are several third-party add-ons to create a unique value ID. There were two options in particular that we entertained. One only works with smaller databases, as you simply create a standard text field with security permissions applied, and update records with a randomly generated unique ID. We created these with a simple Excel formula, like so.
The other option is to use a few utilities with XRMToolbox (every Dynamics admin’s best friend!). The steps are outlined here.
This ‘gotcha’ snuck up on us in the 11th inning, as no one expects that a unique ID would be this hard to export across all related entities. But here we are.
What good is all this wisdom if we can’t share it with the world?
Smartbridge is a Salesforce Partner, and we can help you with your Dynamics migration too.
Marketing Lists, Campaigns and Campaign Hierarchy
Dynamics loves to keep church and state separate (contacts and leads… or leads and contacts?). Therefore, marketing lists can only house one entity type – accounts, leads or contacts. Marketing lists are sometimes considered to be groups, so if you have an integrated marketing automation platform, or email service provider, they may call these Groups or Lists, and you would have likely synced said groups with the Dynamics Marketing Lists. These inherently can be tethered to a Campaign, so you can monitor success with your marketing messages that are targeted to specific lists of people.
Marketing lists don’t exist in Salesforce Sales Cloud. This is actually a good thing because I’ve always felt that the way we manage marketing activities in Dynamics was over-engineered. Every campaign needed at least two lists and the naming conventions had to be followed or confusion prevailed.
OOB, Dynamics campaigns don’t have hierarchy. You can create one with a 1:N relationship, but it can become a complex configuration if you want to rollup values to look at how your parent campaign is doing overall.
Salesforce has a variety of OOB hierarchy fields, including revenue, members, budget, opportunities created and won. They suggest you create a hierarchy 2 or 3 levels deep, making your parent campaign your marketing strategy or message, and your tactics as the children. Members can be assigned directly to the campaign, whether they are leads or contacts.
This quite possibly will be the answer to sales’ dreams – if they want to follow up with engaged prospects, you don’t need to build a dashboard or custom view so they can find what they’re looking for (YOU try telling salespeople they need to look in two different marketing lists to find people to follow-up with!)
Overall, for both sales and marketing teams, this configuration has its upsides. The downside is the migration hurdles to move marketing list members over to campaign members. The trick is to customize a view of marketing list members with their custom IDs attached, and ensure that your Campaign Code is appended to the reports.
Marketing list members with their custom ID and the campaign ID for which the marketing list is associated with.
Salesforce for Outlook
Outlook Integration
Let’s take a look at one thing that was almost too easy. In Dynamics, the Microsoft Dynamics 365 App for Outlook is a lightweight solution built into the platform. You simply locate it within your personal settings and activate it, from within Dynamics. To achieve the same email tracking feature for Salesforce, you’ll need to install and configure the Salesforce app on AppSource, from within Outlook. Surprisingly, it ends up looking nearly identical – if you’re familiar with finding related records and turning on tracking from Outlook, you’ll have no problems with the switch.
There are different Outlook packages for Salesforce, each as a different upgrade option. We’ll break these down is for another article at another time, but in the meantime, here’s a great video where they explain the differences.
Also, if you’d like to hear our thoughts on the best Salesforce add-ons, we’ve shared our favorite Apps here.
We’re all better for it in the end.
Every organization will have their own gotchas, and these were some of our own. Though, the fact that these fields and processes are different between the two CRMs, some degree of concern will be present for every org that uses said fields and processes. How you handle them is up to you, but Smartbridge is always happy to lift up our own hood and show you how we rigged up ours. There’s no sense in re-inventing the wheel when you have a partner to carry you over the migration finish line. Our best recommendation? Remember this chant: “It’ll all be worth it in the end!”
Keep Reading: 4 Salesforce AppExchange Apps You Should Know
Looking for more on Salesforce?
Explore more insights and expertise at Smartbridge.com/salesforce
There’s more to explore at Smartbridge.com!
Sign up to be notified when we publish articles, news, videos and more!
Other ways to
follow us: