Comparing Instances in a Microsoft Dynamics 365 Environment

One has to be living under a rock for not knowing the versatility and the scalability feature of Microsoft Dynamics 365 CRM in today’s business environment. Compared to the other CRM products that are available in the market, Dynamics 365 stands out as a highly flexible and comprehensive solution provider. The product can be tailor-made as per the client’s requirements, industry, or even the last-minute change that the Consultant might have thought of to provide ease of business. The size of the organization isn’t a challenge at all, because Dynamics 365 CRM fits like a glove everywhere.

Instances in a Microsoft Dynamics 365 Environment - AhaApps

Most companies are looking for an ‘out of the box solution, and D365 has the range to provide the same. I can go on and on about why most enterprises are making the switch from their current CRM software to Microsoft Dynamics 365-with its filters feature it provides an effective and better decision-making environment for the staff, business owners are on the winning side with more customers to cater, information silos are done away with, and so on.  With a best practice methodology encouraged by Dynamics 365, business improves.

But the blog isn’t about that. I want to discuss a specific challenge that certain enterprises may face and how a knowledgeable Consultant could have prevented that.

Problem:

We have multiple instances (test instance and Production instance) of Dynamic CRM in our organization. Due to some reasons, all the environments are not in sync (some customizations usually go missing in test environments).

Background: 

Every organization follows a pattern to implement new enhancements or fix bugs into a production environment. We can make our changes directly in the production environment, but we avoid this step, as it isn’t a best practice. Therefore, we need to have a Dev environment and testing environments (such as QA and UAT) along with the production environment. Our cycle starts with developing/ customizing in Dev and then promoting it to test environments. Once it passes all the test cases, then we promote it to our live environment (production environment).

Reason:

The regular pattern may break sometimes due to some odd circumstances. But to make it simple, I’m going to provide you a reason as an example, where this problem may occur.

A business in an organization has requested a new enhancement that has a lot of components involved. The developers did a great job and it went to production by going through all test cases. Soon a new test case was discovered. This new test case was the reason that the enhancement was failing and unfortunately, there was a challenge in reverting and amending it. As the business was getting affected, a quick fix was requested.

Let’s say, one of the developers named John came up with a plan and thought of working in UAT because there was no time for going through the entire regular process (developing in dev, unit testing, promoting to QA and testing in QA, promote to UAT and test in UAT and finally promote to prod). John fixed the issue and promoted it to production, and he saw that everything was working fine. However, John forgot to make that change in other test instances and dev instances.

Just remember there are few Johns in an organization and there are few enhancements or hotfix items that need to be addressed quickly.

In case if we lose track of those customizations, the instances will not sync. If you want to compare different instances or check whether they are in sync or not, then this article will provide you with the best possible solutions that are available.

Solution: 

You can compare it with Microsoft products:

  • In the SDK bin folder, you can find SolutionPackager.exe. This is a tool that is useful to reversibly decompose a compressed solution file into multiple XML files and other files.
  • Download the default solution for the instances that need to be compared (you can use any unmanaged solution but needs to be the same on each instance).
  • Create batch file named Extract Customizations.bat.
    • solutionpackager /action:Extract /zipfile:Instance1\Default_1_0.zip /folder: Folder1
    • solutionpackager /action:Extract /zipfile:Instance2\Default_1_0.zip /folder: Folder2
  • Run the batch file.
  • Once the folders (Folder1 and folder2) are updated, then we need to compare these files with online comparer tools such as Beyond Compare.

This example just goes to show that there needs to be a vigilant developer who remembers all the customizations during the initial stages. This will prevent a challenge cropping up and hampering the client’s business.

Most businesses as we know run on trust and most organizations would want to ally with solution providers who can use trust, honesty as their trademark.

We are known for building long-lasting relationships with our clients that go beyond the walls of the board rooms. So, connect with us and we can tell you how we have been solving our client’s CRM challenges.

Download our CRM Checklist

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons