CRM Guide

How do you successfully migrate to Salesforce?

Published , Updated 6 mn
Profile picture for David Boukhors

David Boukhors

Guest author

David Boukhors is a CPQ expert since 2017 and he is the only official trainer for CPQ in French. He's worked on over 30 CPQ projects with his consultancy Cloud Girafe, based in Paris, France

There always comes a time, in the course of a company’s development, when the CRM solution in place no longer meets its needs and shows its limitations. This is when the question of CRM migration arises.

This article focuses on migrating your CRM to Salesforce. Salesforce today offers one of the most mature CRM solutions on the market, and is often the choice of companies with advanced needs.

One of Salesforce’s strengths is that it’s actually more than a CRM, since it can also handle marketing (via Marketing Cloud) and ERP functions (using the AppExchange).

If you’re considering migrating your CRM to Salesforce, you’re in one of two situations:

  • Rare case: you’re starting from scratch, you don’t have a CRM worthy of the name, or rather you’re using Excel to manage your customer relations and sales processes.
  • Most likely case: you’re using an off-the-shelf CRM solution (such as HubSpot or Pipedrive), but you’re no longer satisfied with it and can’t deploy all the use cases you want.

Whether you’re in one of these two situations, this article is for you. It covers the main topics to be addressed when migrating from CRM to Salesforce.

#1 Map the data to be migrated

In my work as a Salesforce integrator for Cloud Girafe, I’m often asked to take charge of CRM to Salesforce migration projects. We always start our projects with a thorough assessment of our customers’ needs and current CRM operations.

This preliminary work creates a file that will be essential throughout the project: the data dictionary. The aim of this document is to map all the fields and attributes used in the customer’s current CRM (HubSpot, Pipedrive, Freshsales or other) and to match them with the customizable data model proposed by Salesforce.

It’s important to be accompanied by an integrator at this stage. Indeed, the most interesting method is to reuse as many standard fields as possible in Salesforce, rather than creating specific fields. Standard fields will ensure greater compatibility with the modules and AppExchange you install later.

It’s also important for an integrator to explain the Salesforce data model to you, to avoid reinventing the wheel. For example, I often see implementations where an “Address” object is created to manage addresses, whereas the standard data model already offers a multitude of functions for managing address-type data.

#2 Define target processes

Alongside the data dictionary, you need to qualify the sales processes you want to manage in Salesforce.

The easiest way is to follow the Lead-to-Cash lifecycle and describe the sales funnel from your company’s various points of view. Here again, the presence of an integrator will save you precious time and prevent you from accumulating technical debt. As an anecdote, for example, I had a case where the Opportunity object had been completely reprogrammed to save a few licenses – a saving which proved to have serious consequences a few years later when the tool became the cornerstone of the IS.

Diagram of a classic Lead-to-Cash process. Source

I’m also wary of “iso-functional” migrations with hyper-detailed specifications. Before trying to reproduce your processes identically in Salesforce, I’d advise you first to learn about these processes and adapt them to stay close to your current operations.

Here’s an anecdote from my own experience: during a CRM migration, the customer indicated in the specifications that he wanted us never to create more than 5 contacts under one account. Since Salesforce is not restricted, we had to set up a process for calculating the number of contacts and blocking them when the maximum was reached.

No one had ever been able to explain the reason for this constraint, despite our numerous queries. It turned out that the old CRM was limited to 5 contacts per account. This was simply a limited feature of the tool. And unfortunately, it was reproduced identically in Salesforce.

#3 Define target users (status and rights management)

In any project to migrate to a new CRM like Salesforce, one of the key steps is to define the target users and the scope of each type of user. Who can create or delete an account? Who can generate or validate a sales opportunity? More generally: who can do what and who can access what? You need to take the time to define the profiles and rights (access, read, write) of each user.

The typical user profiles used in CRM are as follows:

  • Administrator: Has all the rights required to manage and configure the system. This profile is already in place and generally requires no modification.
  • Sales: Able to create sales opportunities, generate quotes, etc. This profile is essential for sales teams.
  • Sales administration (SD): Has the same rights as the sales profile, but with additional rights to access account financial information, as well as data relating to orders, contracts and subscriptions.
  • Access management for VP Sales. For VP Sales, we recommend using the basic sales profile and adding specific rights via additional permissions. This method maintains simplified profile management while customizing access according to strategic needs.

