Sage CRM 2019 R2: Migrating to Sage CRM (Part 5)

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 -

  • What do we have to do (Scope),
  • How much time do we have to do it (Time),
  • How much money is available to do it (Cost).

And I have also previously discussed that we will have varying levels of access to the application and system data of the source system.

  • We have direct access to the database.
  • We can access data via APIs
  • We can access data via Exports

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

  • What tables/entities are present in the legacy system but are not in Sage CRM?
  • What are the data items (fields) for those new tables? (Name, Data Type, Length)
  • What reports or views are present in the legacy system but have no equivalent in Sage CRM??
  • What entities exist in Sage CRM but are absent in the legacy system? There may be no concept of a Lead in the legacy system.
  • How is "process control" or "workflow" different between the two systems?

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 /accounts
GET /contacts
GET /leads
GET /opportunities
GET /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.