Jira importer - technical evaluation
With Jira Importer - Status quo discovery (#434808 - closed) we gained information on status of the currently available Jira importer.
That investigation confirmed that Jira importer is in an incomplete state as it doesn't import anything but Jira issues title, description, and labels only (see).
There's also a dependency on Jira issue integration that needs to be set up before it's possible to use the importer.
What Jira importer should be capable of
The high-level details of what the Jira Importer should be capable of where noted in here. Repeating here:
- Issue import improvements part 1 (for DataCenter and other versions later) - This would satisfy a vanilla import use case for issues
- Comments
- Attachments
- Status as a label - Allow mapping to an existing label
- Issue relationships (blocking, blocked, related)
- Retain link to GitLab MRs
- Custom fields in the issue description
- Jira subtasks to GitLab tasks (maintain the relationship)
- Epic import - This iteration would create a viable import experience.
- Epics as epics (instead of issues with a label)
- Issue relationships to epics
- Issue import part 2 - These items would be nice-to-haves
- Time tracking import
- Links
- Mapping of custom fields to individual labels
- Component as a label
- Priority as a label
- Resolution as a label
- Fix_version as a milestone
- Out of scope
- Mapping milestones/iterations to sprints - Mapping dates across both systems would be very difficult.
Importing chosen projects data from Jira to GitLab is expected to be a one-off process.
What this investigation issue should answer
- Why current importer depends on integration? Is it possible not to have this dependency?
- From technical POV, would it be better to implement an importer from scratch as oppose to continue developing the current code?
- Which best practices (batched migrations, workers idempotency) used in other importers could be readily implemented in the Jira importer?
- Roughly, what proportion of the total effort would be saved if we would base the Jira importer on importer framework, assuming the framework already existed?
- There are Jira Server, Data Center and Cloud. Possibility to import out of Jira Server is the most urgent. Is it necessary to have 3 separate importers or is it possible to have only one? If one importer serving three sources is possible, would it be better to start from covering Jira Server only or would it be feasible to cover all three sources at once?
Edited by Magdalena Frankiewicz