This is part 2 of my previous post which helps identify tips and gotchas of CRM 2013 upgrade. Click here to read the first part: Top 10 Upgrade Tips and Considerations (part 1).
So it’s time to upgrade to CRM 2013 and the questions we always get are:
What is the impact?
What do I need to do to make sure my organization will continue to work in CRM 2013?
What are the tips and tricks for upgrading to CRM 2013?
How can I estimate the effort to upgrade?
So I will attempt to provide a checklist of the top 10 most common aspects of the upgrade that you should keep in consideration. In my previous post I addressed the top 5 and and here are 5 additional considerations/tips:
Because of the limited mobile functionality of CRM 2011 (mobile express) it is easy to assume that there is no effort required to migrate your mobile express application to CRM 2013 except perhaps some testing effort. However, if you are thinking of taking advantage of the new mobile application (e.g. CRM for tablets) in CRM 2013 then you need to consider that if you are in On-Premise you might need to include additional effort to enable IFD if it is not already configured. Mobile application in CRM 2013 is only supported with claims authentication and IFD mode. Additionally, if you have third party mobile solutions (e.g. Resco, CWR) then refer to the previous paragraph.
If you have used the new forms of CRM 2013 you might have noticed the new Auto-save feature. By default, users are not required to click “Save” when updating a record. Every 30 seconds after editing a field, the form will automatically submit a save request in the background. Clicking some commands such as “new”, “qualify” or closing the form will also issue a save request to the server (note: it does not apply to the create form).
The impact of auto-save is that each auto-save is an update operation in the database so plugins and workflows will trigger and auditing will occur. You need to consider that if the user takes 2 minutes to update a form, then at least 4 updates will actually occur on the server side.
So why is this important for upgrade? Well, you could argue that this is nothing to worry about since this behavior corresponds to how some users are actually saving multiple times in fear of losing their updates, but it is now done automatically. I tend to agree with that but in reality some developers do not consider those type of users when designing plugins or workflows. You need to ensure that your plugins and workflows will not break because of auto-save; one typical recommendation is to limit the “triggering attributes” of an update plugin to only those fields that when changed should really trigger the plugin. This is more of a review exercise and you might not need to make any changes.
On the client side each time auto-save occurs, the fields that changed in the server will be refreshed in the form, but the OnLoad event will not be triggered because the form will not be refreshed. You need to ensure that your form scripts will not break because of this new behavior and if necessary you might need to use the new GetSaveMode() method on your OnSave scripts to identify how the save originated. You can use this same method to prevent auto-save from occurring by intercepting the OnSave and discarding any save originating from auto-save.
Note that you also have the possibility to disable auto-save at the organization level which might make things easier to manage since you don’t need to assess the exact impact of auto-save when upgrading to CRM 2013. However, I think auto-save is a great feature and should not be disabled for the wrong reason (e.g. laziness to manage the upgrade impact).
7. New forms, sitemap and navigation
Inevitably your forms and sitemap will need to be reviewed since the navigation and user experience changed so drastically in CRM 2013. It is very likely that you will need to re-design your forms because the new layout is different and you might want to take advantage of the new form features such as the social pane. You will also need to consider the command bar and make sure your 5 visible commands are actually the most common ones, otherwise you might need to adjust the command bar (ribbon). Keep in mind that in CRM 2013 the form tab index has disappeared so if you had large forms in CRM 2011 divided in multiple tabs, users will now need to scroll down to find the tab they are looking for and there is no quick access tab index as we had in CRM 2011. In general, CRM 2013 goes with the principle of simplicity and usability so you might need to simplify your forms, include less fields, maybe split your large forms into multiple forms, etc.
In terms of sitemap, you might have noticed how different it is to navigate different parts of the application. For the most part according to feedback from the community, it has become harder to be efficient when navigating between different modules of the application. Consider the scenario of a service representative talking to a client and then generating a lead from the conversation. The service representative might need to change from “Service” to “Sales” often and this is much harder to do in CRM 2013 as you might need to scroll horizontally to find your entity and the navigation will also disappear by default requiring more clicks to bring it back. Therefore, you might need to optimize your sitemap for your organization to keep users happy with CRM and minimize the amount of time they spend switching areas. For example, making sure that the most common entities appear first in each area so users don’t have to scroll every time to reach the entity tile they need to work with.
8. Migrate customizations to built-in features
While you might be sure that your customizations will continue to work after the upgrade, it would be great to consider whether you can “un-customize” the system and migrate some of those customization to use built-in features that are configurable. This will of course increase the amount of effort for the migration but will simplify your deployment and make it more maintainable down the road, it is usually an “easy” sell for customers since the advantage is very evident.
Another example of this is customers that use third party mobile solutions for simple mobile scenarios that can now be supported with CRM 2013 built-in mobile features. If you migrate to the built-in mobile features then you will save considerably on infrastructure, maintenance and licensing.
Unless you are working with hosted CRM (e.g. CRM Online), infrastructure is always something you need to consider. I suggest you review the CRM 2013 implementation guide and review all the infrastructure considerations. If you are doing an upgrade, it is always recommended that you setup a parallel environment in CRM 2013 to which you will import the CRM 2011 organization instead of doing an “in-place” upgrade because it will make it easier to do multiple trials and have a better roll-back strategy. It is supported to import CRM 2011 organizations to a CRM 2013 deployment and upgrade the organization during the import. Once the upgrade completes you can decommission the CRM 2011 environment.
Keep in mind that the server and client minimum requirements have changed for CRM 2013 so you need to ensure that you are covered from all angles (operating system, browser support, SQL version, etc.).
Another infrastructure-ish consideration is to have a strategy around the extension tables merge. If you are not familiar with this, here is a brief explanation: In CRM 2011 each entity has a base table and an extension (e.g. custom fields) table. As part of the performance improvements of CRM 2013, these two tables are now merged into a single table. Therefore, when you upgrade an organization from CRM 2011, the table merge is one of the upgrade operations, but it is a special one for a number of reasons:
- It is not a required upgrade step. You can skip this step and continue to use your upgraded organization. However, there might be some performance implications by not merging the tables
- Depending on the data volume, it can take a long time to merge these tables which can considerably increase your downtime during upgrade
- If you decide to skip this step, you can always perform it in the future (another downtime window will be required).
Therefore, when you start testing your upgrade, if you notice that it takes a really long time you might want to defer the table merge to a later date. This way you can split the downtime into 2 different time windows. In order to defer the table merge, there is a registry setting that you need to set during upgrade and then to perform the merge at a later date you need to run the CrmMergeBaseAndExtensionTableTool.exe tool located in the CRM server under c:\Program Files\Microsoft Dynamics CRM\Tools.
10. Avoid platform-only upgrade
If you are upgrading to CRM 2013 and are just doing a platform upgrade (upgrade as is, no changes to current customizations), then you should think twice the question: Why do I need this upgrade? CRM 2011 is still supported for some years so the primary motivation for an upgrade is to take advantage of the new features. So if you are just doing a platform upgrade, then the upgrade motivation is questionable.
My recommendation is that when you start the upgrade discussion with your customers, start delivering the message early on that there are multiple advantages of CRM 2013 and that the upgrade is just a great opportunity to explore these. Consider the upgrade planning as the opportunity to adapt your CRM deployment and customizations to whatever CRM 2013 has to offer, simplify the deployment and maintenance of your environment while keeping end users happy and engaged with the application by providing them great new features.