---
title: "Data Center to Cloud Migration Guide"
canonical: "https://help.releasemanagement.app/space/RM4J/3196387331/Data%20Center%20to%20Cloud%20Migration%20Guide"
format: markdown
---
> Macro (include)

> 📝 As of June 2026, we provide an automated Data Center-to-Cloud migration bundle (script) that covers the majority of the steps described in the Guide below.
> 📝 
> 📝 *Check out: *[https://releasemanagement.atlassian.net/wiki/spaces/RM4J/pages/4146659330](https://releasemanagement.atlassian.net/wiki/spaces/RM4J/pages/4146659330) 
> 📝 
> 📝 For assistance, please contact the support team using the details provided at the bottom of this page.

# Topics

> Macro (toc)

# Assumptions and considerations

The document is built based on the assumption that the following entities to be migrated in an automated way:

- Packages
  - Main fields
    - Summary
    - Description
    - Start Date
    - Release Date
    - Versions in Package
    - Status (Column)
  - Milestones
  - Tags
  - Comments
- Versions
  - Main fields
    - Summary
    - Description
    - Start Date
    - Release Date
    - Status (Column)
  - Tags
  - ** **Milestones
  - Comments

All other entities are to be manually migrated.

Virtual versions are not covered by this guide.

We assume that before this guide is started, all projects, fix visions, and issues have already migrated from the Data Center (DC) to the Cloud instance

Version and package creation/update dates and original history items will be lost.

Comment author and creation date will be lost

In the guide, we will use new terminology where **Releases** have been renamed to **Packages**

> ⚠️ All manual migration steps should be done before migrating the data via API

# Step 1. Manual entities migration

Some entities are better migrated manually for the following reasons:

- The number of such entities is typically low.
- The manual migration process is straightforward and less prone to errors.
- Writing a script for these cases may be more complex than performing the migration manually.

## Boards

Boards can be manually recreated in the new instance. When doing so, ensure you replicate the permissions assigned to the original board.

## Steps & Transitions

Workflow steps, transitions, and restrictions should also be manually copied between boards.

- If there are numerous boards or steps, an automated guide can be provided.
- To access an API migration guide, contact [support@releasemanagement.app](mailto:support@releasemanagement.app)

## Properties

Manually recreate all properties for versions and packages on the Cloud site as done on the Data Center

## Release Notes

Release notes should be manually copied, with one key adjustment:

- In Data Center packages, `{release.jql}` is used for JQL tables, whereas `{package.jql}` is used in the Cloud.
- Update each JQL table after migration to match this convention.

![image]()

## Gadgets 

Gadgets require manual migration.

- Follow the detailed guide available here - [https://releasemanagement.atlassian.net/wiki/spaces/RM4J/pages/1643544577/Migration+to+Cloud#Annex%3A-Migration-of-Gadgets](https://releasemanagement.atlassian.net/wiki/spaces/RM4J/pages/1643544577/Migration+to+Cloud#Annex%3A-Migration-of-Gadgets).

## Special permissions

Recreate special permissions manually on both global and project levels, such as:

- **Release Management** without project admin permissions.

## Global Properties

Global properties must be created in the Cloud environment before migration.

# Step 2. Main migration flow

The overall flow will look like the one below. The flow is explained on a board basis, so it has to be repeated for each board to be migrated.

1. **Data Extraction from the DC instance**
  1. Get board data
  2. Prepare lookup tables to map DC and Cloud entity IDs
  3. Version Processing
    1. Extract version details
    2. Extract properties values
    3. Extract Milestones
    4. Extract Tags
    5. Extract Comments
  4. Package Processing
    1. Extract version details
    2. Extract properties values
    3. Extract Milestones
    4. Extract Tags
    5. Extract Comments
2. **Data writing to Cloud Instance**
  1. Write package data
    1. Create packages with basic data
    2. Apply the package to the version mapping
    3. Write property values
    4. Create Milestones
    5. Create Tags
    6. Create Comments
  2. Write versions data
    1. Update versions with Tags
    2. Write property values
    3. Update versions with Milestones
    4. Update versions with Comments

# Step 3. Prepare global pre-requisites 

## Authentication

Before starting the work, make sure that the authentication mechanisms are up and running for DC and Cloud instances.

1. **Obtain DC authentication token:** [https://releasemanagement.atlassian.net/wiki/spaces/RM4J/pages/1081347/Swagger+Rest+API+Integrations#How-I-can-get-a-Token-to-access-API%3F](https://releasemanagement.atlassian.net/wiki/spaces/RM4J/pages/1081347/Swagger+Rest+API+Integrations#How-I-can-get-a-Token-to-access-API%3F)
2. **Learn how to obtain a Cloud authentication token. **
  1. NOTE: toke lifetime is 15 mins so this procedure should be repeated before each call to Cloud RM API or within 15 mins timeframe with the same token
  2. A guide: [https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/2445246483/Swagger+Rest+API+Integrations#How-I-can-get-a-JWT-token-to-access-API%3F](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/2445246483/Swagger+Rest+API+Integrations#How-I-can-get-a-JWT-token-to-access-API%3F)

## Entity mapping

The IDs for DC and Cloud are different, so in order to match the entities, we need to create lookup tables that can help us calculate DC and Cloud entities.

The following lookup tables are to be created:

1. **Project ID** DC  -> Project ID Cloud
2. **Version ID** DC -> Version ID on Cloud
3. **Board ID** DC -> Board ID Cloud

> ⚠️ The boards on the Cloud instance should be manually created with the same configuration (project, permissions, statuses, transitions, properties, etc.) before the migration starts.

4. For each board:

> ⚠️ The same columns should be manually created on the Cloud instance before starting this step

- **Columns**
  - **Package column ID** mapping: DC package ID -> Cloud Package ID
  - **Version column ID** mapping: DC version ID -> Cloud version ID
- **Properties**
  - **Package Properties ID** mapping: DC property ID -> Cloud property ID
    - Options mapping for Single and multiselect values
      - DC property ID, DC property value ID -> Cloud property ID, Cloud property value ID
  - **Version Properties ID** mapping: DC property ID -> Cloud property ID
    - Options mapping for Single and multislect values
      - DC property ID, DC property value ID -> Cloud property ID, Cloud property value ID
- **DC Columns and Properties** could be obtained by:
  - **GET** "https://<your_jira_url>/rest/release-management/1.0/board/<board_id>"
  - **Headers**:  "content-type: application/json"

In the response, please find a collection with version and package column ids and their mapping to name. Name will be used to map DC and cloud columns:

![image]()

Extract Properties IDs:

![image-20260330-175639.png](media://496e2584-35b2-4eed-a289-b8d28dc3b9a8)


5. **Cloud Get Columns and Properties IDs:**
  1. GET <u>[https://rmcloud-prd.releasemanagement.app/api/1/board/](https://rmcloud-prd.releasemanagement.app/api/1/board/)</u><board_ID>
  2. In the response:

![image]()

Properties IDs:

![image-20260330-175905.png](media://3ddb7e71-bddb-45e6-9221-6c7467c680f6)


All these lookup tables will be used in the further steps.

# Step 4. Data extraction 

## Before start

1. Pick the board and get this board ID - <board_id>

## Data Extraction Guides

1. <u>**Get the whole board data:**</u>
  1. **GET** "https://<your_jira_url>/rest/release-management/1.0/board/<board_id>"
  2. **Headers**:  "content-type: application/json"
2. <u>**Iterate all packages **</u>
  1. The packages collection is grouped by Column ID so, let’s take column by column and iterate all packages inside each column:
  2. Iterate all columns:

![image]()

3. In each column, iterate over packages, and from each package save:
  1. <u>Release ID</u>
  2. <u>Archived Flag</u>
  3. <u>Dates</u>
  4. <u>Name</u>
  5. <u>Description</u> (not shown in the screenshot, as it is empty, but it will be presented in the response if the value is available)
  6. <u>Version mapping</u>. Ids would be enough, other version data will be later
  7. <u>Properties mapping</u>: The properties are stored in the scope of each package:
4. If needed, in the same way, virtual versions could be integrated and stored (this case is not covered in this guide)
5. As a result, we will get all Packages but without tags and comments
6. <u>**Enrich Packages with Tags**</u> from the same response extract tags from Collection: *Tags-> Releases*

![image]()

4. <u>**In order to get comments**</u>, for each Package ID, execute the request:
  1. *GET https://<your_jira_url>/rest/release-management/1.0/release/comment/<release_id>/comments*
  2. Get the response and store comment values for each package. All other fields are not needed

![image]()

5. <u>**In order to get Milestones**</u>, for each Package ID, execute the request:
  1. *GET *<u>*[https://<your_jira_url>/rest/release-management/1.0/release/](https://demo.releasemanagement.app/rest/release-management/1.0/release/)*</u>*<package_id>/milestone*
  2. As a result, the collection of milestones will be received
  3. For each milestone store:
    1. <u>Name</u>
    2. <u>Description </u>
    3. <u>Date</u>
    4. <u>Archived flag</u>
    5. <u>Archived Date</u>
    6. <u>Collection of triggers</u>

![image]()

As a result, we will get the following structure of the data that should be stored in memory on the disk

- <u>**Package Columns Collection**</u>
- <u>**Package Column id**</u>
  - **Packages collection**
    - Package Id
      - Name
      - Archived
      - Start Date
      - Release Date
      - Description
      - Versions Collection
        - Version ID
      - Tags Collection
        - Tag
      - Comments Collection
        - Comment text
      - Milestones Collection
        - Milestone
          - Name
          - Description
          - Date
          - Archived flag
          - Archived Date
          - Collection of triggers
            - Trigger Id

6. <u>**Iterate all versions**</u>
  1. Use the response to the GET Board request from Step 1.
  2. As with packages, group the version collection by column ID. Each group contains versions belonging to a specific column.
  3. Process versions with the type “JIRA_VERSION”; skip other types, mainly virtual versions.
  4. Do not store all details as with packages; version details should already be migrated to the cloud instance.
  5. Store only the mapping between version ID and column ID
  6. Extract property values. Property values are stored in a separate collection **versionMetaMap. **
7. As a result, we will get a collection column_Id1 -> {version_id1,version_id2,..... }; column_Id2 -> {version_id1,version_id2,..... }
8. <u>**Enrich Version with Tags**</u> from the same response extract tags from Collection: *Tags-> versions. *Actually in the same way as packages

![image]()

8. <u>**In order to get comments**</u>, for each Version ID, execute the request:
  1. *GET https://<your_jira_url>/rest/release-management/1.0/board/<baord_id>/version/<version_id>/comment?versionType=JIRA_VERSION*
  2. Get the response and store comment values for each version. All other fields are not needed:

![image]()

9. <u>**In order to get Milestones**</u>, for each Version ID, execute the request:
  1. *GET https://<your_jira_url>/rest/release-management/1.0/board/<board_id>/version/<version_id>/milestone*
  2. As a result, the collection of milestones will be received
  3. For each milestone store:
    1. <u>Name</u>
    2. <u>isShared flag</u> - it could be skipped as shared milestones are not available in the Cloud
    3. <u>Description </u>
    4. <u>Date</u>
    5. <u>Archived flag</u>
    6. <u>Archived Date</u>
    7. <u>Collection of triggers</u>

![image]()

As a result, we will get the following structure of the data that should be stored in memory on the disk

- <u>**Version Column collection**</u>
  - **Version Column Id**
    - Versions Collection
      - Version Id
        - Tags Collection
          - Tag
          - Comments collection
            - Comment text
          - Milestones collection
            - Milestone
              - Name
              - Description
              - Date
              - Archived flag
              - Archived Date
              - Collection of triggers
              - Trigger Id

## Data set structure after export is done

### Main Data Set

Boards Collection

     Board Id

- Package Columns Collection
  - Package Column id
    - Packages collection
      - Package Id
        - Name
        - Archived
        - Start Date
        - Release Date
        - Description
        - Versions Collection
          - Version ID
        - Tags Collection
          - Tag
        - Comments Collection
          - Comment text
        - Properties Collection
          - PropertyID: Value
        - Milestones Collection
          - Milestone
            - Name
            - Description
            - Date
            - Archived flag
            - Archived Date
            - Collection of triggers
              - Trigger Id
- Version Column collection
  - Version Column Id
    - Versions Collection
      - Version Id
        - Properties Collection
          - PropertyID: Value
        - Tags Collection
          - Tag
          - Comments collection
            - Comment text
          - Milestones collection
            - Milestone
              - Name
              - Description
              - Date
              - Archived flag
              - Archived Date
              - Collection of triggers
              - Trigger Id

### Lookup Tables

- **Project ID**
  - DC ProjectId -> Cloud Project ID
- **Version ID**
  - DC Version ID ->Cloud Version ID
- **Board ID**
  - DC Board ID -> Cloud Board ID
- **Package Column Mapping**
  - DC Board ID, DC Package Column ID, Cloud Package Column ID
- **Version Column Mapping**
  - DC Board ID, DC Version Column ID, Cloud Version Column ID
- **Package Property Mapping**
  - DC Property ID, Cloud Property Id
- **Package Property Values Mapping**
  - DC Property ID, Cloud Property ID, DC Property Value ID,  Cloud Property Value ID
- **Version Property Mapping**
  - DC Property ID, Cloud Property ID
- **Version Property Values Mapping**
  - DC Property ID, Cloud Property ID, DC Property Value ID,  Cloud Property Value ID

# Step 5. Cloud Data Writing

These steps are to be executed for each board.

> ⚠️ Before starting this step, please make sure that:
> ⚠️ 
> ⚠️ - The boards are created in the cloud
> ⚠️ - All Columns are created for packages and versions

## Locate board

From the Board IDs lookup table find a Cloud Board ID

## Write packages

### Create packages 

Please use all entitled IDs from look-up tables to match DC IDs with Cloud IDs (for instance mapping of Column ID)

For each package in the data set execute:

***POST**** *<u>*[https://rmcloud-prd.releasemanagement.app/api/1/package](https://rmcloud-prd.releasemanagement.app/api/1/package)*</u>

**Payload***:*

```
{
   "boardId":"<board_id>",
   "name":"<Name>",
   "description":"Migrated package Description",
   "versionIds":[
      "<version_id_from_lookup>",
      "<version_id_from_lookup>",
      "<version_id_from_lookup>"
   ],
   "virtualVersionIds":[
   ],
   "columnId":"<column_id_from_look_up>",
   "synchronize":false,
   "synchronizeParams":{
      "name":true,
      "description":true,
      "startDate":true,
      "releaseDate":true
   },
   "startDate":"<start_date>",
   "releaseDate":"<end_date>"
}
```

![image]()

In response, the payload with the Package will be received, please store the package id, it will be used for the creation of tags, comments and milestones

![image]()

### Enrich with Properties

PUT [https://rmcloud-prd.releasemanagement.app/api/1/package/<newly_created_package_id>/customField](#)

Payload:

```
{
"property1_Id":"Value_or_value_id",
"property2_Id":"Value_or_value_id",
}
```

### Enrich with Tags

Tags could be taken as strings from the data set

For newly created packages execute the request:

***POST**** **[https://rmcloud-prd.releasemanagement.app/api/1/tag/package/](https://rmcloud-prd.releasemanagement.app/api/1/tag/package/)**<package_id>*

**Payload**:

```
["<add_tag_coma_separated>","<add_tag_coma_separated>"]
```

![image]()

### Enrich with comments 

For each comment in the dataset execute the request:

***POST**** **[https://rmcloud-prd.releasemanagement.app/api/1/package/](https://rmcloud-prd.releasemanagement.app/api/1/package/)**<package_id>/comment*

**Payload**:

```
{"content":"<comment text>"}
```

![image]()

### Enrich with milestones 

For each milestone in the dataset please execute the requests

1. Create Milestone:

***POST**** *<u>*[https://rmcloud-prd.releasemanagement.app/api/1/package/](https://rmcloud-prd.releasemanagement.app/api/1/package/)*</u>*<package_id>/milestone*

**Payload:**

```
{
   "boardId":"<baored_id>",
   "name":"<Milestone_name>",
   "date":"<milestone_name>",
   "packageId":"<package_id>"
}
```

![image]()

In the response, please take the newly created milestone ID

![image]()


2. Update milestone with extra data

Execute request: 

**PUT** <u>[https://rmcloud-prd.releasemanagement.app/api/1/package/milestone/](https://rmcloud-prd.releasemanagement.app/api/1/package/milestone/)</u><milestone_id>

**Payloads**:

Update description:

```
{"description":"new description"}
```

Update achieved flag:

```
{"achieved":true}
```

Update Achieved date:

```
{"achievedDate":"2024-06-11T21:00:00.000Z"}
```

Update Trigger by columns (use columns from lookup table )

```
{"triggerColumnIds":["5e64b408d9a039003ffb1442","5e64b408d9a039003ffb1441"]}
```

> ℹ️ Multiple properties could be changed in a single request.

## Extend versions data

### Enrich with Properties

PUT [https://rmcloud-prd.releasemanagement.app/api/1/board/your_board_id/version/version_id/customField](https://rmcloud-prd.releasemanagement.app/api/1/board/your_board_id/version/version_id/customField)

Payload:

```
{
"property1_Id":"Value_or_value_id",
"property2_Id":"Value_or_value_id",
}
```


#### Map versions to columns

For each version, please execute the request (NOTE: Please mind transition restrictions. Also, all IDs will be taken from look-up tables).

**PUT** [https://rmcloud-prd.releasemanagement.app/api/1/board/](https://rmcloud-prd.releasemanagement.app/api/1/board/)<baord_id>/version/<version_id>/move?columnId=<colum_id>

**Payload**:

```
{"versions":[["<version_id>",true]]}
```

##### Enrich with Tags 

Tags could be taken as strings from the data set

For newly created packages execute the request:

***POST**** **[https://rmcloud-prd.releasemanagement.app/api/1/tag/version/](https://rmcloud-prd.releasemanagement.app/api/1/tag/version/)**<version_id>?type=0*

**Payload**:

```
["<add_tag_coma_separated>","<add_tag_coma_separated>"]
```


![image]()

### Enrich with comments 

For each comment in the dataset execute the request:

***POST**** **[https://rmcloud-prd.releasemanagement.app/api/1/board/](https://rmcloud-prd.releasemanagement.app/api/1/board/)**<baord_id>/version/<version_id>/comment*

**Payload**:

```
{"content":"<comment text>"}
```

### Enrich with milestones 

For each milestone in the dataset please execute the requests

1. Create Milestone:

***POST**** **[https://rmcloud-prd.releasemanagement.app/api/1/version/](https://rmcloud-prd.releasemanagement.app/api/1/version/)**<vesion_id>/milestone*

**Payload:**

```
{
   "boardId":"<board_id>",
   "name":"<name>",
   "date":"<milestone_date>",
   "versionType":0
}
```

![image]()

In the response, please take the newly created milestone ID

![image]()


2. Update milestone with extra data

Execute request: 

**PUT** [https://rmcloud-prd.releasemanagement.app/api/1/version/milestone/](https://rmcloud-prd.releasemanagement.app/api/1/version/milestone/)<milestone_id>

**Payloads**:

Update description:

```
{"description":"new description"}
```

Update achieved flag:

```
{"achieved":true}
```

Update Achived date:

```
{"achievedDate":"2024-06-11T21:00:00.000Z"}
```

Update Trigger by columns (use columns from lookup table )

```
{"triggerColumnIds":["5e64b408d9a039003ffb1442","5e64b408d9a039003ffb1441"]}
```

> ℹ️ Multiple properties could be changed in a single request.

> Macro (include)