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.
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 -
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:
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