Pre-Migration Checklist

Confirm with your team which ADO organisation and project you are migrating. Migrayt migrates one project per run. If you have multiple projects, you will need separate runs.

Create a dedicated ADO account for the migration (e.g. migrayt-migration@yourcompany.com). This keeps the migration clearly attributable and allows you to revoke access cleanly afterwards.

Minimum required permissions:

• Project Reader on the source project
• Access to Work Items (read)
• Access to Analytics (read)

Some work items may be restricted to specific security groups. Migrayt can only read items that the service account can see. Run a test WIQL query to check the item count matches your expectation.

List any custom work item types beyond the standard ADO types (Epic, Feature, User Story, Task, Bug). You will need to map these to Jira issue types during the migration wizard.

Files over 250 MB cannot be uploaded to Jira Cloud. Use this WIQL query to find oversized attachments:

SELECT [System.Id], [System.Title]
FROM WorkItems
WHERE [System.AttachedFileCount] > 0
ORDER BY [System.Id]

Check the attachment sizes in the results. Very large files should be moved to a file storage service before migration.

Create the Jira project you are migrating into. Migrayt migrates into an existing project — it does not create the project for you.

If migrating to a Scrum project, ensure at least one board exists before starting.

Create a Jira account for the migration (e.g. migrayt@yourcompany.com). This account should have:

• Project Administrator role on the destination project
• Ability to create issues, components, sprints, and worklogs
• Optionally: Site Administrator if you want Migrayt to auto-create inactive accounts for ex-employees

Ensure the Jira project has the issue types you intend to map ADO types to. At minimum: Epic, Story, Task, Bug. If you have Sub-tasks, enable Sub-task as well.

If your ADO project uses custom fields that you want to carry over, create the corresponding custom fields in Jira before migration. Migrayt can only map to fields that exist in Jira.

Supported Jira custom field types: text field, number field, date picker, user picker, select list (single), checkbox.

Ensure your Jira project's workflow includes statuses for all ADO states you use. At minimum: To Do, In Progress, Done. Optionally: In Review, Blocked, Cancelled, Backlog.

If a target status does not exist in the workflow, items will remain in their creation status ("To Do") and the skipped transition will be flagged in the report.

Ensure your Jira project has the following link types enabled: Relates, Blocks, Duplicate. These are standard and should be present by default.

Inform your team that Jira will be receiving a large volume of new issues. During migration, avoid creating new Jira issues in the destination project manually to prevent confusion.

ADO does not need to be locked or paused — your team can continue using ADO during the migration.

If you are migrating both active and legacy projects:

• Active projects: migrate first, communicate the cutover date to your team
• Legacy projects: migrate after the team is settled in Jira

Migrayt supports incremental migration — you can re-run a migration to pick up items created in ADO after the first run.

Review your ADO project for items assigned to people who have left. Decide in advance whether you want to:

• Have Migrayt create inactive Jira accounts for them (requires site admin credentials)
• Accept the ghost assignment strategy and manually reassign after migration

Migrayt will suggest sprint mappings based on name similarity. If your ADO and Jira sprints use different naming conventions, prepare a mapping table in advance so you can make faster decisions during Phase 5.