Share

Dynamics CRM 2015: Upgrade Options

Dynamics CRM 2015 is a major CRM upgrade for CRM On Premises. In the past with upgrades like CRM 4->CRM 2011 and CRM 2011->CRM 2013, it was always a best practice to set up new servers and import upgrade your CRM environment to the new version. This was because there were major changes in system requirements and user experience between major versions.


Typically, changes to SQL Server, Windows, processor architecture, or other factors would preclude doing in-place upgrades in most cases. Also, the user interface would usually change in a major way, requiring fairly lengthy reconfiguration or updates to form layouts.

That’s why I would always recommend doing an import upgrade—it was less risk than upgrading in place, and resulted in less downtime, as the customization would always need to be upgraded post the server upgrade.

But we are in a different world now. Gone are the 4 year spans between new versions. Now we get one every year (and a mid year update that is sometimes pretty major in its own regard). This shift has changed my thinking on upgrade best practices.

If you compare CRM 2013 requirements with CRM 2015 requirements, you will see that they are almost identical. Sure, if you installed CRM 2013 on SQL 2008, you will need to move to SQL 2012 for your CRM 2015 deployment. But if you used SQL and Windows 2012, your servers will be fine for CRM 2015.

From a functionality perspective, CRM 2015 introduces many great new features. But these are iterative on top of what was introduced in 2013. After your environment is upgraded to 2015, many end users won’t know anything has changed—they will see the results when you introduce rollup fields, hierarchical security, dashboards on tablet app and other new features to your configuration, but from a user experience, 2015 upgrade is closer to a service pack than a historical major version upgrade.

So given this shift to more regular, less user shocking upgrades, my thinking on upgrade best practices has shifted to to following:

  • For many on premises deployments that have new servers using the latest versions of Windows and SQL Server, in-place upgrades may be the preferred upgrade method, as long as the upgrade is thoroughly tested first in non-production environments.
  • For very complex customizations or large enterprise deployments that have ample server/virtual host availability, import upgrades will probably still be the preferred upgrade methodology.