When I started writing this blog on how to upgrade from CRM 4.0 to CRM 2011, it occurred to me that there are already several great blogs out there on the subject so rather than regurgitate what already exists, I will add a few links here and then focus on the issues behind upgrading and your customizations. Here are some great links on how to upgrade to CRM 2011: and .
If you do not have many customizations, the upgrade seems to go like any other upgrade you have done before, but if you have a lot of customizations like Rockton (www.rocktonsoftware.com) does, you will probably be surprised just how difficult it can be to get everything to work like it did before the upgrade.
In CRM 4.0, we have a custom ASP.NET web application that resides in the supported ISV folder of the CRM 4.0 website. These pages do a lot of different things, but they are mostly used for background server processing. For example, you select 20 accounts and click a button. That button pops up a progress window that passes the GUIDS of the selected accounts to an ASP.NET page using AJAX. The ASP.NET page processes the records and when finished, returns a response back to the processing page to let the user know if the transaction was successful or not. This is a pretty standard feature of any web application.
Our web application also hosted about 40 JavaScript libraries. We would host them out there and then modify them using a multi-color, intellisense aware IDE like Visual Studio, then just add links to the libraries inside the CRM forms. This allowed us to not only share code better but also make changes outside the CRM editor. This way you do not have to click your way out 10 times and publish in order to see if your changes worked.
Outside of the web application, we have several custom workflow assemblies that we can use when building workflows that need to do more than what can be done with the steps that come with CRM 4.0 out of the box.
For our upgrade, we chose to add an additional server, install SQL Server 2008 R2, CRM 2011, and import our production database, so I could experiment with the new deployment without affecting our day to day CRM operations. The first thing I noticed was that the links from the CRM forms to the JavaScript libraries did not migrate over correctly and copying the existing web application to the ISV folder of the new CRM 2011 ISV folder did not help.
I spent about a week troubleshooting issue after issue with very few successes. After much frustration, I decided that it was better to pay for support rather than spend any more time on the issues. Almost 2 days with support went by and after many different changes and configuration file modifications, it was clear that this was just not going to work.
With all of this and the fact that we were planning on eventually moving to CRM online someday where there is no ISV folder for your custom web application, I decided to drop the custom web application all together and devise a solution that would also work online.
I created a new un-managed solution and re-coded all of the JavaScript libraries to use the new XRM page model rather than the crmForm model and added them to the new solution as web resources. This is not necessary but will make the next upgrade easier without having to worry about backward compatibility.
I created plugins to replace the processing that was previously being handled by ASP.NET pages. The way I chose to do this was to create a new custom Process entity. For example, you now select 20 accounts and click a button that pops up an html progress page. JavaScript inside the html page creates a new Process entity record using the REST endpoint and adds the GUIDS of all the selected accounts to a field on the Process entity. A plugin fires in the create stage of the Process entity that processes the records accordingly. If an error or exception occurs, a Process Detail record is created that details what happened and gets linked to the Process record. JavaScript inside the html progress page checks the status of the process every second and when complete either tells the user all was successful or displays a link that the user can click to drill down into the details of what went wrong.
Writing all of these plugins to replace the ASP.NET code gave me a great knowledge base of how things are done in CRM 2011. The next issue I ran into is that we have many different custom workflow assemblies, and there are several different nuances between how you code CRM 4.0 workflow assemblies compared to CRM 2011 workflow assemblies. Because of these nuances, the experience I received from writing all the plugins, and because of the fact that CRM online does not support custom workflow assemblies, I re-coded all of our custom workflow assemblies into plugins. This goes surprisingly fast once you have a firm grasp on how to code plugins.
Our public website is driven 100% by CRM and did not require a single change other than to point the web service references to the new server. This was a pleasant surprise. So it does appear that some things are 100% backward compatible but many things are not and you will have to consider that before you start down the upgrade path.
Curious about Rockton Software's New Product Launch for CRM?
Don't have Microsoft Dynamics CRM? Download the CRM Software Blog's white paper, "24 Wildly Creative Ways Companies Use Microsoft Dynamics CRM to Drive Revenue and Serve Customers" to learn more about how CRM can improve your business, or get started with a quick online quote today.
Written By .
