We couldn't import Project Version because of missing dependencies: Project - JCMA Error
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
When trying to run the Jira Cloud Migration Assistant (JCMA) to migrate from Server to Cloud, the migration plan fails and the following message appears stating there are possible issues with the Project Version:
1
2
ERROR <Project_Key> project-import We couldn't import Project Version <Version_Name> because of <Number_of_Occurrences> missing dependencies: Project <Project_Key>.
This caused <Number_of_Issues> other items to fail. Check the reasons for the missing dependencies on your server site. Environment
This message applies to the Jira Cloud Migration Assistant (JCMA).
From Server to Cloud
Cause
This happens because a project is using entities from another project that is not being migrated, hence the missing dependency. Fix Versions are project-specific.
Solution
To address this issue, one should add or create the project version <Version_Name> on the appropriate project and remove the association of the previous project version, the one that belongs to a different project. Then, re-associate with the newly created project version via a bulk operation.
This can happen with the system field Fix Version or a custom field of type Version Picker.
Fix Version system field
Please make sure to follow all the steps below:
You can find the affected issues that have the Project version <Version_Name> by running this JQL (Jira Query Language):
1project = <Project_Key> and (fixversion = '<Version_Name>' OR affectedVersion = '<Version_Name>')Replace the <Project_Key> placeholder with the project key of the impacted project and the <Version_Name> with the project version that is currently associated with the affected issues.
Our recommendation is to bulk update the issues removing the Fix Version from the other project to the ones they belong to.
Afterward, if the issue persists or the above JQL returns 0 results, we can run this query on your Jira Server database to find the affected issues:
1 2 3 4 5 6 7select p.id project_id_issue, pv.project project_id_version, (p.pkey || '-' || i.issuenum) as key, i.summary, pv.id version_id, pv.vname version_name from jiraissue i inner join project p on i.project = p.id inner join nodeassociation na on na.source_node_id = i.id inner join projectversion pv on pv.id = na.sink_node_id where association_type in ('IssueFixVersion','IssueVersion') and p.pkey in ('PROJECT_KEY') and p.id != pv.project;Replace the PROJECT_KEY placeholder with the project key of the impacted project.
If there are any results, please go back to step #2 and repeat the process.
Version Picker custom field
Run this query on the Jira server database to identify which issues from the project key referenced on the logs are impacted by this problem.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
WITH customfieldinfo AS
(SELECT p.id AS project_id_source
, p.pkey AS project_key_source
, (p.pkey || '-' || j.issuenum) AS issuekey
, cf.cfname AS custom_field_name
, cfv.numbervalue::INTEGER AS current_version_id
, pv.vname AS current_version_name
, cfv.id AS cfv_entry
FROM jiraissue j
JOIN project p ON p.id = j.project
JOIN customfieldvalue cfv ON cfv.issue = j.id
JOIN customfield cf ON cf.id = cfv.customfield
JOIN projectversion pv ON pv.id = cfv.numbervalue::INTEGER
WHERE cf.customfieldtypekey IN ('com.atlassian.jira.plugin.system.customfieldtypes:version',
'com.atlassian.jira.plugin.system.customfieldtypes:multiversion')) ,
issueinfo AS
(SELECT j.id AS issueid
, (p.pkey || '-' || j.issuenum) AS issuekey
FROM jiraissue j
JOIN project p ON p.id = j.project),
versioninfo AS
(SELECT id AS versionid
, vname AS versionname
, project AS projectsourceid
FROM projectversion),
projectinfo AS
(SELECT id AS pid_dep
, pkey AS project_key_dependency
FROM project),
minidb AS
(SELECT ii.cfv_entry
, ii.project_id_source
, ii.issuekey
, ii.custom_field_name
, ii.current_version_id
, ii.current_version_name
, pi.pid_dep AS project_id_depedency
, pi.project_key_dependency
FROM customfieldinfo ii
JOIN issueinfo iff ON iff.issuekey = ii.issuekey
JOIN versioninfo vi ON vi.versionid = ii.current_version_id
JOIN projectinfo pi ON pi.pid_dep = vi.projectsourceid
WHERE ii.project_id_source != pi.pid_dep)
SELECT mdb.*
, pv.project AS target_project_key
, pv.vname AS target_project_version_name
, pv.id AS target_project_version_id
, 'update customfieldvalue set numbervalue = ' || pv.id || ' where id = ' || mdb.cfv_entry || ';' AS update_query
FROM minidb mdb
JOIN projectversion pv ON pv.project = mdb.project_id_source
WHERE mdb.current_version_name = pv.vname;Note
Replace the PROJECT_KEY placeholder with the project key of the impacted project.
Note
This query works for Postgres. You may need to adjust it to the database flavor you're using.
Solution
If that data is not necessary to be moved over, remove the custom field of type Version Picker from all the screens associated with the project you're trying to migrate. When doing that the JCMA will skip exporting those references.
If data is necessary to be moved over, we recommend creating a new custom field of a different type and copying the same values from the Version Picker to this new one. After that, you should also make sure to remove the Version Picker custom field from the screen of the impacted project.
Was this helpful?