--- title: "Multi-project snapshots" canonical: "https://support.appfire.com/space/CMJ/197825512/Multi-project%20snapshots" format: markdown --- > Macro (aura-html) ## Deploy multi-project snapshots **Multi-project snapshots** are [project snapshots](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197956922) that contain the configuration of two or more selected projects. A multi-project snapshot can include the issues of the selected projects if it is created as a [project with issues snapshot type](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198247183). Read our [Single-project snapshots](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197857553) document if you want to deploy a snapshot with only one project. The deployment of multi-project snapshots starts with [providing a deployment snapshot](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197857553) on CMJ’s **Deploy** page. The deployment goes through the following phases: 1. **Select** phase - In this phase, you can use the [advanced options](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198021794) to select elements you want to skip merging during deployment. 2. **[Analyze](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197825592/Analyze+phase?atlOrigin=eyJpIjoiZjAzNTkxODQ3YTEzNDNlNWJiZTY3MmYxMGE4ZWVlMzciLCJwIjoiYyJ9)** phase - In this phase, CMJ performs deep change and impact analysis of the changes that the deployed snapshot will introduce on the target Jira instance. 3. **Migrate** phase - This is the issue migration phase. It’s only required when issues on the target Jira are incompatible with the snapshot configuration. To learn more, see the list of cases that require [issue migration](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197923086/Issue+migration?atlOrigin=eyJpIjoiM2IzMTRkOTJiOTVlNDRiYmE5MWNjZGNmZmVhNTA2NDQiLCJwIjoiYyJ9). 4. **Deploy** phase - This is the final phase of the deployment process. In this phase, you must confirm that you want to apply the configuration and issues from the selected snapshot to your Jira instance. The deployment of multiple-project snapshots works by “**merging**” the projects' configuration and issue data from the snapshot into the target Jira instance. This document explains how “merging” works when [deploying project configuration snapshots](#Deploy-a-%E2%80%98Project%E2%80%99-snapshot) and [projects with issues snapshots](#Deploy-a-%E2%80%98Projects-with-issues%E2%80%99-snapshots). ![Snapshot-Multiple-Projects.png](media://2b7a5f19-e58b-4a50-af05-b06b301f96ce) ### Deploy a ‘Project’ snapshot When you deploy a snapshot containing multiple projects and their configuration, CMJ applies the project configurations in the snapshot to the **target Jira **instance. When merging project configurations, CMJ applies the following rules to the target Jira: - All configuration objects from the snapshot that don't exist on the target Jira instance will be **added**. - If a snapshot and a target configuration object have the same name/id, CMJ compares both objects. If they are different, CMJ will **replace** the target object with the object from the snapshot. - CMJ **doesn't delete** or change configuration objects on the target Jira instance if they don’t exist in the snapshot. **An exclusion: **a configuration object will be deleted if it is a **non-root (child) **object. > ℹ️ **Merging root vs. non-root configuration objects** > ℹ️ > ℹ️ CMJ applies different rules when merging root and non-root configuration objects. A configuration object represents a piece of Jira configuration. There are two types of configuration objects: **root** and **non-root** (also known as **child**). For example, *workflows* are root objects, and *custom field contexts* are non-root objects. You can find a full list of root and non-root configuration objects in the [What is a configuration object](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197892733) document. #### **Example** Let's assume you have the following: 1. A **workflow scheme **called "*Dev Code*" is an example of a **root** configuration object. 2. The **Jira Service Management request types** "*A*," "*B,*" and "*C*" as examples of **non-root (child)** objects. Suppose you're performing a deployment, and these objects will be merged into the target project. Check the table below to see if and how CMJ will change the target workflow scheme and request types in each use case. | **Configuration object** | **In the snapshot** | **In the target Jira** | **Result** | | --- | --- | --- | --- | | Workflow scheme “Dev Code”[root] | :check_mark: Yes | :cross_mark: No | A new workflow scheme “Dev Code” will be **added** to the target Jira instance. | | Workflow scheme “Dev Code”[root] | :check_mark: Yes | :check_mark: Yes | The workflow scheme “Dev Code” in the snapshot will** replace** workflow scheme “Dev Code” in the target Jira instance only if there are differences between the two workflow schemes. Otherwise, the target project will not be changed. | | Workflow scheme “Dev Code”[root] | :cross_mark: No | :check_mark: Yes | The workflow scheme “Dev Code” in the target Jira instance will stay as it is and **will not be deleted**. | | JSM request type[child] | Request types “**A**”, “**B**” | :cross_mark: No request types | Request types “**A**” and “**B**” are **added** to the target instance. | | JSM request type[child] | Request types “**A**”, “**B**” | Request type “**A**” | The target instance will contain request types “**A**” and “**B**” after request type “B” is **added**. | | JSM request type[child] | Request types “**A**”, “**B**” | Request types “**B**”, “**C**” | The target instance will contain request types “**A**” and “**B**”. ”C” will be **deleted.** | What if you don’t want to replace a configuration object, let’s say, the workflow scheme “Dev Code” in the target Jira instance? The **Selective Merge** feature in CMJ allows you to create and assign a new scheme instead. Learn more in our [Selective Merge documents](https://appfire.atlassian.net/wiki/pages/createpage.action?spaceKey=cmj&title=Selective%20Merge&linkCreation=true&fromPageId=197825512). > ℹ️ **Merging Jira Service Management project snapshots** > ℹ️ > ℹ️ Knowing which objects are considered root and non-root and how merging issues works is very helpful for understanding the results of the deployment of a Jira Service Management (JSM) project snapshot. A JSM snapshot includes: > ℹ️ > ℹ️ - the standard Jira project configuration (mostly root objects), > ℹ️ - Jira Service Management-specific configuration (mostly non-root objects), and > ℹ️ - *(optionally)* issue data. > ℹ️ > ℹ️ Each of these three JSM project snapshot elements follows the merge rules relevant for its type. ### Deploy a ‘Projects with issues’ snapshots When deploying a[ project snapshot with issues](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198247183), the projects and their configuration objects will be “merged,” as explained in the [Deploy a 'Project' snapshot](#Deploy-a-%E2%80%98Project%E2%80%99-snapshot) section. **Issue data **in the snapshot includes the issues in the selected projects and all their comments, links, history, worklog, custom field values, agile data, etc. For including **issue attachments** in the snapshot, read more about [Moving attachments](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/197825295). #### **How CMJ imports issue data?** There are two cases of importing issues and related data when deploying a multi-project snapshot**.** **A. **Some or all of the matching projects on the target Jira instance **do not contain issues**. In this case, all issues and their data are imported into the empty projects on the target Jira instance. **B. **Some or all of the matching projects on the target Jira** **instance** already contain issues**. In this case, if the same issue exists both in the target project and in the snapshot, **this issue will not be imported**. Issues not existing in the target project will be imported with all their data. For more information on migrating projects with issue data, please refer to our use case document: [https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198279348](https://appfire.atlassian.net/wiki/spaces/CMJ/pages/198279348)