Issue Summary

When migrating Projects from Server to Cloud, the migration assistant can reopen past completed Sprints in some scenarios. Some well-known scenarios are:

• Sprint name already exists in destination Cloud site (expected as per MIG-1339)
• Sprint was previously migrated under a different name after Project data changed
• Sprint contains cross-project issues
• Shared Sprints found in other Boards
• In phased migrations, if migrator selects on every plan to migrate "All dashboards", if a gadget/ dashboard references a sprint, although the sprint belongs to a single project board, will be exported in cross project data and the server data will take prevalence over already existing cloud data;

This is reproducible on Data Center: (yes)

Steps to Reproduce

These steps only account for 1 particular scenario that is very consistent (cross-project issues):

1. On Server site, create Project A with Sprint 1 and Issues
2. Perform a Server to Cloud migration using JCMA including Project A
3. On Cloud site, complete Sprint 1
4. On Server site, create Project B with Issues. Assign an Issue to Sprint 1
5. Perform a Server to Cloud migration using JCMA including only Project B

Expected Results

Considering Project A was not in the scope of the migration, this should have no impact, OR a new Sprint 1 should be created in Project B.

Actual Results

Sprint 1 from Project A is reopened. This is also still applicable if the Sprint was renamed in the Server site where it will update the Sprint name in the Cloud site.

Workaround

If migrating in phases with the option to migrate "All dashboards" in each phase, prior to the migration, contact Atlassian Migration Support with the result of the below query:

SELECT
    pp.ID AS DashboardID,
    pp.PAGENAME AS DashboardName,
    pc.ID AS GadgetID,
    pc.GADGET_XML AS GadgetKey,
    gup_sprint.USERPREFVALUE AS SprintID,
    aosp."NAME" AS SprintName,
    aosp."START_DATE" AS SprintStartDate,
    aosp."COMPLETE_DATE" AS SprintCompleteDate,
    aosp."END_DATE" AS SprintEndDate,
    aosp."CLOSED" AS SprintClosed,
    aosp."STARTED" AS SprintStarted,
    aosp."RAPID_VIEW_ID" AS RapidViewID 
    FROM
       PORTALPAGE pp
   JOIN
       PORTLETCONFIGURATION pc ON pp.ID = pc.PORTALPAGE
   JOIN
       GADGETUSERPREFERENCE gup_sprint ON pc.ID = gup_sprint.PORTLETCONFIGURATION AND gup_sprint.USERPREFKEY = 'sprintId'
   JOIN
       "AO_60DB71_SPRINT" aosp ON gup_sprint.USERPREFVALUE = aosp."ID"::text;

Atlassian support will be able to map the above result with the existing cloud data and will provide you the differences for the potentially impacted sprints. Having this information, migrator can take educated decision on whether to proceed in using the migrate "All dashboard" option with impact or not migrating dashboards (as long as all dashboards were migrated in the first migration phase). More than this, the information provided can be leveraged to modify the on premise sprints via REST/ API or database ( by setting to the on prem sprints the values existing on cloud).