This is the fourth article within a short series that explores the options available to a partner when moving a customer from Sage CRM Cloud edition (sagecrm.com) to Sage CRM on premise.
In this article, I want to consider what needs to be migrated.
In my previous article, I discussed how there were basically three broad options for getting hold of the data in the cloud edition of Sage CRM.
We could use the standard features of Sage CRM to export selected contact information, or use either the RESTful or SOAP Web Services to extract data from the Cloud instance or we could download backups of the database and the document library.
Let's assume that you have downloaded everything from the original cloud instance in the form of a database backup and the document library. 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. For the migration of the Cloud edition to on-premise 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.
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 a failure the experience of that failure sucks.
And what is the biggest reason cited for project failure? Poor requirements definition.
The next article is going to consider the physical differences between a Sage CRM Cloud Edition database and a Sage CRM on-premise database. There are differences in data structure and objects that need to be understood in order to plan the work that needs to be carried out for the migration to succeed. Once you understand the differences between the two systems you will be able to make an informed decision about the scope of the migration project.
Migrating a SageCRM.com database to an instance of Sage CRM 2018 R3
Links to all the articles in the series