How It Works
Overview

Migration Overview

Every Migrayt migration follows the same eight-phase lifecycle. Phases 1–5 are configuration (human-in-the-loop). Phases 6–8 are automated execution. You can pause and resume at any point during execution.

The Eight Phases

Phase 1  Connect Platforms        OAuth authentication with ADO and Jira
Phase 2  Scan Source Project      Count and catalogue everything in ADO
Phase 3  Map Work Item Types      AI suggests ADO type → Jira issue type mappings
Phase 4  Map Fields               AI suggests field-by-field mappings per type pair
Phase 5  Map Iterations & Areas   ADO iteration paths → Jira sprints; area paths → components
Phase 6  Review Pricing           Dynamic price calculated from item count and attachment size
Phase 7  Dry Run Preview          10 representative items transformed — no writes to Jira
Phase 8  Execute Migration        Full migration with live progress, pause/resume, and final report

Phase Details

Phase 1 — Connect Platforms

You authenticate with both platforms using OAuth 2.0. Migrayt requests only the minimum permissions required:

Azure DevOps scopes: vso.work_write, vso.project, vso.analytics, vso.identity
Jira scopes: read:jira-work, write:jira-work, read:jira-user

Your credentials are stored in AWS Secrets Manager and never written to the database. Migrayt cannot access your platforms unless you explicitly revoke and reconnect.

Phase 2 — Scan Source Project

Migrayt runs a read-only audit of your ADO project using WIQL (Work Item Query Language). The scan collects:

  • Work item type counts (Epics, Features, User Stories, Tasks, Bugs, custom types)
  • Full iteration path tree with date ranges and item counts per sprint
  • Full area path tree with item counts per node
  • All custom fields in use, their types, and how many items use each
  • Total attachment size in GB
  • Comment count
  • Relation type counts (blocks, relates, duplicates, parent-child)

The scan is completely read-only. Nothing in ADO is changed.

This data drives two things: the AI mapping suggestions in Phases 3–5, and the dynamic pricing calculation in Phase 6.

Phase 3 — Map Work Item Types

ADO and Jira use different terminology for the same concepts. Migrayt's AI analyses your specific ADO project structure and suggests the best mapping to Jira issue types.

The most complex case is ADO's four-level hierarchy (Epic → Feature → User Story → Task) collapsing to Jira's two-level hierarchy (Epic → Story). See Work Item Mapping for the full explanation.

All suggestions are shown to you for approval. You can override any mapping before proceeding.

Phase 4 — Map Fields

For each work item type pair confirmed in Phase 3, Migrayt maps individual fields. Standard ADO system fields (Title, Description, State, Priority, Assignee, Tags) are mapped automatically with high confidence.

Custom fields are matched by name similarity and field type compatibility. Fields with no Jira equivalent are listed explicitly so you understand what data will not carry over.

See Field Mapping for full details.

Phase 5 — Map Iterations and Areas

ADO iteration paths (hierarchical sprint tree) are mapped to Jira Sprints on the board you select. ADO area paths (hierarchical team/component tree) are mapped to Jira Components (flat).

Migrayt pre-creates any Jira Sprints or Components that do not already exist before the migration starts.

See Iteration & Sprint Mapping and Area & Component Mapping.

Phase 6 — Pricing

Price is calculated after the scan based on actual item count and attachment volume. There are no fixed tiers. You see the exact price before paying.

Base rate:        £0.012 per work item
Attachments:      £0.50 per GB
Minimum charge:   £99

Volume discounts:
  > 1,000 items:   5% off
  > 10,000 items:  15% off
  > 50,000 items:  25% off

See Pricing for examples.

Phase 7 — Dry Run

A dry run takes 10 representative items (2 of each mapped type where possible) and shows you exactly how they will appear in Jira after transformation — field values, status, hierarchy, labels. No data is written to Jira during a dry run.

This is your last opportunity to adjust mappings before the live migration.

Phase 8 — Execute Migration

The migration runs in strict topological order to ensure referential integrity:

  1. Create Jira Components (from area path mappings)
  2. Create Jira Sprints (from iteration path mappings)
  3. Migrate Epics
  4. Migrate Features (mapped type)
  5. Migrate User Stories / Stories
  6. Migrate Tasks and Bugs
  7. Migrate Test Cases and Test Plans
  8. Migrate Comments (oldest first, per item)
  9. Migrate Attachments (with inline image URL rewriting)
  10. Create Issue Links (after all items exist)
  11. Transition statuses to match ADO states
  12. Migrate time logs (if 7pace add-on enabled)
  13. Enrich test steps (if Xray add-on enabled)

Progress is streamed live to your browser. You can pause at any point — the migration resumes from the last completed item, never from the beginning.

After completion, an AI-generated report summarises what was migrated, what was changed, and any items that require attention.

Quick StartData Flow & Architecture