How Do You Plan an On-Premises Microsoft Dynamics CRM Upgrade?

Upgrading an older on-premises Microsoft Dynamics CRM environment requires careful planning, especially when customizations, integrations, databases, and multiple CRM versions are involved. A reliable upgrade plan should account for backups, supported version paths, customization testing, dry runs, user validation, and a controlled production cutover.

For organizations working with legacy Dynamics CRM versions, you’ll need to understand what may break, test the entire upgrade path before touching production, and document each step so the live upgrade can be completed with fewer surprises.

Key Highlights

• An in-place Dynamics CRM upgrade is best suited to environments with few customizations or custom code that has already been evaluated for compatibility.
• Backups should cover both CRM SQL databases and the CRM application server so the environment can be restored if the upgrade fails.
• When several Dynamics CRM versions must be crossed, build and test the complete upgrade path before the production cutover.
• Custom JavaScript, .NET code, reports, integrations, third-party solutions, and direct database access all require review.
• Multiple dry runs, structured user testing, and documented resolutions can significantly improve preparation for the live upgrade.

When Does an In-Place Dynamics CRM Upgrade Make Sense?

An in-place upgrade may be appropriate when the existing Dynamics CRM environment has few customizations or when there is a high degree of confidence that the existing customization code will work with the target version. Microsoft's upgrade planning guidance states that a full backup of the Dynamics 365 / CRM databases should always be run before upgrading to a new version.

Microsoft Dynamics CRM versions can introduce changes to the object model. Code or customizations that work correctly in the existing system may stop working after the CRM platform is upgraded.

Before proceeding, download the CRM SDK for the version being implemented and review its developer documentation. In particular, look at the sections covering “What’s new for developers” and, when available, “What’s changing in the next release.” These resources can help identify changes that may affect existing customizations. Microsoft publishes a "What's changing in the next release" topic in the CRM developer documentation, intended to let organisations plan for changes that affect them on upgrade.

What Should Be Backed Up Before an In-Place Upgrade?

You should be able to restore all related Dynamics CRM environments before beginning an in-place upgrade.

At a minimum, this includes:

• SQL backups of the CRM Organization databases
• SQL backups of the CRM Configuration database
• Windows backups of the CRM application server, including the IIS server

That way, if the upgrade encounters a serious problem, you need a practical path back to the previous working environment.

How Do You Upgrade Dynamics CRM to a New On-Premises Environment?

For more complex upgrades, creating a separate environment provides a place to test the upgrade process without immediately affecting the production Dynamics CRM system.

Start by building the new environment and installing the CRM version you are upgrading to. If the existing system cannot upgrade directly to the final version, install the next supported version in the upgrade chain first. The only supported upgrade path to Microsoft Dynamics CRM Server 2016 was from Microsoft Dynamics CRM Server 2015, so earlier versions had to be upgraded to 2015 first.

For example, a legacy upgrade from Dynamics CRM 2011 to CRM 2016 required progressing through the intervening supported releases:

1. Dynamics CRM 2011
2. Dynamics CRM 2013
3. Dynamics CRM 2015
4. Dynamics CRM 2016

When downtime is a concern, it can be useful to prepare application servers for each CRM version required in the path. This allows the upgrade process to be tested repeatedly without reinstalling each interim version every time. Once the migration is complete, those temporary environments can be decommissioned. Only Dynamics CRM 2011 Update Rollup 6 (version 05.00.9690.1992) or Update Rollup 14 and later could be upgraded to Dynamics CRM 2013.

What Happens During the First Dynamics CRM Upgrade Dry Run?

A dry run lets the project team perform the upgrade against a copy of production data before making changes to the production environment.

Begin by backing up the production CRM SQL databases and restoring them to the SQL environment being used for the upgrade. Then import the CRM organization into the first upgrade environment. Microsoft describes migrating to a new instance of SQL Server as the recommended option for upgrading Dynamics CRM Server, as opposed to an in-place upgrade of the existing databases.