It is advisable to limit the number of different profiles to simplify system maintenance. Each addition of a new field or functionality should be carefully examined from the point of view of access rights, to avoid unnecessary complexity.

Salesforce enables fine-tuned user and access management.

Salesforce has also introduced advanced functionalities such as Dynamic Forms, revolutionizing the management of access rights. This technology makes it possible to make a specific field editable or visible only to certain users, according to precise criteria. Unlike older methods, which often required the duplication of pages and profiles, Dynamic Forms considerably simplify the customization of user interfaces according to access rights.

Dynamic Forms lets you define read/write access rights for each data field.

#4 Making a successful transition from your old CRM to Salesforce

Those familiar with IT projects will be familiar with the term “switchover”, often associated with a critical and risky moment in a project. But what exactly does it mean?

The “switchover” refers to the process of transitioning from the old CRM, say CRM A, to a new system, in this case Salesforce. This is an important step, as it involves transferring not only data, but also business processes and user interfaces to an often radically different environment. CRM migration goes far beyond the purely technical aspect of data migration.

The aim is to make this organizational transition as smooth and transparent as possible for users.

However, transferring data and configurations from one system to another is a complex and time-consuming operation. This transition time, although minimized by prior simulations called “dry runs”, cannot be reduced to zero. These simulations are essential, as they enable problems to be identified and corrected before the day of the actual switchover, thus reducing the risk of service interruption.

And successful switchover is not just a question of technology. User training and communication are also essential. Before, during and after the switchover, it’s important to offer appropriate support to familiarize users with the new system. Training sessions and clear communication materials can greatly facilitate this adaptation.

Last but not least, it’s important to plan for a post-changeover monitoring period. During this phase, the IT team must remain vigilant and responsive to user feedback, to quickly resolve any technical or functional issues that may arise. This monitoring helps to stabilize the system and ensure that the new CRM meets users’ needs.

#5 Anticipating the maintenance of your Salesforce CRM (Third-Party Maintenance)

Throughout the life of your CRM, you’ll come across periods of change, often punctuated by specific projects. However, in between these active phases, it’s essential to keep the system running smoothly, and to quickly resolve any malfunctions. This is where Third-Party Application Maintenance (TPAM) comes in.

What is TMA?

TMA refers to the ongoing maintenance services that keep your CRM running smoothly on a day-to-day basis, by fixing bugs and making minor improvements to the system. This maintenance is important for the ongoing stability and efficiency of your operations.

To manage this ongoing maintenance, it’s often a good idea to sign a maintenance contract with a specialist service provider. At Cloud Girafe, for example, we offer TMA services recognized for their efficiency and adaptability. Our agile approach is particularly appreciated, so much so that many of our competitors and partners recommend us to handle post-project maintenance for their customers.

We advise you to anticipate this issue and negotiate TMA conditions and rates with your Salesforce integrator from the outset. This not only enables you toanticipate costs, but also ensures that your system will be in safe hands after the initial deployment phase. By agreeing these terms and conditions from the outset, you can concentrate fully on your core business, while being confident that your CRM is running optimally and continuing to adapt to your needs.

Conclusion

In conclusion, it’s worth stressing once again the importance of considering CRM migration first and foremost as an organizational issue. Beyond the technical aspects, beyond the question of data (to which migration projects are sometimes reduced), the success of a migration to Salesforce depends on your ability to make this new CRM a tool that is adopted and appreciated by users, and aligned with their business needs. This is the key to a successful “switch” to Salesforce, and it’s the principle that guides the projects I work on with my customers at Cloud Girafe. If you have any questions on this subject, please don’t hesitate to leave a comment.

About the author

David Boukhors is a CPQ expert since 2017 and he is the only official trainer for CPQ in French. He's worked on over 30 CPQ projects with his consultancy Cloud Girafe, based in Paris, France