We recently had a Dynamics CRM client with a mature CRM 4.0 deployment move to a brand new start up. They needed to transition their entire on-premise CRM 4.0 setup over to Dynamics CRM 2011 online (complete with new reporting servers, new Active Directory (Office 365), etc.)
They decided upon a re-implementation, based on what's involved in the move from on-premise to online. Now, as there's currently no easy way to achieve this (short of a full data migration effort), and because a data migration effort was already necessary, the client decided to revise their data model and code base and choose a re-implementation.
Comparing CRM Re-Implementation to a CRM Upgrade
For this client, the benefits of a re-implementation were:
a. Scrub of the schema. This allowed cleanup of 5 years of accumulated fields and forms outside of the CRM application.
b. Selective data import. (Example: Inactive contacts older than 3 years were not imported at all)
c. Code optimized for 2011. (Rather than fix the code prior to upgrade or during the import process, the code can be optimized offline.)
d. An opportunity to manage (and include) different data sets other than the Sales CRM instance into the data migration prior to load.
e. For migrations of instance from on-premise to the cloud, where a migration is essential, the opportunities identified above are too good to miss!
Not all of these are mutually exclusive when compared to an upgrade, but they are significantly easier to manage when dealing with a tabula rasa style environment.
To be fair, we should look at the benefits offered by selecting an Upgrade:
a. Automatic data migration.
b. Mapping of Users to the new domain users, and historical mapping of old, unmatched users.
c. Transition of all client side code and database stored plugins.
d. Workflow transitions.
Re-implementation forces a deep dive into the minutiae of the existing CRM environment. This is the kind of thing that would usually only happen when an environment is initially set up, or for certain key releases of functionality. (In the case of the latter, it is still unlikely that the entire application gets reviewed.)
Accordingly, we built a data-map for all entities in the source application that needed to be migrated. This data map also contained details of all forms and views currently in use, and the sequencing and labeling of the included fields.
What followed was a painstaking process of field by field examination by Madrona and the client to evaluate the use and label of each of these fields. Once the data map was confirmed, we planned the migration of the existing CRM data into the new application. Sequencing of this was key, as we were not simply inserting rows into SQL, we were migrating to the online CRM 2011.
Some Final Thoughts On Re-Implementation
Having recently completed this project, here are some key takeaways to consider when evaluating an Upgrade vs. a Re-Implementation:
1. Set expectations early The process of re-mapping needs to be replicated at the testing phase by the client to ensure the data migrations occur exactly as planned.
2. The ability to manage the dataset outside of a CRM environment, and to include new data into the mix during the transition, is an opportunity unique to the re-implementation process If you have a great deal of data normalization to perform (and are due an upgrade) it's worth considering re-implementation.
3. Being able to transition code independent of the data migration is another advantage re-implementation.
4. The relationship between CRM and external reporting teams needs to be established early, and considered a key part of the process With schema renaming and fine tuning of the data migration process, large impacts can be seen downstream for reporting.
If you'd like more information on the benefits and workload involved in Dynamics CRM upgrades and re-implementations, or would like to discuss which of these options may be right for you, call us today at 206.686.8701 ,or
By Madrona Solutions Group, Dynamics CRM and Business Intelligence Consulting, Seattle, WA