MicroStrategy ONE

Merge Projects to Synchronize Objects

You can use MicroStrategy Project Merge to synchronize a large number of objects between projects. Project Merge streamlines the task of migrating objects from one project to another. While you can use Object Manager to copy objects individually, Project Merge can be used as a bulk copy tool. For differences between Object Manager and Project Merge, see Compare Project Merge to Object Manager.

The rules that you use to resolve conflicts between the two projects in Project Merge can be saved to an XML file and reused. You can then execute Project Merge repeatedly using this rule file. This allows you to schedule a project merge on a recurring basis. For more details about scheduling project merges, see Merge Projects with the Project Merge Wizard.

Project Merge migrates an entire project. All objects are copied to the destination project. Any objects that are present in the source project but not the destination project are created in the destination project.

  • If you want to merge two projects, MicroStrategy recommends that the projects have related schemas. This means that either one project must be a duplicate of the other, or both projects must be duplicates of a third project. For information about duplicating projects, including instructions, see Duplicate a Project.
  • To merge two projects that do not have related schemas, the projects must either have been created with MicroStrategy 9.0.1 or later, or have been updated to version 9.0.1 or later using the Perform system object ID unification option. For information about this upgrade, see the Upgrade Help.
  • Project Merge does not transfer user and group permissions on objects. To migrate permissions from one project to another, use a project security update package. For more information, see Copy Objects in a Batch: Update Packages.

Projects may need to be merged at various points during their life cycle. These points may include:

  • Migrating objects through development, testing, and production projects as the objects become ready for use.
  • Receiving a new version of a project from a project developer.

In either case, you must move objects from development to testing, and then to the production projects that your users use every day.

Topics covered in this section include: