This is the second in a short series of articles on Sage CRM Developer Best Practices. I mentioned in my first article that I would discuss the project pain points that the participants had identified and how they can be overcome by careful preparation.
There is no magic wand that will remove the problems associated with inheriting an existing system with unknown customisation and incomplete project documentation. There may be no magic wand but there are several things that can start to mitigate the problem.
The first thing that needs to be done is to take stock. In an ideal world, a full 'service history' of a customer installation will be available. The initial project documents should exist. These are the ones that are supposed to describe the scope of the customisation, and business rules and workflows that were to be implemented. There should also exist follow-up documents that describe any later customisation or changes that have been made.
If you are lucky the project will have updated versions of the
Or their equivalents.
Depending on the version you are using these can all be found in the Partner Documentation folder or within the Help Center.
Sage CRM is a very plastic and easily changed system and System Administrators and consultants may make ad hoc changes that cause the system to drift away from the original definition. It can be a profoundly unsettling experience to discover that a system is documented to have one set of customisation but in reality may have a different set of configurations.
You can gather all the documents, you can read and understand what the system was originally like but when facing an upgrade or an extension project you still need to know what the system is really like now and what changes have been made. To do that you need to to have a baseline and to be able to make a detailed comparison with a default unmodified system and the system with which you are confronted.
Sage CRM is a metadata driven system so the place to start is in the database. You can examine that to tell you which screens, lists and fields have been added, and which have been changed or had scripts and rules added to them, and where calls to ASP and .NET assemblies have been made.
I have published previously a small collection of SQL scripts that I use to investigate changes between a 'vanilla' database and a customised one.
You can find the latest set of " SQL Scripts used to Investigate changes in Database" in the "Example Components and Developer Resources" download folder.
The example scripts will
But these are only examples of how you can use SQL to investigate the changes made to a system. You can expand these to cover all aspects of the system.
Once you have your baseline and you are secure in your understanding of the state of the system, that is you are confident you understand how its business rules work and the extent of its existing customisation, you then need to consider what any specific upgrade of the system requires.
Here you are going to need to think about changes to supported environments, browsers, server software, office software and even the database.
The Hardware and Software Requirements document and the Release notes for each version will become essential reading. If you want to avoid pain this is not a step that you can short cut.
If you are like me and don't enjoy reading technical articles there is a short training lesson available that discusses some of the things to consider ahead of an upgrade.
In the next article, I'll start discussing the project management and communication factors that can influence project success.