Iteration Paths & Sprint Mapping

ADO iteration paths are one of the most complex parts of any migration. This page explains the structural difference and how Migrayt resolves it.

The Structural Difference

ADO Iteration Paths are hierarchical. A project typically structures iterations like:

MyProject
  └── 2024
        ├── Sprint 1   (2024-01-08 → 2024-01-19)
        ├── Sprint 2   (2024-01-22 → 2024-02-02)
        └── Sprint 3   (2024-02-05 → 2024-02-16)
  └── 2025
        ├── Q1
        │     ├── Sprint 1   (2025-01-06 → 2025-01-17)
        │     └── Sprint 2   (2025-01-20 → 2025-01-31)
        └── Q2
              ├── Sprint 1   (2025-04-07 → 2025-04-18)
              └── Sprint 2   (2025-04-21 → 2025-05-02)

Jira Sprints are flat — all sprints on a board exist at the same level with no parent-child grouping. Sprint names do not need to be unique globally, but must be unique per board.

Mapping Approach

During Phase 5, Migrayt shows you the full ADO iteration tree on the left and your existing Jira sprints on the right. For each ADO iteration, the AI suggests one of three actions:

Action	When used
Map to existing sprint	A Jira sprint with the same or similar name already exists on the target board
Create new sprint	No matching Jira sprint found; Migrayt will create it before migration starts
Drop	The iteration has zero items; optionally drop rather than create an empty sprint

Matching logic

Migrayt uses two signals to suggest matches:

Name similarity — Sprint 1 in ADO matches Sprint 1 in Jira with high confidence. Partial matches like S1 or Iteration 1 match with medium confidence and are flagged for review.
Date overlap — If an ADO iteration has start/end dates and a Jira sprint has start/end dates, Migrayt checks whether the date ranges overlap. A 100% overlap is treated as a strong match even if names differ.

Pre-creation

Any sprints that need to be created are created in Jira before work items are migrated. This ensures that every item can be assigned to the correct sprint immediately during the migration. You do not need to create sprints manually.

Migrayt creates sprints with the following fields from the ADO iteration:

Name — Full ADO path leaf node (e.g. Sprint 1, 2025 Q1 Sprint 1)
Start date — From ADO if set; omitted if not
End date — From ADO if set; omitted if not
Board — The Jira board you selected during platform connection

Kanban Boards

If you selected a Kanban board in Jira (rather than a Scrum board), sprints do not exist. In this case, Migrayt offers two alternatives:

Map to Fix Versions — ADO iterations are created as Jira Fix Versions (milestones) and items are linked to them
Drop sprint data — Items are migrated without sprint assignment; iteration path information is stored in a custom label (ado-iteration:{path})

You choose this behaviour during Phase 5.

Unmapped Iterations

Items assigned to ADO iterations that were marked as "Drop" will be migrated without a sprint assignment. They will appear in Jira's backlog with no sprint. This is valid Jira behaviour and does not cause any errors.

The post-migration report lists all items that lost their sprint assignment, grouped by iteration path.

Example

ADO Iteration            Items   AI Suggestion          Confidence
───────────────────────  ──────  ─────────────────────  ──────────
2024 > Sprint 1            34    Create "Sprint 1"          High
2024 > Sprint 2            28    Map → "Sprint 2" (Jira)    High (name + date match)
2024 > Sprint 3             0    Drop (empty)               Auto
2025 > Q1 > Sprint 1       41    Create "Q1 Sprint 1"       High
2025 > Q1 > Sprint 2       37    Create "Q1 Sprint 2"       High
2025 > Q2 > Sprint 1       12    Create "Q2 Sprint 1"       High

Field Mapping Areas & Components