Share via

Microsoft Dynamics CRM Upgrade Tips and Considerations

  • Article

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 article 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 you can consider for own upgrade. It is based on personal upgrade experience as told by Jim Steger.

First and foremost, you have to PLAN your upgrade. 

Skills & Knowledge

Before starting the 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?
    • an 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?

Microsoft Dynamics CRM requires 64 bit hardware for the servers. If you need to upgrade your hardware, also consider moving to SQL Server 2008 R2.

Even if upgrading to SQL Server 2008 R2 is not an option, consider migrating just reporting services to 2008 R2 version - the enhancements and new features are well worth it.

Upgrade Steps

Here is a sample upgrade high level steps:

  • Backup the production db
  • Imported back up into a development environment
  • Regression tested the functionality in CRM 2011, noting everything that didn't work
  • Updated code, customizations, etc on dev (see recommendations, but focus on native customizations, script, and SQL changes)
  • Created solution package(s) for production deployment
  • Upgraded production db (for example, take a backup of the 4.0 database and import into your new production CRM 2011 environment if you bought 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, if you plan to clean up business unit and security role setup, you may want to wait on those updates until AFTER you have upgraded,, so that you can be sure things worked as they should after the upgrade, as opposed to it being part of the clean up.
    • Another example is altering the schema. There may be a couple of areas that would be prime for a custom activity or you may want to change the relationship. Againl, it may be 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
    • If you used to have code for a filtered lookup, field level security scripts or sub-grids on form, consider using the native approaches now.
    • Further consider replacing custom audit code with the native audit. Same for custom document library links with the native SharePoint document library functionality.
  • Take copious notes!

    • Be sure to take careful notes of the following:

      • Entities updated, including ones you want to audit
      • Entities, plug-ins, etc removed.

    • Finally keep a log of all the steps you need to do for the upgrade.

      • This is critical to avoid forgetting steps during the actual upgrade

  • Consider upgrading custom code in this order:

    • Scripts
      • Some scripts may have trouble working after the upgrade. Try to update those using the new SDK client model.
    • 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 the plug-ins and external applications using the SDK should work against the old end points!
      • This gives you a chance go back and move to the new WCF end points, after the upgrade, and you there do not need to hold up the entire upgrade for this work to be complete and it means you will have 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. You may find yourself fighting random issues more due to trying to update existing upgraded XML, instead of just adding the nodes yourself.
    • Along those lines, give yourself some time to work with the ribbon. That was probably one of the areas that takes 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.
    • Many budgets may not 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

Additional Resources

[[Microsoft Dynamics CRM Overview|Return to Dynamics CRM Overview]]