Other than my CRM Online customers, the rest of my customer base which are using on premises systems still run CRM 2011 and are looking to upgrade to CRM 2015. While my customer base is a small subset of the microcosm, I am betting they are not alone. This is a high level overview that I will modify and embellish over time.
This upgrade will need to be done in stages and will require an intermediate upgrade to CRM 2013.
Step 1: Upgrade your SQL server system if necessary:
CRM 2015 discontinues support for SQL Server 2008 / 2008R2
However CRM 2015 continues to support Windows 2008 / 2008R2
Step 2: Any CRM 4.0 SDK solutions will no longer be supported, so make sure that all of your solutions are using the CRM 2011 SDK as a starting point. This includes all of your plugins, custom workflows, web applications and scheduled applications that use the CRM API.
Step 3: it is recommended that CRM 2011 should be updated to Rollup 14 before starting.
Step 4: Run the Custom Code Validation Tool to test your JavaScript Form customizations. http://blogs.msdn.com/b/crm/archive/2012/06/21/microsoft-dynamics-crm-2011-custom-code-validation-tool-released.aspx
Step 5: Run the Legacy Feature Check Tool to see if you are still using any CRM 4.0 API calls.
Warning: Inventory any SQL Views or direct SQL queries or updates that you may have created against the actual CRM database tables. It is recommended to always use the CRM Views and not access the CRM database directly, but in the event that you did anything unsupported, the Base and Extension tables will be merged at the end of this process.
Running the CRM 2013 Upgrade
There are 3 upgrade options ranging from upgrading In-place which is over the top of your existing system to migrating your data from your existing CRM system to a completely new CRM 2013 system.
If you have VM’s you will want to try the In-place upgrade first as it updates similar to a rollup and if successful is the fastest.
CRM 2013 Modifications
Optional 1: Most of the XRM systems I’ve worked on have numerous plugins that fire when the vast majority of the CRM entities are modified. If you have a large number of plugins that fire like this and your system could be bogged down by frequent saves by your users, you may consider disabling the new Autosave feature in 2013 at least initially.
http://blogs.msdn.com/b/crm/archive/2013/10/15/manage-auto-save.aspx
This feature can be disabled on a form by form basis later.
Optional 2: Microsoft recommends migrating to the new forms created for each entity in 2013. The CRM 2011 forms will be named “Information”. The new 2013 forms will have the entity name like “Account”. From the new entity form there is a Merge feature that will pull the customizations from the 2011 form and put those customizations at the bottom of the form. There will be some work to clean these forms up.
Optional 3: You can merge your database in 2013 however this is a required step in the CRM 2015 Upgrade, so I prefer to let the latest upgrade code take care of this step. This is the merger of the Base and Extension tables in the CRM database.
Running the CRM 2015 Upgrade
There are 3 upgrade options ranging from upgrading In-place which is over the top of your existing system to migrating your data from your existing CRM system to a completely new CRM 2013 system.
Since this is the step when the database tables will be merged, I would suggest going with the MS recommendation to migrate from the Updated 2013 system to a fresh CRM 2015 system especially on a production system. If you have VM copies to play with, upgrading In-place is less of a risk.
CRM 2015 Modifications
MS says that CRM 2015 will use CRM 2011 SDK plugins but substitute calls to the 2011 SDK with calls from the CRM 2015 SDK.
However there are some important changes that need to be handled.
As of CRM 2015 Update 1 which is currently only used on CRM Online as I type this. For plugin registration the SetState and Assign messages have been deprecated. Ownership and the state of an entity can now be changed using Update rather than separate AssignRequest and SetStateRequest messages.
Once your plugins are registered to fire on “Update” make sure to set their filtering attributes to be appropriate “ownerid” and “statecode” for example and you may need to check your execution order if you have other plugins firing on the Update of an entity.
