This is the fourth 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 what exactly needs to be migrated within the project. Any project needs to consider its scope and balance that against the 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.

In the previous article in this series, I discussed how options for accessing a legacy system's data basically boil down to 3 possibilities.

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

Let's assume that whatever option is available to you that you have access to all data from the legacy system and that includes not just the business data but also any files that may have been stored in the old system. But just because you have everything does not mean that you are going to need to move everything into the new instance of Sage CRM.

Any project and this includes a migration project, needs to consider its scope with time and resources that available.

There is nothing intrinsically difficult about a Sage CRM migration project. But if you are going to implement a new instance of Sage CRM successfully then you need to be prepared to be very disciplined in the way in which you approach every part of the project. That is from the very start. How you initiate the project, how you plan the migration actions to be carried out and then how you execute those actions, all require you to have a strong control of the project. This control and discipline need to run from the beginning to the end of the work. It is not just your own actions that need to be controlled and managed but the whole team that includes the customer and users and other stakeholders. You need to be clear about expectations for the migration and how you can measure your achievement of the project goals and what may be the customer's own success criteria.

Management of 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).

If you have managed a project before then you will know that all of these factors - scope, time and cost are interrelated constraints that need to be carefully monitored. A change in one constraint immediately affects the other. All three constraints combine to influence a fourth constraint - the quality of the data being migrated.

One constraint cannot be changed without affecting the others.

They compete against each other, -for example:

• Increased scope (e.g. deciding to bring across all custom entities or all historic documents) typically means increased time and cost. The choices that are made about duplicating workflows or business rules or new entities will by necessity require more time to design, implement and test.
• A tight time constraint could mean increased costs (e.g. adding more people to get the job done on time) and reduced scope (remove certain times of data from the migration).
• A tight budget could mean increased time (not able to hire enough people to get the job done on time) and reduced scope (excluding custom entities).
• Each of these three constraints can impact the fourth constraint, "data quality", and inversely, changing the data quality constraint can affect other constraints, for example increasing the required data quality level for the project can put demands on cost and time. Data Quality within the context of a Sage CRM migration project is about whether a certain entity is brought across, the referential integrity is maintained and that the data is cleaned of duplicated and incomplete data is flagged.

It makes sense that data quality sits in the middle of the triangle being influenced by and acting as an "influencer" on the migration project constraints. The data quality is going to be at the heart of the project.

It is nevertheless an uncomfortable truth that Sage CRM migration projects can, like any IT project, 'fail'. There are different reasons given for that project failure which may include poor requirements definition, inadequate risk management, poor scope definition, communication problems, or lack of qualified resources.

The survey above was for software projects in general and not specifically about Sage CRM. But whatever the reason for failure the experience of that failure sucks.

And what is the biggest reason cited for project failure? Poor requirements definition.

In my next article, I will 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 all the migration to succeed.

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.