Frequently Asked Questions

No. Migrayt only reads from ADO — it never writes to or modifies your ADO project. Your team can continue using ADO normally during the migration. There is no downtime or lock period.

Yes. Each project is a separate Migrayt migration run. You can migrate projects sequentially or, for independent projects, contact sales about concurrent migrations.

That is fine. Migrayt only creates new issues — it never modifies or deletes existing Jira issues. Existing issues and migrated items coexist in the same project.

Migrayt scans and adapts to any process template. Custom work item types, custom states, and custom fields are all detected during the scan phase and presented in the mapping UI.

The scan typically takes 1–5 minutes for projects up to 10,000 items. Larger projects (50,000+) may take 10–15 minutes. The scan is read-only and does not affect ADO performance.

Yes. Migrayt runs unattended. You do not need to stay at your computer. The migration continues in the background regardless of whether you have the browser open. You can check progress by returning to the migration URL at any time.

Migrayt checkpoints progress after every item. If interrupted (network failure, server restart, spot instance termination), the migration resumes from the last checkpoint automatically. No items are duplicated. At most 50 items before the interruption point may need to be re-processed.

No. Every migrated item receives a unique label (ado-id-{N}) in Jira. On any subsequent run, Migrayt checks for this label before creating an item. If it already exists, the item is skipped. This is guaranteed — there is no way to get duplicates by re-running.

Yes. Click the Pause button in the migration UI or call the pause API endpoint. The migration stops at the next checkpoint and can be resumed at any time. See Pause & Resume for details.

ADO work item IDs are not preserved as Jira issue IDs (Jira assigns sequential issue IDs from its own counter). However, the original ADO ID is:

• Stored as the label ado-id-{N} on every Jira issue
• Available in the ID mapping table in the post-migration report
• Searchable in Jira via JQL: labels = "ado-id-10432"

Jira Cloud does not allow the created field to be set via the API. All migrated items will have a created date equal to the date of migration. The original ADO creation date is preserved in the item history and in the description where relevant.

Items in closed or removed ADO states are migrated normally. The state is mapped to the closest Jira equivalent (e.g. "Removed" → "Cancelled") and the issue is transitioned to that status after creation.

Migrayt converts ADO HTML descriptions to Jira's Atlassian Document Format (ADF). Standard formatting (headings, bold, italic, lists, code blocks, tables, inline images) is fully preserved. Very complex nested HTML structures may be simplified to plain text paragraphs. Inline images are re-uploaded as Jira attachments and the URLs are rewritten.

The field is listed as "unmapped" in the Phase 4 mapping UI. The data from that field is not migrated. If you want the data to carry over, create the corresponding custom field in Jira before migration and return to Phase 4 to map it.

Migrayt attempts to create an inactive Jira account for ex-employees (no login access, just a directory entry). If that fails (SSO/SCIM restrictions), the item is assigned to the migration service account with the original assignee's name preserved in the description. See Ex-Employees for full details.

Users should log in to Jira and verify their items are correctly assigned and in the right status. Boards and sprints should be configured per your team's preference — Migrayt creates the sprints but does not configure boards.

Yes. Re-running a migration after new items are added to ADO will create the new items in Jira and skip all items that already exist. This is the incremental migration pattern.

Yes. Delete the migrated items in Jira (bulk delete via Jira's bulk operations) and run the migration again. Migrayt will create all items fresh.

Run this JQL query in Jira:

labels = "migrated-from-ado" AND assignee = "migration@yourcompany.com"

Use Jira's bulk edit to reassign them.

Yes. If a migration fails entirely and cannot be recovered, a full refund is issued within 5 business days. If the migration partially completes and the issues are not resolvable, a pro-rated refund is issued. Contact support@migrayt.ai.