Sonoma Partners Microsoft CRM and Salesforce Blog

Upgrading to CRM 2011 - Our Story

We have recently upgraded our own production Dynamics CRM system.  There are numerous sources of upgrade information, best practices, how-to's, etc floating around. The main one you should read and consider is from the Dynamics CRM 2011 implementation guide.

This post is not an in-depth exploration on how to conduct an upgrade (see the implementation guide for that), but more of the some of the decisions, issues, and thoughts we went through during our own upgrade.

First and foremost, you have to PLAN your upgrade.

You need to understand the following:

  • Updates & customizations
    • Script
    • Plug-ins
    • Custom web pages
    • Custom reporting (custom SQL)
    • Services
    • External integrations/applications
    • SharePoint
  • Hardware
    • Are you doing an in-place upgrade?
    • Is your hardware 64-bit capable?
    • Can you bring up new servers or have to use the existing ones?
  • Components installed
    • IFD
    • Email Router
    • Outlook Add-in
    • Reporting Connector
    • 3rd Party applications (such as ExactTarget, Hoovers, etc)
    • Etc
  • Logistics
    • How big is your current db?
    • How extensive is your customizations?
    • Have you done anything unsupported?
    • How much downtime can you allow for the upgrade?


Here is some quick stats on our system:

  • About 45 GB database (upgraded or migrated from the old v1.0 days!)
  • Customizations are fairly basic, contained around a few external web pages, a lot of script, a few plug-ins/workflow assemblies
  • External integrations (corporate web site, Quickbooks, data mart, Word Add-in, etc)
  • Client applications (such as Time Entry, Vibe social networking)
  • Custom filtered lookups and field-level security functionality
  • ExactTarget and Hoover's installed, along with a few of the Microsoft accelerators
  • We also had some simple, custom SharePoint library redirects
  • 1 web server, 1 database server (with Reporting Services), SharePoint server
  • Outlook client across 60+ users
  • Upgraded over the weekend and have everything ready for the organization that next Monday.

As we began our planning, the first thing we had to do was upgrade our web and database servers to 64-bit. As a result, we decided to purchase a new server for the web front end and choose to upgrade our SQL Server, since the db hardware was 64-bit capable already. This allowed us to configure and test the server ahead of time. Also, since we also had to upgrade our SQL Server to 64-bit, we decided to upgrade our production SQL server to 2008 R2 as well.


Then we did the following high level steps:

  • Backup the production db
  • Imported into development environment
  • Regression tested the functionality in CRM 2011, noting everything that didn't work
  • Updated code, customizations, etc on dev (see recommendations, but we focused on native customizations, script, and SQL changes)
  • Created solution package(s) for production deployment
  • Upgraded production db (we did this by taking a backup of the 4.0 database and importing into our new production CRM 2011 environment, since we brought in new hardware)
  • Import dev solution changes
  • Configured new teams, field-level security, enabled auditing, setup document library
  • Configured email router, report connector
  • Tested, fixed issues
  • Took another backup of the database
  • Removed extra entities, attributes, etc for clean-up
  • Deployed Outlook to a smaller pilot group
  • Rolled out Outlook to rest of the organization
  • Upgrading remaining code (see recommendation below)

Recommendations / Tips

  • Try to limit focus of the upgrade
    • You will have needs to include new functionality and approaches, but the more you can just update what you currently have, the easier it is to pinpoint issues from the upgrade, as opposed to issues from new code/functionality.
    • For instance, I would like to clean up my business unit and security role setup. I chose to wait on those updates until AFTER we upgraded, so that I could be sure things worked as they should after the upgrade, as opposed to it being to my clean up.
    • Another example is altering the schema.
      • There are couple of areas that would be prime for a custom activity or I may want to change the relationship. I believe it is far easier to upgrade everything as is, get people working and then make those changes, as there is less to test and it will take less time to get the upgraded completed.
  • Do a Test Upgrade in a development environment
    • Use the new Solution Dependency Tracking, assembly, & Web Resource lists
      • CRM will upgrade all script and images into web resources. I went through this list to understand all the code in the system
      • Similarly, all plug-ins now display in the solution. This made it really easy to see what was in the system.
    • This also allows you to test the upgrade and functionality to give you a baseline.
  • Use as much of the native functionality as you can
    • I removed all our old filtered lookup and field level security scripts and replaced it with the native tools. Same holds true for the forms with sub-grids (which we had previously done with JavaScript)
    • Further I replaced our custom audit with the native audit and our custom document library links with the native SharePoint document library functionality.
  • Take copious notes!
    • I took careful notes of the following:
      • Entities I updated, including ones I wanted to audit
      • Entities, plug-ins, etc I removed.
    • I also keep a log of all the steps I wanted to do for the upgrade.
      • This was critical that we didn't forget steps as we got going
  • Consider upgrading custom code in this order:
    • Scripts
      • Our scripts seemed to have the most trouble working after the upgrade. We had a manageable set of scripts, and many were nullified with the new functionality (inline form grids, filtered lookups, etc)
    • SQL (reporting)
      • Note that deletionstatecode and owninguser fields are deprecated. As such, any custom reporting scripts using those fields will need to be updated to work.
    • Everything else (plugins, etc)
    • Reasoning:
      • The scripts and SQL needed some TLC to work properly, but all of our plug-ins and external applications using the SDK worked like a charm against the old end points!
      • Now, I will go back and move to the new WCF end points, but I didn't need to hold up the entire upgrade for this work to be complete and it means we had less issues with regression testing.
  • Don't forget the new security privileges
    • Custom security roles aren't updated with some of the more core pieces you will need access, such as read privileges to Web Resources, Charts, Dashboards
    • Note the native security roles are updated with the base privileges.
  • Remove ALL isv.config links prior to upgrade and put them back in yourself in development
    • The ribbon XML is extremely complicated to follow and the naming convention of the upgraded nodes is systematic, but not super clear. I found myself fighting random issues more due to trying to update existing upgraded XML, instead of just adding the nodes myself.
    • Along those lines, give yourself some time to work with the ribbon. That was probably one of the areas that took us the most time to update.
  • Clean out your WorkflowLogBase and AsyncOperationBase tables (if they are large) of any processed workflow instances prior to the import.
    • CRM 2011 will attempt to upgrade every workflow process instance to WF4.0 and it takes a really long time, depending on the volume of workflow instances. If you don't need some of those old process instances, then remove them prior to import/upgrade.
  • Bring up a new environment if at all possible.
    • I know many budgets don't allow it, but it simplifies testing and allows you to work out all the connection/authentication type things that can crop up on you. Further, and most importantly, you have a very easy rollback situation in case things get dire during the actual rollout.
  • Have users help test both in dev and immediately after the rollout!
    • This goes without saying, but some of your power users will uncover functionality, issues, etc that you probably didn't know was being used

Upgrade Issues We Experienced
(Keep in mind we upgraded prior to UR1)

  • Workflow rules
    • We had (and are still having at the time I write this) some issues with some upgrade workflow rules being properly evaluated. I'll update this article once we have a solid fix.
  • Reporting connector and email authentication
    • We had some auth issues that had to be resolved after the upgrade. It wasn't difficult to resolve, but just be sure to test the reporting area and any wf emails thoroughly.
  • Outlook 4.0 client *should* work against CRM 2011, but we had some users who had trouble with tracking data from the 4.0 client. We just pushed up the rollout of the CRM 2011 Outlook client, and that rollout went pretty smooth.
  • Various product defects
    • Most are minor and some should be addressed in UR1.
    • We didn't hit any showstopping issues, which was great!