-
-
Notifications
You must be signed in to change notification settings - Fork 230
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
5e84119
commit c0e9b38
Showing
1 changed file
with
16 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -73,7 +73,7 @@ Here is a reference sheet with all of the default fields in Azure DevOps: <https | |
|
||
Here is a reference sheet with all of the default link types in Azure DevOps: <https://learn.microsoft.com/en-us/azure/devops/boards/queries/link-type-reference?view=azure-devops>. | ||
|
||
## 4. Guideline for migrating multiple projects | ||
## 5. Guideline for migrating multiple projects | ||
|
||
### Scenario 1: Single project | ||
|
||
|
@@ -118,7 +118,7 @@ For example, let us say you are migrating the Jira projects A, B and C in sequen | |
7. Export project C into **workspaceC** | ||
8. Import project C1 | ||
|
||
## 5. What is the purpose of the --force flag? | ||
## 6. What is the purpose of the --force flag? | ||
|
||
Here you will find a description on what the `--force` flag does under various circumstances. | ||
|
||
|
@@ -127,7 +127,7 @@ Here you will find a description on what the `--force` flag does under various c | |
| Jira Exporter | Items in the migration workspace (local) will be overwritten. | Items already downloaded in the workspace will be skipped. Items in the workspace will remain intact. | [jira-export.md](https://github.com/solidify/jira-azuredevops-migrator/blob/master/docs/jira-export.md) | | ||
| Work Item Importer | Work Items in ADO will remain intact. New duplicate work items may be created. | Revisions which already have been imported will be skipped. Existing Work Items may be updated with new data if the incoming revisions have not already been imported. | [wi-import.md](https://github.com/solidify/jira-azuredevops-migrator/blob/master/docs/wi-import.md)| | ||
|
||
## 6. How to migrate custom fields having dropdown lists? | ||
## 7. How to migrate custom fields having dropdown lists? | ||
|
||
- To map a custom field which is an dropdown list you can use MapArray mapper to get in a better way. | ||
Also take a look at the other possible [Mappers](config.md#mappers) to use. | ||
|
@@ -144,7 +144,7 @@ Example: | |
} | ||
``` | ||
|
||
## 7. How to migrate correct user from Jira to Azure DevOps and assign to the new work items? | ||
## 8. How to migrate correct user from Jira to Azure DevOps and assign to the new work items? | ||
|
||
- User mapping differs between Jira Cloud and Jira Server. To migrate users and assign the new work items in Azure DevOps to the same user as the original task had in Jira, we need to add a text file in the root that would look something like this: | ||
|
||
|
@@ -186,7 +186,7 @@ Example: | |
[email protected][email protected] | ||
``` | ||
## 8. How to migrate the Work Log (Time Spent, Remaining Estimate fields)? | ||
## 9. How to migrate the Work Log (Time Spent, Remaining Estimate fields)? | ||
You can migrate the logged and remaining time using the following field mappings. | ||
|
@@ -211,7 +211,7 @@ The history of the **logged time** and **remaining time** will be preserved on e | |
} | ||
``` | ||
|
||
## 9. How to map custom user picker fields | ||
## 10. How to map custom user picker fields | ||
|
||
Here is how we have successfully mapped user picker fields in the past. `source` should be the field name: | ||
|
||
|
@@ -224,7 +224,7 @@ Here is how we have successfully mapped user picker fields in the past. `source` | |
}, | ||
``` | ||
|
||
## 10. How to map datetime fields | ||
## 11. How to map datetime fields | ||
|
||
Here is how we can map datetime fields like ResolvedDate: | ||
|
||
|
@@ -236,7 +236,7 @@ Here is how we can map datetime fields like ResolvedDate: | |
} | ||
``` | ||
|
||
## 11. How to migrate an issue fields to a comment | ||
## 12. How to migrate an issue fields to a comment | ||
|
||
Through some manual intervention, we can migrate every historical value of an **issue field** to a **Work Item Comments**. Simply do the following: | ||
|
||
|
@@ -260,7 +260,7 @@ Through some manual intervention, we can migrate every historical value of an ** | |
- `e0cd3eb0-d8b7-4e62-ba35-c24d06d7f667` > `System.History` | ||
1. Run `WiImport` as usual. | ||
|
||
## 12. How to omit the Jira issue ID/key in the work item title | ||
## 13. How to omit the Jira issue ID/key in the work item title | ||
|
||
By default, the field mapping for `System.Title` will be set up so that the title is prefixed with the Issue key. This can be prevented by omitting the **MapTitle mapper** from the field map in the configuration: | ||
|
||
|
@@ -281,7 +281,7 @@ Instead of the default: | |
} | ||
``` | ||
|
||
## 13. What are the base-area-path and base-iteration-path properties in the config.json file? | ||
## 14. What are the base-area-path and base-iteration-path properties in the config.json file? | ||
|
||
**`base-area-path`:** | ||
The `base-area-path` property in the migrator configuration specifies the root area path under which all migrated work items will be placed. This path organizes work items into different functional or project areas within Azure DevOps. | ||
|
@@ -298,7 +298,7 @@ The `base-iteration-path` property defines the root iteration path for the migra | |
|
||
In such cases, you may need to create a mapping strategy to translate Jira project components to Azure DevOps area and iteration paths. This might involve some manual configuration and planning to ensure that the migrated work items fit into the desired structure. See the next section in this FAQ for a guide on how to map sprints, iteration paths and area paths. | ||
|
||
## 14. How to map sprints, iteration paths and area paths | ||
## 15. How to map sprints, iteration paths and area paths | ||
|
||
It is possible to do custom mappings of the **Jira Sprints** as **Iteration Paths**, and vice versa for **Area Paths**. | ||
|
||
|
@@ -357,7 +357,7 @@ This will set the Iteration path correctly. The final path will be like the foll | |
- `<project name>\<base-iteration-path>\<mapped value>` | ||
- `<project name>\<base-area-path>\<mapped value>` | ||
|
||
## 15. How to migrate Development Links (commit, PR, branch) | ||
## 16. How to migrate Development Links (commit, PR, branch) | ||
|
||
If you have previously migrated your BitBucket git repositories to your Azure DevOps Server/organization, you can also migrate the development links of the Jira Issues to the corresponding ADO Work Items. | ||
|
||
|
@@ -379,7 +379,7 @@ In your configuration file, you must specify the following properties: | |
|
||
The **repository-map** must contain a key-value lookup table with the names of the Bitbucket git repositories and their translations in ADO. | ||
|
||
## 16. How to limit the number of issues to be exported during JIRA export (pagination) | ||
## 17. How to limit the number of issues to be exported during JIRA export (pagination) | ||
|
||
If you export or the whole migration takes too long, you can achieve something similar to pagination by limiting the export to batches of issues through the `query` property of your `config.json` file. Simply enter a JQL query that filters issues on the `ìd` property, for example: | ||
|
||
|
@@ -393,7 +393,7 @@ And so on. | |
|
||
You can always use the **issues** view in your Jira project to experiment with different JQL queries. | ||
|
||
## 17. I get https response code 400 and a System.Aggregate Exception with the warning "Failed to get item count using query ...", and no items are exported | ||
## 18. I get https response code 400 and a System.Aggregate Exception with the warning "Failed to get item count using query ...", and no items are exported | ||
|
||
The issue is usually a malformed query. Make sure that you have tried all of the following solutions: | ||
|
||
|
@@ -416,7 +416,7 @@ curl -D- | |
"http://johnie:8081/rest/api/2/search" | ||
``` | ||
|
||
## 18. Sprint names are corrupted. ADO Iteration paths are named "[ synced = false ]" | ||
## 19. Sprint names are corrupted. ADO Iteration paths are named "[ synced = false ]" | ||
|
||
The issue is usually that a custom field has been defined in Jira which is also named "Sprint", and the tool is picking up this field instead of the default Srpint field. | ||
|
||
|
@@ -446,7 +446,7 @@ It seems that for jira server, the field IDs can different between different dev | |
|
||
Give it a try and let me know if it still does not work. | ||
|
||
## 19. Azure DevOps Rate and usage limits (ADO Cloud only) | ||
## 20. Azure DevOps Rate and usage limits (ADO Cloud only) | ||
|
||
In the unlikely event that you experience issues with being rate limited by Azure DevOps, we always recommend the following procedure: | ||
|
||
|