Upgrading Dynamics CRM can be a big task. Everyone from the developers to the end users need to be aware of the scope of changes with the new release, the impact it will have on their current deployment, and the time it will take to implement, test and deploy. So, upgrading across multiple releases can be downright scary. Multi-release upgrades can magnify the effort several times depending on the complexity of the solution.
Many companies can understandably find themselves in a multi version upgrade situation. Organizations may not be able to afford the time it takes to upgrade their system given constraints around development resources, scheduling downtime, and active customer feature requests. So upgrades are put off repeatedly and the they fall behind in releases. With Microsoft’s recent switch to a more aggressive release schedule for Dynamics CRM, just keeping up on the changes can be a full-time job.
I have been assisting a customer with upgrades from CRM 2011 On Premise to CRM 2016 On Premise. They previously upgraded a highly customized (and in many ways unsupported) CRM 4 deployment to a nearly 100% supported CRM 2011 implementation. They have multiple CRM deployments and the upgrade/migration for each had their own challenges but each team did a great job in planning for subsequent upgrades.
With all of the general preparation, each upgrade still requires a solid plan for execution. In this and subsequent posts, I’d like to share some of the planning approaches, challenges, and “gotchas” that we’ve seen during an ongoing migration. The system that we are currently migrating is a very large CRM 2011 On Premise xRM solution, leveraging much of the out of the box capabilities while greatly expanding with custom code and custom entities.
Planning for your upgrade
Before diving into my customer’s experience, we can take a look at some very high level topics to consider. This is by no means the definitive list but it should be a nice starting point for the discussion.
- What resources will you need?
Your team will need some environments to do your work. With an On Premise deployment, this can mean new servers, new hosted virtual machines, or new developer virtual machines. Setting up these environments can be costly in both dollars and time, so it needs to be considered as early as possible - How does this affect your current production system?
What happens to the current production system while you upgrade? Will you provide new features and updates while the upgrade effort is taking place? With large migrations, this can cause a LOT of churn and possible issues with merging updates. Your management team will need to consider a code freeze at some point during the process - What steps will you need to take in your migration?
If you have a large solutions that includes a large amount of code with a complex schema, how do you sync the customizations and source code? This does not seem like it would be complicated, but planning out the stages/steps in advance can save time for your development team - What about all of the cool new features?
With major releases, you usually see some new feature that you want to leverage. Some new features may not be relevant while some may be extremely easy to implement. However, other features might require data migration and process changes. Planning time for your team to review new capabilities during the migration can be key to making the most out of the CRM platform - How will you test your migration?
If your current solution is supported and you follow all of the steps provided by Microsoft, it should just work, right? Well, sure… but that is an awful big leap of faith to take with this project! A full regression test of your system will likely be required, so pulling in your end users and QA team as early as possible can help greatly - How will you complete the final migration and deployment?
When everything is complete, your solution is migrated and tested, how will you go about the final deployment? As with any system roll out, your team should plan for down time, end-user testing, remediation, and acceptance. If your upgrade included any data migration or transformation steps, this will need some extra testing and validation
My customer experience, part one
The first step in planning my customer upgrade was a review overall solution and choose an upgrade approach based on Microsoft recommendations. We know that the solution is large and complex, so we knew that we needed to take a staged approach. Fortunately, you can find a solid amount of material on upgrade planning with Microsoft online at the following link: https://technet.microsoft.com/en-us/library/hh699716.aspx#BKMK_Upgradeoptions
The first thing that Microsoft offers are three approaches to your upgrade. Our team chose the first option listed:
Migrate by using a new instance of SQL Server. We recommend this option for upgrading Microsoft Dynamics CRM Server. Although this option requires a different computer for Microsoft Dynamics CRM 2016 and a different instance of SQL Server, it provides the least amount of potential downtime for users since the existing deployment can remain functioning until the upgrade is completed and verified.
What this means choice for our migration: our team took the approach of leveraging the Deployment Administrator Organization Import feature to upgrade the database on a new machine. Right away, we had infrastructure resource requirements: a new CRM 2016 instance on which we would perform the upgrade. Unfortunately, a CRM 2011 database cannot be imported to a CRM 2016 instance, so we also needed an instance of CRM 2013 and CRM 2015. My customer has an excellent team that provides virtual infrastructure so they provided us a few new virtual machines for the upgrade, such as the CRM 2013 and 2015 instances required for import, three CRM 2016 dev sandboxes, and a CRM 2016 testing sandbox. The development team quickly had the resources to begin testing some of the initial migration steps and reviewing new CRM 2016 functionality.
A staged approach
Another decision the team made was to simply port the system and get a functional CRM 2016 instance with the current solution customizations. This would allow us to get a working solution in front of our customers very early and get some feedback. This also meant that we did not need the code ported and working to get the system in front of the users. We would disable any of the scripts that caused errors or required migration, disable any plugins and workflows that would cause problems, etc. Essentially, we wanted to present users with the coming attractions.
This approach is important because with the CRM 2013 release, we knew that the user interface saw a massive overhaul, so the user experience would change drastically. So my customer wanted to get their users on board and familiar with the upgraded system as soon as possible. We aimed to avoid major shock by the end-users when they saw the new user interface for the first time while providing some early training, gathering early feedback, and to simply gathering ideas by the customer. It’s great to see users participate with conversations often sounding like, “Oh, that’s cool. Can you also make it do this too?”
While the end users are reviewing the updated system, the development team is able to proceed with the code migration analysis, including plugins, workflows, scripts, etc. This exercise allowed planning our iterative releases to the user team and QA team. Basically, how do we roll out the migrated features to the end users? Even though we are simply porting over the current functionality, some of the areas are very complex. Performing an analysis of the code base allowed the team a chance to review features and functionality that they may not have addressed in some time, provide insight into a testing and release planning, while at the same time, deciding what new functionality can be leveraged with the new release. For example, would Business Process Flows benefit the end users? What JavaScript can be ported over to business rules? Where can we use Actions effectively? All of these items would be tracked in preparation for a later stage in the migration.
All coming together…
So, with some of these decisions for approach, our big picture plan started taking shape. Very high level steps for the migration included:
- Migrate the CRM database from CRM 2011 to CRM 2016
- Disable any broken functionality
- Present to the end-user team
- Begin code migration and upgrade
- Evaluate new capabilities available in CRM 2016
- Begin iterative releases to QA and end-user testing
With this high level plan, we have some actionable steps to take as a team a plan that gets us in front of the customer early and often!
Next steps?
In my next post, I will go into some of the details on the database migration steps. These are fairly well documented but we ran into a few situations that are worth a discussion!
In the meantime, any comments, feedback, and corrections are welcome!