I am currently beginning a project to migrate from Microsoft Dynamics CRM 4.0 to Microsoft Dynamics CRM Online and thought I’d document it so I remember all the mistakes, missteps and dead ends I encounter on the way.
We are aiming to begin the migration at the end of October and have planned 3 months to complete the switch over, not a lot of time when all the customisations have to be recreated as there is no migration path and there is only one developer doing it.
The Current System
First thing to do is review the current system and find any obvious pain points.
The current system architecture is simple enough:
- All On-Premise Servers
- One SQL Server running 2008 R2 hosting the Databases
- One CRM 4.0 server, serving the front end, webservices and Async Service
- One Server hosing the Email Router
- Two groups of users
- One who exclusively uses Outlook 2007 to access CRM
- One who exclusively uses the Web Interface to access CRM
|Total Database size||285GB|
|Number of Users||120|
|Number of Email Router Users||20|
|Number of integrations||6|
|Number of custom entities||72|
|Number of customised entities||4|
|Number of Workflows||146|
|Number of custom Workflow Activities||36|
|Number of Plugins||18|
Now, those numbers look scary, let’s break them down a bit and see if they can be lowered at all.
Total Database Size
285GB. Two Hundred And Eighty Five Gigabytes.
That’s an awful lot of data when CRM Online comes with just 5gb and additional data is 6.20 GBP per GB per month; over 20,000 GBP per year, what is it all being used for and can we lower it?
A quick trip to SQL Server Management Studio and a run of Disk Usage by Top Tables later shows that 46.9% of the space is used by email attachments.
Accounts and Contacts? Less than 2GB. A few more queries show that this database contains data going back to 2008, a total of 8 years of data that has never been cleaned.
We can definitely reduce this number.
Number of custom entities
72 custom entities. That’s 42% of the entities that CRM 4.0 comes with as standard. Surely they aren’t all used?
No, no they are not. Another area that has never been cleaned up, maybe as many as 10 are currently still in use, the others are failed experiments and leftovers from finished programs.
10 is much more manageable.
Number of Workflows
146 Workflows. That’s just crazy talk; we can take it down to 131 straight away as 15 are draft and obviously not in use.
Let’s run an Advanced Find and see when they were last used. 17 Workflows have been used in this year, 37 in the last 2 years.
Now we’re getting somewhere.
Now we have more information and can clearly see that this is a possible migration. A lot of unused customisation is going to be disposed of and the data will need a good scrub on its way through the migration scripts.
The next step is to look at those integrations we glossed over before.