While implementing a CRM can have a profound positive impact on your business, sometimes you have to concede that it isn’t working. For whatever reason, whether it’s down to the functionality or complexity of the platform, businesses can occasionally find they have regressed under their new system and have no choice but to cut their losses and look for a new CRM solution.
The important thing is not to look at your change of CRM as an admission of failure, but rather another opportunity to get the most out of your business, having gained first-hand experience of what doesn’t work. CRM vendors will no doubt be tripping over themselves to win your business, but the greatest challenge when changing CRM is no doubt data migration.
Why do people migrate to Salesforce from Microsoft Dynamics?
It isn’t uncommon for businesses to change their CRM solution from Microsoft Dynamics to Salesforce. According to our 2018 Salesforce salary survey, the top three CRM vendors from which Salesforce-using employers have migrated were Microsoft Dynamics, Oracle, and SAP.
What’s more, the functionality of Salesforce was reported as by far the top reason for implementing the CRM system, while 37% of those implementing Salesforce admitted that lack of confidence in their previous CRM solution triggered the change.
One of the more common reasons that Salesforce is celebrated is the huge number of product integrations that come readily available with the platform. Instead of choosing a solution that houses every function under the sun, Salesforce’s approach is to embrace other platforms and give users the option to use products from other market leaders — if you can’t beat them, join them.
If you have already started winding up your subscription to Microsoft Dynamics and have spoken to a Salesforce representative regarding which of their solutions would be best for your business, it may be time to think about how you plan on migrating your business data. After all, a CRM system is nothing without data.
Data migration is not something that should be taken lightly, however. Without a smooth transition from one CRM product to the next, you could experience loss of revenue due to delayed business processes, as well as the obvious risk of data loss. You need to ensure that staff are ready to harness that data as soon as your new CRM is up and running, and this can be challenging.
Changing your CRM: the fundamentals of data migration
Planning is everything when it comes to data migration, as not only must a number of tasks be carried out to ensure an effective product switch, but they must also be performed in the right order. We will start out by listing good practice for any kind of data migration, regardless of which CRM you are switching from and to, then give specific guidance on avoiding common mistakes when moving from Dynamics to Salesforce.
While there is a lot of guidance available as to best practices when migrating data to a new CRM product, it can actually be boiled down to five key steps:
1. Explore and assess the data in your source system
Before you begin thinking about moving homes, you need to get your own house in order. While your data may be stored across thousands of fields and datasets, many of those may be duplicates, erroneous, or redundant. At this early stage, it is critical to identify shortfalls in your processed data so as not to jeopardize your migration.
A productive exercise is to become familiar with the fields in your target CRM, and use these to group the data in your source system. This way you can cleanse and organize your data knowing exactly what your new CRM solution is looking for.
This may be quite straightforward if data fields are similar (such as customer name, address, contact number etc), but if you find your new product contains fields that your old solution does not, you may have to take data from several fields to populate these. By contrast, if your new solution does not contain appropriate fields to house your existing data, you can plan ahead of time whether new fields need to be manually created or if you will be storing your misfit data in some other way.
2. Data profiling and cleansing
Now you are familiar with the depth of your data and how your records compare to that of the new system, you can start to clean up that data ready for migration. Data profiling allows you to critically evaluate the quality of your data, whether you can address data anomalies or repeat errors in bulk, and how you will go about mapping your data to migrate to the new platform.
If you find repeat patterns of data fields being empty or poorly maintained, consider whether this data is crucial or whether it has been neglected for a reason. While it’s essential that you take all crucial data with you to the next platform, remember that the less information that needs to be migrated, the smoother and simpler the process.
Niels Weigel
Niels Weigel is an expert in data management and, in his blog post for SAP, outlined the six following steps as essential when profiling and cleansing data:
Discover — Gain a clear understanding of how and where your data is stored.
Define — Establish your data standards, policies, and quality requirements. Feel free to involve the rest of your organization to ensure these policies are universal.
Assess — Make an objective assessment of the current data quality based on the standards and policies you have just defined.
Analyze — Try to establish the root cause of your bad data, and trace the potential impact of this bad data through other facets of the business. You may discover that this bad data has a greater knock-on effect than you anticipated.
Improve — Manually improve your data, and establish systems to prevent bad data in the future in relation to the root causes you have identified. Bad data can be as a result of employees or customers, so look to improve both sides of data entry.
Monitor — Now you have cleansed your data and established systems to maintain it, keep a constant eye on whether these processes are being fulfilled. If you don’t see improvements in the utilization of data or in your data quality scores, revisit these six stages and investigate whether anything has been overlooked.
Recent research from Gartner indicates that the average financial impact of poor data quality on organizations is around $9.7 million a year. Gartner also reported that poor data quality is a primary reason for 40% of all businesses failing to achieve targets. Failing to cleanse data before a product migration could lead you down the wrong path before you even begin using your new CRM solution, so be sure to invest time in data profiling now rather than later to prevent delays to service.
3. Plan and test the migration
This step is a little more challenging from a technical perspective and will probably involve an expert opinion. There needs to be a clear timeline outlined for your migration, in which each department of your business is clear on what is required of them and by what deadline — this is particularly important if a zero-downtime migration is required, as you will need to plan the migration in a way that does not disrupt business processes, which can be very tricky.
You will also need to define the technical architecture of your old and new CRM solution, and use that to define the process for your migration. Data mapping is made much easier if your initial data exploration, cleanse, and categorization is of a high quality, as you will now be able to map out which data should be moved to where.
Of course, no data migration will go ahead without prior testing, and a responsible way of doing this is to subset the data and test one category at a time. Start by testing small groups of data (such as a particular product or a specific post or zip code) and move to larger groups when you are confident that all mappings are working correctly. This means that if a problem arises, you can identify which dataset contains the offending data and eradicate it.
Once you have increased data volumes to include different data sets at once, and are satisfied that you could migrate any combination of data sets at the same time without error, you have yourself a tried and tested data migration process that is also scalable, so you can migrate as much or as little data as you like. All you need to check at this point is that you are able to complete a full migration within your proposed timeline. If not, you may fall back on the fact that your data migration process is scalable, which allows you to complete data migration in stages.
Ben McCarthy
Ben McCarthy is the Managing Director of Salesforce consultancy EMPAUA, and runs the much-celebrated, community-driven website Salesforce Ben. He has vast experience in Salesforce implementation, and believes that businesses can not overdo the planning and anticipation aspect of CRM implementation.
“A common pitfall when migrating to Salesforce is probably not anticipating it enough,” Ben explains. “Because that is obviously something that needs to happen with every project. Whether it’s an integration or manually exporting data and uploading it to another system, I think that anticipation and being prepared, knowing exactly what is required, is very important.
“Our customers obviously know their data the best, so we’d rather they outline their migration needs and we support them in doing that. I think it’s important to address it as early as possible so that you’re prepared for when we actually come to migration day.”
4. Execute the migration
Crunch time. When you choose to go ahead with your migration is entirely down to you. If you have a core group of staff that works 9-5, five days a week, it makes sense to start your migration in the evenings or at the weekend, when there is little to no disruption to business. If you have a group of sales staff working around the clock, however, things can be a little trickier.
The reality is that there may not be an ideal situation when you are migrating data, as you will likely have to compromise somewhere down the line. Either you bulk migrate your data and risk service downtime and disruption to everyday business, or you migrate in stages or in out-of-office time, which is more time-consuming and could involve extra costs if you need staff to work additional hours.
The upside is that by this stage the logistics of the migration will have already been ironed out, so all that’s left to do is actually go through with it. It makes sense to have someone manning the station while the migration occurs (presumably a data expert in your business or a contractor that you are using for the project) as this allows you to encounter and resolve problems as soon as they occur. Migration can be a very lengthy process if you come back after a weekend to find your migration encountered an error just ten minutes in…
When the migration is complete, quickly check through your datasets to ensure there is no missing data, as the likelihood is that you will soon be decommissioning your old CRM system and therefore lose that source data. Dynamics 365 offers a 90-day grace period in which your data is stored following the cancellation of your subscription, so be sure to take care of it before then. If you have the facilities, it may be worth making a secure backup of your old data just in case something catastrophic occurs with your new system — this is unlikely, but it is possible.
If your new CRM solution is based in the cloud, check connectivity and accessibility, ensuring that the relevant members of your business have sufficient permissions to access, input, and administrate the data required to perform their job role. If you find you don’t have enough licenses to cover the essential personnel in your business, consider whether your new licenses need to include full access or whether read-only access would be sufficient.
5. Audit, rollout, and optimize your new system
While your data profiling, cleansing, and mapping may have been meticulous, sometimes mistakes happen. It’s essential that you conduct a full audit of your new system before rolling it out across the business. If you discover errors, you always have the option of going back to your old system (or your secure backup) and taking another look at data profiling and mapping — something has clearly gone wrong somewhere along the way so, unless you know specifically where your problem lies, you may as well start at the source.
When you are convinced that your data has been successfully migrated, you can then begin rolling out the system across your business. Depending on the complexity of your new CRM, you may need to think about training your staff to operate the system. Ideally, you will have arranged this ahead of time, with staff being offered a dummy version of the software to practice regular functions and get to grips with the platform before they are required to operate it for real.
In addition to ensuring data quality and training your staff to get the most out of your new system, you should also consider which add-ons and extensions you could use to your advantage. Many modern CRM systems feature hundreds of integrations to boost overall functionality, as opposed to being included at the product’s core — why would a CRM vendor attempt to invent its own social media, when it could simply integrate with Facebook and Twitter?
While these five steps cover the basics of CRM and data migration, you will struggle to oversee the more technical stages of the migration process without a working knowledge of the new CRM software. Many businesses opt to employ or contract a third party to oversee the data migration, with some CRM vendors even offering a list of approved or accredited implementation partners to assist you.
Salesforce is perhaps the CRM vendor that embraces implementation partners the most. While some vendors prefer to oversee their own implementation, Salesforce recognizes that end users sometimes prefer to use third parties. Independent implementation partners have objective, unbiased experience of Salesforce, knowing every strength and weakness of the platform, which works out well for customers who want the very best solution available, particularly if they aren’t opting for an out-of-the-box solution.
Mistakes to avoid when migrating from Dynamics to Salesforce
We could spend days going through the particulars of data migration and best practice for data profiling and cleansing, but the reality is that each CRM platform is different. For a smooth transition, you need specific guidance on how to migrate from your particular CRM product, taking into account common problems and shortfalls.
Dynamics 365 is a fine CRM solution — it wouldn’t be one of the market leaders if it wasn’t — but there are certainly things that can make a migration from Dynamics more problematic than it needs to be. If you’ve already had a stab at data profiling ready for the migration, then you may have encountered some of these already. Here, we will detail some of the more-prominent mistakes to avoid when migrating from Dynamics 365 to Salesforce.
The customization conundrum
One of the biggest strengths of Microsoft Dynamics is also one of its biggest weaknesses. Dynamics has massive capability when it comes to customization and, if you have been using the CRM for a while, you may already have established hundreds of customizations in the way of custom fields. These are fantastic when using the CRM, but can be a nightmare when it comes to migration. After all, how can you expect your new CRM to recognize your custom fields when you had to manually create them in the first place? That is not to say that it can’t be done, it just requires a lot of time and expertise, usually from a professional.
A stumbling block when overseeing any kind of data migration is metadata. This certainly applies with Dynamics, where metadata entities include Workflows/Processes, Reports, and System Views. Metadata often consists of unmanaged customizations, which your new platform almost certainly won’t recognize. While it is possible to migrate metadata with a lot of care and attention (and years of experience in data mapping), a more practical solution is to instead migrate this metadata as conventional data. Doing this makes you capable of recreating these fields without needing to package them in a solution.
Dynamics houses unique types of entities that don’t match up with other systems. In Dynamics, ‘Activities’ are used to document a specific type of communication, recording the time, subject, and essential details of that communication. These are difficult to migrate due to the relationship they have with other entities in Dynamics — they tend to tie in with other types of data, and migrating an Activity requires you to also migrate records indicating the sender and recipient of the activity. This can be notoriously difficult to data map, due to the unpredictable nature of which data may be attached.
Recurring events and meetings are always problematic during a migration, and this is also true with Dynamics. ‘Appointments’ can throw up real issues, particularly if you have a recurring appointment that has been cancelled. One solution may be to migrate your appointments to another calendar in the short term, and then treat that as a separate migration. Appointments are so sensitive that it isn’t worth the risk of losing vital information, so at very least you should take more care with this type of data.
You may start to feel a great deal of regret around how your data has been administered when you discover how much essential information hasn’t been logged correctly, but instead lumbered into Notes and Attachments. This can be particularly problematic if those attachments are large and not migration-friendly, as you may have to spend a lot of time filtering that data through several different facets of metadata, or even putting it to one side until your migration is completed so you can then input it manually.
Advice from the Ohana
In order to discover some of the less common pitfalls when migrating from Dynamics to Salesforce, we took to Salesforce user groups and forums to see what the Ohana had to say about the process. With Salesforce being such a community-driven platform, there is an appropriately diverse range of guidance on migration to the service.
This discussion in the Salesforce Reddit community (/r/Salesforce) concerns migration to Salesforce from Dynamics. Reddit user TheBeerdedBeer identified the issues related to data mapping and recommended a quick fix to make migration easier:
I created a legacy ID unique field on contacts and accounts to aid when migrated everything over to make sure everything was in the right place when it imported.
While Reddit user bhamdan, despite having no experience of Dynamics-to-Salesforce migration as such, advised a step-by-step method of migrating from any CRM to Salesforce:
You need to migrate from bottom to top, things that aren’t related to things that are. Accounts first, then contacts, then cases or opportunities. The issue is that migrating from anything to Salesforce can be complicated with unforeseen issues. I haven’t migrated from Dynamics to Salesforce but I have migrated from several other CRMs and they all have common issues and unique issues.
This step-by-step method appears to be a popular one, with other Salesforce users suggesting a structured approach. In this article on LinkedIn, Salesforce partner Rolustech highlights importing related custom objects in a random order as one of the more common mistakes to avoid when migrating to Salesforce:
You might always import accounts before contacts or opportunities as it is reinforced everywhere, taking care of ordering of custom objects in accordance with relationships is equally important as the standard objects. Along with ordering of objects, you will need to include fields of the same object multiple times into other objects, to make sure that all the lookup relationships are set up.
Helpful tools and applications for Salesforce migration
Conversely, Reddit user tehdrunkard recommended using data quality tools to assist with migration, as this can make the process far more manageable:
Data mapping was simple. I loaded it into an access database then exported what I needed and uploaded with DemandTools.
This Salesforce professional was not the only one to recommend the use of tools when migrating. This thread about Dynamics-to-Salesforce migration on the Salesforce Trailblazer community forums throws up a number of solutions using tools, with one user suggesting the Force.com Excel Connector for updating data in bulk within Excel. The idea is that by implementing mass fixes in Excel, this will eradicate many of the issues associated with data mapping.
Another tool recommended in this thread, which also uses Force.com API, is Data Loader. This application is designed to be easy to use and will enable you to extract data from a given database into Salesforce objects. While data mapping is no easy task for a non-expert, this tool at least makes it possible with a drag-and-drop field mapping interface. Be sure to study the user guide and community articles on Data Loader before using the application, as a sloppy start to data mapping could put your migration in jeopardy.
The Salesforce AppExchange also provides a brilliant avenue for discovering helpful applications to assist with data migration. The highest-rated free tool on the AppExchange by a long stretch is Jitterbit Cloud Data Loader. This data migration tool enables Salesforce users to automate data importing from external flat files and databases, as well as from inside the Salesforce platform. While free applications have a habit of giving you limited access before prompting you to upgrade, its positive reviews suggest that this tool offers a comprehensive migration assistant with easy-to-use wizards for those without a deep knowledge of Salesforce.
While we could go on to list a multitude of helpful tools and applications that will assist with the many aspects of migration, the truth is that without a technical understanding of the Salesforce platform, your efforts may fall short. Enlisting the help of an implementation partner or Salesforce expert is the most responsible way to ensure a smooth and effective migration.
If you are interested in linking up with an implementation partner, or require greater assistance on your product migration, Mason Frank holds relationships with some of the most reputable partners in the Salesforce ecosystem, and would be happy to help in any way we can. Don’t hesitate to contact us to speak to one of our knowledgeable consultants, who will guide you through your next steps.
