As a veteran of many Dynamics CRM upgrades, I’ve come to identify and expect many of the pitfalls and opportunities that come with upgrading CRM from one version to the next. However, a recent experience caused me to re-evaluate these assumptions.
We had a client with a mature CRM 4.0 deployment moving from their host company to a brand new start up. They needed to transition their on-premise Sales CRM 4.0 instance in its entirety to Dynamics CRM 2011 online, with new reporting servers, new Active Directory (Office 365), etc.
What finally moved them to decide upon a re-implementation was the move from on-premise to online. There is currently no easy way to achieve this short of a full data migration effort (potentially using the new Microsoft Instance Adapter), and because a data migration effort was going to be involved anyway, the client decided to take advantage of the opportunity to revise their data model and code base, hence the re-implementation.
Comparing CRM Re-Implementation With CRM Upgrade
The benefits of a re-implementation for this client were:
- Scrub of the schema. 5 years of accumulated fields and forms were all cleaned up outside of the CRM application
- Selective import of data. Inactive contacts older than 3 years were not imported at all. The same logic applied to activities, leads, deactivated accounts, and attachments.
- Optimization of code for 2011. Rather than fix the code prior to the upgrade occurring, or during the import process of the 4.0 DB to a 2011 DB, the code can be optimized offline.
- An opportunity to manage and include different data sets other than the Sales CRM instance into the data migration prior to load.
- 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 are significantly easier to manage when dealing with a tabula rasa style environment.
For parity, the upgrade path offers the following benefits:
- Automatic migration of data.
- Mapping of Users to the new domain users, and historical mapping of old, unmatched users.
- A transition of all client side code and database stored plugins.
- A transition of workflows.
Re-implementation forces a deep dive into the minutiae of the existing CRM environment. This is otherwise only really done 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 is reviewed.)
Accordingly, a data-map was constructed for all entities in the source application that needed to be migrated. In addition, 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 members of our West Monroe team and the client to evaluate the use and label of each of these fields (sample below). Due to the scale of the project, we identified a single resource on the West Monroe team to own the schema map process and document. We all contributed, along with the client, and the schema master ensured that our versioning was maintained.
Sample: The red highlights indicate a field no longer needed. Note the schema renaming:
Once the data map was confirmed, we began planning the migration of the existing CRM data into the new application. Clearly the sequencing of this was key, as we were not simply inserting rows into SQL, we were migrating to the online CRM 2011, and so we need to use the API at all times.
Final Post Re-Implementation Thoughts
Having recently completed this project, we had some key takeaways as it relates to this debate that we will take into our next project of this type:
- Set expectations early that the process of re-mapping, as time consuming as it is, needs to be replicated at the testing phase by the client so as to ensure the data migrations occur exactly as planned
- 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 that is unique to the re-implementation process. If you have a great deal of data normalization to perform, and are due an upgrade, it is worth considering re-implementation for this alone. In this case, we on-boarded a Support function into CRM along with the Sales team, and used this process to merge Account and Contact data
- Code transition was excellent. Being able to do this independent of the data migration was a great plus. This and the schema change opportunity are the stand-out advantages of the re-implementation.
- The relationship between CRM and external reporting teams (in this case, a data warehouse team that had been doing weekly extracts from CRM) 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 especially if they are using GUIDs as key identifiers.
Finally, based on our experience, here is a comparative table of each:
|Moving from on-Premise to Online.||Not applicable. Even if you upgrade to match the current version you still need to migrate to the cloud via re-implementation.||Essential.|
|Data Migration.||No risk.||Complicated. Complete field mapping required, plus design of the migration process itself and sequencing of the imports.|
|Data integrity.||No risk.||Higher risk due to re-structure of data. Not able to fully replicate all deactivated system users in CRM online either (need to map to a service account instead).|
|Data model changes.||Complicated. Can only be completed either live in the source application pre-deployment, or once upgraded.||Easier.|
|Removal / culling of data.||Done only via the CRM user interface and bulk deletes, or a third party API tool.||Easier.|
|Merging and adding additional Data.||Complicated. Traditional data migration with downstream effects (data clean up and de-duplication).||Managed outside of CRM, much simpler insertion into the CRM application.|
|CRM SSRS Reports.||Reports are moved over into the new instance automatically. The reports are not tested automatically.||Reports have to be optimized offline and deployed anew to the re-implemented instance.|
|Other Reports.||Aside from a change of Organization name or hardware, the data model and guides will all remain identical.||Potentially complicated dependent upon reporting model. If a schema re-structure has occurred, commensurate work may be required with reporting model.|
|Code Optimization.||Either let the upgrade process tell you where you code has failed (or the upgrade may even fail!) and then fix.||Re-implementation forces a code review, due to schema revision. Code situation will not prevent successful data migration. Easier for developers.|
|Workflows.||Upgraded automatically. May need fixing is dependent code breaks.||Need to be manually re-created.|