Real-Life Scenario: New Version From a Project Developer

In this scenario, you have initially purchased a project from a vendor whose products are specialized for analyzing sales data. This is project version 1. Over the course of time, your developers have customized objects in the project, resulting in what you called version 1.1 and later, version 1.2., and so on. Now you have purchased version 2 of the project from the same vendor, and you want to merge the new (Version 2) project with your existing (Version 1.2) project.

MicroStrategy encourages vendors in these situations to include in the installation of version 2 an "automatic" upgrade to the project using Project Merge. In this way the vendor, rather than the user or purchaser, can configure the rules for this project merge. For information about executing Project Merge without user input, see Merge Projects with the Project Merge Wizard.

This combination of the two projects creates Project version 2.1, as shown in the diagram below.

The vendor's new Version 2 project has new objects that are not in yours, which you feel confident in moving over. But some of the objects in the Version 2 project may conflict with objects that you had customized in the Version 1.2 project. How do you determine which of the Version 2 objects you want move into your system, or which of your Version 1.2 objects to modify?

You could perform this merge object-by-object and migrate them manually using Object Manager, but this will be time-consuming if the project is large. It may be more efficient to use the Project Merge tool. With this tool, you can define rules for merging projects that help you identify conflicting objects and handle them a certain way. Project Merge then applies those rules while merging the projects. For more information about using the MicroStrategy Project Merge tool, see Merge Projects to Synchronize Objects.