As you move through the process:

1. Record every upgrade error that occurs.
2. Document how each error was resolved.
3. Repeat the process for every CRM version required in the upgrade chain.
4. Configure SQL backups for the new environment, since it is intended to become the production environment.

Documenting errors and resolutions is especially important. When the live upgrade begins, the team can refer to solutions that have already been tested rather than troubleshooting the same problems again under production downtime pressure. During an in-place upgrade only the organization specified is upgraded; additional organizations are disabled and must be upgraded separately using the Import-CrmOrganization PowerShell command or Deployment Manager.

How Should Dynamics CRM Customizations Be Fixed During the Upgrade?

Once the first dry run reaches the final target version, create an unmanaged solution to hold the code changes and customization fixes required to make the upgraded CRM environment work correctly. The Solutions feature can export all unmanaged solution customizations, such as modified forms, views and mappings, for later import into the same or a different organization.

This solution becomes an important part of the upgrade process because it allows those tested fixes to be applied again during subsequent dry runs and the production upgrade.

Before running another upgrade test, export the unmanaged solution from the upgrade environment so the tested fixes are preserved. Microsoft's developer documentation describes an unmanaged solution as a way to group unmanaged customizations into a set that can be transported between organizations.

Why Is User Testing Important Before the Dynamics CRM Upgrade Goes Live?

Users should test the upgraded Dynamics CRM environment while the existing production system remains operational. Microsoft's user acceptance testing guidance recommends documenting 5 to 8 significant business process steps as the test cases to be run during targeted UAT.

Rather than relying on informal testing, assign responsibility to a specific person or team. Give testers a defined list of business processes and functions to verify, and have them sign off as each item is successfully tested. Microsoft advises that no further data migration or solution imports should occur once UAT test cases have been documented and agreed by the development team, testing team and business leads.

This approach helps uncover problems that technical upgrade checks may not identify. A system can complete the technical upgrade successfully while still having problems with the workflows, customizations, integrations, reports, or processes users depend on every day.

Why Should You Perform a Second Dynamics CRM Upgrade Dry Run?

A second dry run confirms that the documented upgrade procedure can be repeated and that the fixes developed during the first test can be applied successfully.

It is also the first opportunity to test importing the unmanaged solution containing the upgrade fixes into a newly upgraded environment. That makes the second dry run an important validation step rather than simply a repeat of the first test.

Before beginning the second dry run, export the unmanaged solution containing the tested fixes from the existing upgrade environment.

Your goal is to prove that both parts of the process work together: upgrading the CRM environment and then applying the customization changes required for the target version.

Which Dynamics CRM Customizations Should Be Reviewed Before an Upgrade?

Any component that depends on the CRM platform, its object model, or its database structure should be reviewed for compatibility.

Common areas include:

• JavaScript web resources
• HTML web resources
• .NET code used by plugins
• .NET workflow assemblies
• Third-party managed and unmanaged solutions
• Custom reports
• Integrations with other systems

Database access also deserves particular attention in older Dynamics CRM environments.

Anything accessing the CRM database directly should use the appropriate objects beginning with the Filtered naming convention, such as Filtered Views. Code or reports using extension base tables also require review because those tables no longer exist in Dynamics CRM 2016. In that environment, filtered views or the appropriate base tables should be used instead.

What Should Be Done Before the Live Dynamics CRM Upgrade?

The production cutover should follow the same process that has already been validated during the dry runs, with additional steps to protect production data and prevent users or services from changing information during the upgrade.

Prepare the Production CRM Environment

Before taking the final production database backup:

• Disable or stop production IIS so users cannot continue logging into CRM.
• Disable the CRM asynchronous services so active asynchronous operations are not running during the final backup.
• Disable the email router service.
• Make any required DNS changes if the existing production URL will be used by the upgraded environment.

These tasks apply to the live production upgrade rather than the earlier dry runs.

Preserve the Tested Dynamics CRM Fixes

Export the unmanaged solution from the tested upgrade environment before starting the production upgrade. This solution should contain the changes required to make the upgraded version operate correctly.

Keeping this package separate allows the team to reproduce the fixes that were already validated during testing.

Perform the Production Database Upgrade

Back up the production SQL database and restore it to the SQL instance used for the upgrade, following the same procedure tested during the dry runs.

Continue through each required Dynamics CRM version until the target version is reached. Once there:

1. Import the unmanaged solution containing the upgrade fixes.
2. Publish the customizations.
3. Import any updated third-party solutions required for the new CRM version.

Because the basic sequence has already been tested multiple times, the live upgrade should follow the documented procedure rather than introducing new steps during production downtime.

What Should Be Tested After the Dynamics CRM Upgrade?

After the upgrade is complete, services and client connectivity need to be restored and verified.

Post-upgrade tasks include:

• Configure the email router service.
• Enable the CRM asynchronous service.
• Check the Windows event log for errors.
• Test Dynamics CRM web client connectivity.
• Test Outlook connectivity.
• Upgrade Dynamics CRM Outlook clients for end users where required.

The email router may not have been fully tested during the dry runs because enabling it could allow CRM workflow rules to send actual email. That makes validation during the production cutover particularly important.

Dynamics CRM Upgrade Process at a Glance

For a complex Dynamics CRM upgrade, it helps to think of the project as a sequence of controlled stages rather than a single software installation. The table below summarizes the process before we look more closely at the testing and production steps.

Upgrade Stage	Main Purpose	Key Actions
Assess the environment	Identify potential upgrade risks	Review customizations, integrations, reports, database access, and CRM SDK changes
Back up existing CRM	Create a recovery path	Back up CRM organization databases, the configuration database, and the CRM application server
Build the upgrade environment	Prepare a safe place for testing	Install the required CRM versions and prepare SQL and application servers
First dry run	Discover upgrade issues	Restore production data, run the upgrade, record errors, and document resolutions
Fix customizations	Address compatibility problems	Update code and customizations and store the changes in an unmanaged solution
User testing	Validate business processes	Test workflows, integrations, reports, and everyday CRM functions
Second dry run	Confirm repeatability	Repeat the upgrade and verify that documented fixes and the unmanaged solution work correctly
Production cutover	Upgrade the live environment	Stop relevant services, take final backups, complete the upgrade path, and apply tested fixes
Post-upgrade validation	Confirm the new environment is working	Restore services, review event logs, and test web, Outlook, and email connectivity

Why Consider Team EASI for Microsoft Dynamics CRM and Dynamics 365 Projects?

Team EASI is a Microsoft-focused technology services firm with more than 22 years of experience working with Microsoft business platforms. Its expertise includes Microsoft Dynamics 365, Power Platform, Azure, Microsoft 365, application development, integrations, migrations, implementation, training, and support.

That background is relevant to CRM modernization because an upgrade rarely exists in isolation. Customizations, integrations, databases, user processes, and other Microsoft technologies often need to be evaluated together when determining how an existing environment should move forward.

For organizations maintaining older Dynamics CRM systems or considering a broader move to modern Microsoft business applications, working with a team that understands both the legacy environment and Microsoft's current platform can help provide continuity from assessment and planning through implementation and support.

Plan Your Dynamics CRM Upgrade Before Touching Production

A successful Dynamics CRM upgrade depends heavily on preparation. Back up the environment, understand the required version path, review customizations, perform multiple dry runs, document problems and their resolutions, and give users time to test the upgraded system before the production cutover.

If your organization is maintaining an older Microsoft Dynamics CRM environment and needs help assessing the upgrade path or determining the appropriate next step, contact Team EASI to discuss your environment and modernization requirements.

By EASI | www.teameasi.com