Today's CRM applications, such as Salesforce, must meet high standards and provide a multi-dimensional view of the customer. To achieve this, data from legacy systems must be integrated or migrated into the new CRM system in almost every Salesforce project. This data migration is an integral part of the project, and Salesforce provides a very good solution for this with its API. But in any migration process, stumbling blocks cost nerves and valuable resources. However, if you know what to look out for, some problems can be avoided. Here are the top 5 professional tips.
Tip 1: Take a critical look at what reports you need
In order to take full advantage of Salesforce's reporting capabilities, the data model needs to be adapted. One of the main problems is that Salesforce does not allow two objects that are attached to the same parent object to be displayed in the same visual - this can lead to problems with target/actual reporting.
For example, it is not possible to view an account's Invoice object in the same visual as the account's Opportunity object. This type of comparison is essential for sales management. However, if each Invoice is assigned to an Opportunity, this can easily be achieved.
We therefore recommend that you work result-orientated during the design phase. The first step is to assess which reports are really needed. Only then do you start the implementation. In most cases, this avoids many time-consuming or unnecessary steps.
Tip 2: Use external IDs
The second tip is about tracking and troubleshooting data migrations. The key is to be able to link the record in Salesforce directly to the corresponding record in the source system.
This is achieved by using External IDs in Salesforce. It is possible to specify for all fields of an object that it is an object. For example, if data from System A and System B is being pulled into an object, it makes sense to use two External ID fields (External ID_A and External ID_B) so that the connection can be made immediately.
The API function in Salesforce, which also passes ExternalD fields directly, has been proven in numerous projects. This allows Salesforce to find a record without the associated SalesforceID.
The ExternalIDs are also the central function when setting up synchronisations. They keep data in different systems identical.
Tip 3: Less (migration) is more
Often the approach is: We need all the data! In our experience, this is a fallacy. Our recommendation is to migrate only the fields that are actually used, and if possible, only if the information is still important (in the sense of tip 1). This will avoid confusing mappings, the time-consuming transfer of large amounts of data, and data garbage that is transferred from legacy systems. Which brings us to the next tip:
Tip 4: Preparation is everything
For a proper migration from multiple source systems to Salesforce, the specification is the be-all and end-all. If there is no precise coordination of which fields in the different systems match and which system is the leading one for this, data consistency problems are pre-programmed. "Garbage in, garbage out applies to most projects involving data, and Salesforce data integration projects are no exception. It is important to consider what data is actually needed, and it is a good idea to quality check the data beforehand. This allows you to identify and clean up any inconsistencies in the source data (for example, the date edited is earlier than the date created, or picklist fields are populated with free text).
There is an option to include the cleanup directly in the migration job or to correct it in the source system. Depending on whether the source system is to be used later or not, the correct option must be selected here.
Tip 5: Define and execute integration tests
Without well-designed integration tests, all the preparation is for naught. With large amounts of data, it is important to migrate all records and test the most important properties and records (e.g. support tickets that are still active).
This is the only way to determine whether the migration was successful or not. These tests should be defined in advance and performed by key users. They are the only ones who can logically check the data. A successful integration or migration is therefore only possible with the interaction of several competences.
Conclusion
Data migration from legacy systems to the new system should be approached strategically. This means that conceptual work on what needs to be migrated and why is essential in order to take the right steps. During the migration, the migration engineer is given far too much responsibility, ignoring the fact that he can contribute the technical component, but not always the logical one. This clearly shows why such a project should be properly planned to avoid the pitfalls mentioned above.