This is the fifth article in a short series that is intended to explore the options available to a partner when moving a customer from an existing CRM or contact management system to Sage CRM on-premise.
In this article, I want to consider the data differences (structure, terminology etc) between the legacy system and the new Sage CRM system. We need to look at the differences in data structures and objects to understand the work that needs to be carried out to ensure the migration will succeed.
In the previous article in this series, I looked at the reality that managing a project involves understanding and managing three key elements -
And I have also previously discussed that we will have varying levels of access to the application and system data of the source system.
Is the project team likely to have full access to everything in the source system? Can they access all business data, all business rules and all system data? The team will have to know what they have access to and they have to understand how this relates to Sage CRM.
This preparation is the most important part of a migration project.
Below are just some of the questions about the data structures that need to be asked
The project team will need to make sure that they have assembled the resources they will need. That’s the documentation for both the Sage CRM and the legacy system. And that legacy system will most likely have been configured around the needs of the customer and their existing system needs to be documented to capture the business rules.
The project team needs to confirm any assumptions that they may have concerning access to the data. Not all business data may be exposed if you only have API access to the legacy system.
If your legacy system provides only API access then you may need to think about how the published resources map to Sage CRM structures.
Consider a system offering a REST API
It may have endpoints that approximate to Sage CRM structures.
GET /accountsGET /contactsGET /leadsGET /opportunitiesGET /users
When data is imported into Sage CRM from another system it would typically need to be transformed to match the Sage CRM data model. For example, an entity representing a customer would need to be split over multiple tables such as company, person, person_link, address, address_link, phone and email.
You would need to make sure that you are familiar with the Sage CRM data model. A simplified version of the Sage CRM application data model is available on the Community.
That is why a project team should create a test instance of Sage CRM so the assumptions can be tested.
The next article is going to consider how will data integrity can be maintained as the data is migrated. We want to be able to ensure no orphaned or widowed records are created as the data is moved from the legacy system to Sage CRM.