Originally asked by Sándor Jankovics on 12 February 2022 (original question)
Hi everyone!
Our company is migrating from Jira server to Jira cloud. My question is that we woud like to migrate the in progress issues as well but also would like to keep them in synced.
My use case is the following right now: We have a zendesk instance for our customer support requests and it is synced to Jira server using exalate. But we are moving to Jira cloud. How can we be able to configure exalate to remember the connections from the server?
I know that there is a bulk connect button but where can I get the list of issues that are under synced and with which issue(I tried already the support zip, but no luck )?
Answer by Francis Martens (Exalate) on 13 February 2022
The steps to follow are (on high level)
Setup the connection between zendesk and Jira cloud - make sure that all is working as expected
Download the twins using following sql query on the Jira database
Postgres Query to extract the twins
SELECT LR."ISSUE_URN" AS local_issue, RR."ISSUE_URN" AS remote_issue
FROM "AO_08F1AF_TWIN_TRACE" TT
LEFT JOIN "AO_08F1AF_REPLICA" LR ON TT."LOCAL_REPLICA_ID" = LR."ID"
LEFT JOIN "AO_08F1AF_REPLICA" RR ON TT."REMOTE_REPLICA_ID" = RR."ID"
JOIN "AO_08F1AF_RELATION" R ON TT."RELATION_ID" = R."ID"
WHERE R."NAME" IN ('Connection Name');
The sql will need to be adapted if Jira is using another database type (mssql, mysql, oracle …). Replace ‘connection name’ with the name of the connection …
Use bulk connect to restore the connection
Comments:
Sándor Jankovics commented on 14 February 2022
Thanks, this sql really saved a lot of work (old community)
Sándor Jankovics commented on 14 February 2022
After the bulk import will exalate know that it is not the firstsync?
In our use case: We only allow to modify the description and summary on the first sync therefore in the code we use:
if(firstSync){
issue.summary=replica.summary
}
Is it going to be able to not fall into the ‘if’?
Francis Martens (Exalate) commented on 14 February 2022
The firstSync is false if there is a twin registered for that (local) issue and that connection.
The proof is in the pudding (old community)