How can I move a project board to a new app without losing task relationships?

Plan for both task records and their relationships. List each source field and relationship type, what it means, and the destination field or feature that should represent it. Mark anything with no clear equivalent as unsupported until you verify it. A matching field name does not prove that values or behavior will map correctly.

Use a field map such as:

• Task title and stable identifier → destination fields; confirm similar titles remain distinguishable.
• Parent or subtask → hierarchy feature; confirm the needed nesting level is supported.
• Dependency and link type → destination link; confirm direction and meaning.
• Assignee → user mapping; decide what to do with unmatched accounts.
• Due date → date field; check how populated and blank dates should appear.

Save the map and a source snapshot or export for comparison. Capabilities vary by product and migration path. For example, Atlassian lists assignees, due dates, subtasks, and issue links among data supported by Jira Cloud Migration Assistant, but also identifies items that are not migrated. This is Jira-specific, not a guarantee for another app or route. [S1]

Before the move, make a relationship inventory. For each task, record a stable identifier and parent identifier, if any. For each dependency, record the two task identifiers, link type, and direction. Use an export or report that preserves these details if the board is too large to track by hand. Avoid relying on titles alone, since they may repeat or change.

After the move, compare the inventory with the destination. Inspect a varied sample: a task with subtasks, one with multiple dependencies, one with an unusual link type, and one with no links. Check both ends of each relationship and make sure dependencies point between the intended tasks in the intended direction. A matching total link count is not enough; links may connect the wrong records.

If the destination lacks an equivalent feature, mark the relationship as unsupported and agree on a documented alternative or manual rebuild. Do not silently replace it with a generic link or assume that its original meaning is preserved.

Compare source and destination assignees on several records, including different people and unassigned tasks. Agree in advance how unmatched or inactive accounts should appear, and ask the responsible project owner to approve that mapping. Do not infer a person’s identity from a similar-looking account.

For dates, compare actual displayed values on a sample that includes populated and blank due dates. Confirm that each populated date appears in the intended field and blanks remain as expected. Record mismatches rather than treating an import as successful just because the task arrived.

Use reports where your migration method provides them, but also check individual records. In the Jira Cloud Migration Assistant context, Atlassian describes pre- and post-migration reports and error logs, and recommends reviewing projects and issues afterward. These recommendations concern Jira migrations, not every platform. [S2]

Keep a simple record for the migration:

Board: [board name] Migration run/date: [placeholder] Source snapshot: [export or reference] Destination: [app and board] Exceptions owner: [role or placeholder]

Before moving, save the field map and relationship inventory. Afterward, compare task records, then inspect the varied sample and any items flagged in available reports. Log each mismatch as: source record → expected result → observed result → action owner → status. For approved rebuilds, verify both ends of every relationship and its direction. Ask the person responsible for the board to review open exceptions before colleagues rely on the destination.

This plan helps find omissions; it does not establish that every feature transfers automatically. Verify support for your source, destination, and migration method before scheduling the move.