Approach to migrate from CRM2011 On-Premise to CRM2016 On-Line
[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][fusion_text]One of the challenges in migrating data from an old CRM installation that runs on premise to a new online instance is, there is no simple way or assistant driven solution for that. For a real project we had the requirement to move a CRM2011-OnPremise environment to a new CRM2016-Online environment. In the following I try to describe the approach we used and the traps you can run into.
The source system
CRM 2011 OnPremise was heavily customized in 2 entities (accounts and opportunities) and some minor customizations in the contacts and leads. The customer used CoreMotive as marketing tool. The CRM was used by marketing and sales.
There were about 50.000 active accounts, 130.000 active Contacts, 50.000 active leads and 6.500 open opportunities to transfer. The system had around 400 user (active and inactive) that owned the data.
The destination system
CRM 2016 Online should be the new system. The customer wanted to expand the CRM to use service as well and especially field service. At the same time keep the old functionality for sales and marketing. To keep the storage as low as possible the new system should include SharePoint as document-storage as well. The new system at the end is a CRM2016 online with the field service solution activated. For customer surveys additionally the “Voice of the customer” addon was choosen.
The customer used CoreMotif as marketing add on inside the old CRM. As CoreMotif for Dynamics CRM is end of life, the customer decided to switch to ClickDimensions instead. This situation made it impossible or rather too expensive to migrate 100% of the marketing functionality as the 2 products use different data structure and delivers different features and functionality.
So the new environment had CRM 2016 with field service, voice of the customer and ClickDimensions activated.
The migration path
As a complete migration would have transferred the old notes and activities (including attachments), we proposed to keep the old system running and switch the user access-license to read-only to avoid blowing up the database on the online tenant. To enable users to access the old data we implement-ted a hyperlink-field on the forms that would open the data in the old system. This approach removed the need of migrating the old activities and made it a lot easier to migrate.
At the end we proposed to migrate the following entities (including a hyperlink to open this data in the old system):
- Active Accounts
- Active Contacts
- Open Opportunities
- Active Leads
- Active Campaigns
- Static Marketing Lists
Dynamic Marketing Lists should be rebuild manually as there only were few of these.
The tools and systems used
As tool we used Microsoft SQL-Server 2014 with SSIS and additionally the Dynamics CRM-Tools for SSIS from Kingsway Soft. So the final setup looked like that:[/fusion_text][fusion_imageframe lightbox=”no” gallery_id=”” lightbox_image=”” style_type=”none” hover_type=”none” bordercolor=”” bordersize=”0px” borderradius=”0″ stylecolor=”” align=”center” link=”” linktarget=”_self” animation_type=”0″ animation_direction=”down” animation_speed=”0.1″ animation_offset=”” hide_on_mobile=”no” class=”” id=””] [/fusion_imageframe][fusion_separator style_type=”none” top_margin=”20″ bottom_margin=”” sep_color=”” border_size=”” icon=”” icon_circle=”” icon_circle_color=”” width=”” alignment=”center” class=”” id=””/][fusion_text]As the Kingsway-SSIS-Extension only were used on the developer laptop and no distributable ETL-Package was created there will be no license fees to use that tool.
Things to be in place before starting the migration
- Add a text field for the old GUID on all migrated entities
- Rebuild all custom fields on the migrated entities that should be used in the future system. Take a detailed look with your customer on the fields, forms and processes bound to these entities. In reality an old system often has fields that wasn’t used in the past and could be removed in the new solution.
- Turn off the automatic Geo-Coding in the field service setup, as this will return an error when running the ETL-Package and geo-coding is not possible because data is missing.
- List all custom entities used in the migrated entities into your ETL-Package as well. In the given case the customer had added custom entities and lookups to this in the entities that should be migrated.