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.

Sage CRM 2019 R2: Migrating to Sage CRM

1. Introduction
   • Starting to explore the options available to a partner when moving a customer from an existing CRM or contact management system to Sage CRM.
2. What are the typical types of older system? What is the typical database size and complexity?
   • Partners should understand the size of the problem and the opportunity. Getting a sense of typical system can help with planning especially when they may be several customers that need to be migrated and it is desirable to standardise the approach.
3. What are the options for extracting the data from a legacy CRM system?
   • This could range from a flat-file download to only API access.
4. What do we need to migrate?
   • Any project needs to consider its scope with time and resources available. For the migration of legacy data to Sage CRM, we need to take quite a cold hard look at what needs to be brought across whether that is Business Data, Documents, Custom Entities and Business Rules.
5. What are the data differences (structure, terminology etc) between the legacy system and a Sage CRM database?
   • We need to look at the differences in data structures and objects to understand the work that needs to be carried out to all the migration to succeed.
6. How will we maintain data integrity?
   • How will you maintain the integrity of data especially referential integrity as the data moves from one database to another? We want to be able to ensure that all communications, opportunities, notes etc all remain the children of the correct company and person entities and that no orphaned or widowed records are created.

7. What 3rd Party options and partner expertise is available?
   • This last article will look at the different migration tools and services that are available within the partner community.