Migratly migrates Jira to Monday.com by reading both APIs, deriving the mapping between them, and showing you what it found before anything is written. For this pair that is 13 entity types and 70 field mappings, of which 35 carry across intact and 30 are flagged as lossy, partial, dropped, or needing a route other than the obvious one. 5 of them need a decision from you. The Jira side is read-only throughout — Migratly never writes to or deletes from your source.
How the structure changes
- Each Jira project becomes a Monday folder.
- Inside that folder, separate boards are created for Tasks, Epics and a Bugs Queue. Board columns come from the mapped Jira fields.
- Jira sprints become groups inside the project's Tasks board.
- Issues and epics are written as items only after their board exists — creating the board and filling it are two separate waves.
- Issue links become Monday dependencies in the last wave.
What maps to what
Entities are written in dependency waves. Everything at wave 0 exists before anything at wave 1 is created, which is what makes cross-references resolvable and the whole run resumable from a cursor.
| Jira | Monday.com | Wave | How it is handled | Fields |
|---|
| Project |
Folder |
0 |
the folder everything else lands in |
2 |
| User |
User |
0 |
accounts matched before anything is written |
4 |
| Epic |
Epics |
1 |
the collection that everything else lands in |
3 |
| Issue |
Tasks |
1 |
the collection that everything else lands in |
5 |
| Sprint |
Group |
1 |
a grouping inside a collection, created before its records |
4 |
| Sprint |
Sprints |
1 |
the collection that everything else lands in |
1 |
| Epic |
Item |
2 |
the records themselves |
4 |
| Issue |
Item |
2 |
the records themselves |
31 |
| Sprint |
Item |
2 |
the records themselves |
4 |
| Attachment |
File |
3 |
comments, attachments and body content |
2 |
| Comment |
Update |
3 |
comments, attachments and body content |
3 |
| Sub-task |
Subitem |
3 |
the records themselves |
4 |
| IssueLink |
Dependency |
4 |
links between records, resolved last |
3 |
Field-by-field coverage
Every mapping carries one of five labels. Full means it carries across intact. Partial means the value survives with a narrowed range. Lossy means something is lost. Workaround means there is no native slot and it is carried another way. Dropped means the target will not accept it. Anything short of full is shown to you before the run, not discovered afterwards.
Project → Folder
| Jira field | Monday.com field | Coverage | Notes |
|---|
name |
name |
Full |
|
key |
no equivalent |
Internal |
Used as the collection_key template prefix for boards inside this folder (e.g. KAN_tasks, KAN_epics). |
User → User
| Jira field | Monday.com field | Coverage | Notes |
|---|
accountId |
no equivalent |
Lossy |
Monday users have numeric IDs unrelated to Jira accountId — joined by email. |
displayName |
name |
Full |
|
emailAddress |
email |
Full |
Primary join key — Jira users must already exist in the target Monday workspace with the same email. |
active |
no equivalent |
Dropped |
Monday does not expose user active status via API; admin-only setting. |
Epic → Epics
| Jira field | Monday.com field | Coverage | Notes |
|---|
summary |
item_name |
Internal |
|
status.name |
column.status |
Partial |
|
customfield_10015 |
column.date |
Full |
Jira Cloud epic start date custom field. |
Issue → Tasks
| Jira field | Monday.com field | Coverage | Notes |
|---|
summary |
item_name |
Internal |
Driver for declaring the board has a primary 'Name' column — item_name is the native title field on every Monday board. |
status.name |
column.status |
Partial |
Status column must be created on the board with Jira's status labels. Unmapped statuses fall back to the board default. Asks you first |
priority.name |
column.priority |
Full |
|
duedate |
column.date |
Full |
|
labels |
column.dropdown |
Full |
|
Sprint → Group
| Jira field | Monday.com field | Coverage | Notes |
|---|
name |
title |
Full |
|
state |
no equivalent |
Dropped |
Monday Groups have no state/status concept — sprint state inferred from issue completion. |
startDate |
no equivalent |
Dropped |
Monday Groups have no start/end date fields. |
goal |
no equivalent |
Workaround |
Sprint goal stored as the first Update on the first item of the group (workaround). |
Sprint → Sprints
| Jira field | Monday.com field | Coverage | Notes |
|---|
name |
item_name |
Internal |
Driver for declaring the Sprints board's primary Name column. |
Epic → Item
| Jira field | Monday.com field | Coverage | Notes |
|---|
summary |
item_name |
Full |
|
description |
column_values.long_text |
Partial |
ADF → plain/markdown. |
status.name |
column_values.status |
Partial |
Asks you first |
customfield_10015 |
column_values.date |
Full |
Epic start date. |
Issue → Item
| Jira field | Monday.com field | Coverage | Notes |
|---|
summary |
item_name |
Full |
|
description |
column_values.long_text |
Partial |
ADF rich text flattens to plain text/markdown. For rich content, also append as an Update. |
status.name |
column_values.task_status |
Partial |
Maps to source-template's `task_status` (Status) column on cloned Tasks board. Asks you first |
priority.name |
column_values.priority |
Full |
|
assignee.accountId |
column_values.task_owner |
Full |
|
reporter.accountId |
no equivalent |
Workaround |
Monday items don't have a reporter field — reporter prepended in description or as an Update. |
labels |
column_values.labels |
Full |
|
duedate |
column_values.date |
Full |
|
created |
no equivalent |
Dropped |
Monday's created_at is set by the API at item creation time — cannot override. |
key |
column_values.issue_key |
Full |
|
customfield_10016 |
column_values.numbers |
Partial |
Story points custom field ID varies per Jira instance — should be discovered at runtime. Asks you first |
customfield_10020 |
group_id |
Full |
Sprint custom field — items placed in the matching Sprint Group on the cloned Tasks board. customfield_10020 is a LIST of sprint dicts; pipe picks the most-current (active>future>closed) and extracts .name. _resolve_group looks up group_map[<board>:<name>] which the Sprint→Group entity populated. |
customfield_10020 |
column_values.task_sprint |
Full |
Cross-board link to the Sprint item on the cloned Sprints board (split from group_id above so _build_properties picks the lookup transform, not the group-name extractor — executor only uses first_route per field_mapping). |
parent.key |
column_values.task_epic |
Full |
Cross-board link to the Epic item on the cloned Epics board. Uses the universal id_map lookup — the Epic→Item migration runs first (dependency_level=2) and populates id_map[Record:<epic_key>] with the new item id; this transform resolves that mapping at write time. |
issuetype.name |
column_values.task_type |
Full |
Maps to source-template's `task_type` (Type) column on cloned Tasks board. |
project.key |
column_values.project_key |
Internal |
Already encoded in board structure (one board per project) — but stored on item too for traceability. |
creator.accountId |
column_values.original_creator |
Workaround |
Monday items don't support arbitrary creator override; original creator name stored as text. |
fixVersions |
column_values.fix_versions |
Full |
|
versions |
column_values.affects_versions |
Full |
|
components |
column_values.components |
Full |
|
resolution.name |
column_values.resolution |
Full |
|
resolutiondate |
column_values.date |
Full |
|
votes.votes |
no equivalent |
Dropped |
Vote counts have no decision-grade value post-migration; deliberately dropped. |
watches.watchCount |
no equivalent |
Dropped |
Watch counts deliberately dropped. |
workratio |
no equivalent |
Dropped |
Derived value; not meaningful post-migration. |
progress |
no equivalent |
Dropped |
Time-tracking aggregate; covered elsewhere. |
aggregateprogress |
no equivalent |
Dropped |
Sub-issue roll-up; recomputed in target. |
lastViewed |
no equivalent |
Dropped |
Per-user metadata. |
statuscategorychangedate |
no equivalent |
Dropped |
Derived field; not meaningful post-migration. |
statusCategory |
no equivalent |
Dropped |
Derived from status.name. |
id |
no equivalent |
Dropped |
Internal Jira numeric ID; key preserved instead. |
Sprint → Item
| Jira field | Monday.com field | Coverage | Notes |
|---|
name |
item_name |
Full |
|
goal |
column_values.sprint_goals |
Full |
Maps to cloned Sprints board's `sprint_goals` long_text column. |
startDate |
column_values.sprint_timeline |
Full |
Compound timeline value built from startDate + endDate of the same source record via the `object` op (each field reads from source record). Coerce normalises to YYYY-MM-DD. |
state |
column_values.active_sprint |
Full |
Map Jira sprint state → checkbox. 'active' → checked, else unchecked. |
Attachment → File
| Jira field | Monday.com field | Coverage | Notes |
|---|
content |
no equivalent |
Workaround |
Monday API v2 has no native binary upload mutation. Workaround: post the source attachment URL as text in an Update, with auth-protected URLs that may expire. Asks you first |
filename |
no equivalent |
Full |
|
Comment → Update
| Jira field | Monday.com field | Coverage | Notes |
|---|
body |
body |
Partial |
ADF → plain text/markdown; Monday Updates support markdown but not arbitrary rich blocks. |
author.accountId |
no equivalent |
Workaround |
Monday Updates can't be posted as another user — author name prepended in body. |
created |
no equivalent |
Dropped |
Monday sets created_at on Updates — cannot override. |
Sub-task → Subitem
| Jira field | Monday.com field | Coverage | Notes |
|---|
summary |
item_name |
Full |
|
parent.key |
parent_item_id |
Full |
|
status.name |
column_values.status |
Partial |
|
assignee.accountId |
column_values.assignee |
Full |
|
IssueLink → Dependency
| Jira field | Monday.com field | Coverage | Notes |
|---|
inwardIssue.key |
column_values.dependency |
Full |
|
outwardIssue.key |
column_values.dependency |
Full |
|
type.name |
no equivalent |
Dropped |
Monday dependencies are untyped — blocks/duplicates/relates merge to a single dependency relationship. |
What does not carry across cleanly
These are the 27 mappings where Monday.com cannot hold what Jira holds. Each one appears in your coverage report with the same reason, and with the alternative routes available.
accountId Lossy
Monday users have numeric IDs unrelated to Jira accountId — joined by email.active Dropped
Monday does not expose user active status via API; admin-only setting.status.name Partial
Status column must be created on the board with Jira's status labels. Unmapped statuses fall back to the board default.state Dropped
Monday Groups have no state/status concept — sprint state inferred from issue completion.startDate Dropped
Monday Groups have no start/end date fields.goal Workaround
Sprint goal stored as the first Update on the first item of the group (workaround).description Partial
ADF rich text flattens to plain text/markdown. For rich content, also append as an Update.status.name Partial
Maps to source-template's `task_status` (Status) column on cloned Tasks board.reporter.accountId Workaround
Monday items don't have a reporter field — reporter prepended in description or as an Update.created Dropped
Monday's created_at is set by the API at item creation time — cannot override.customfield_10016 Partial
Story points custom field ID varies per Jira instance — should be discovered at runtime.creator.accountId Workaround
Monday items don't support arbitrary creator override; original creator name stored as text.votes.votes Dropped
Vote counts have no decision-grade value post-migration; deliberately dropped.watches.watchCount Dropped
Watch counts deliberately dropped.workratio Dropped
Derived value; not meaningful post-migration.progress Dropped
Time-tracking aggregate; covered elsewhere.aggregateprogress Dropped
Sub-issue roll-up; recomputed in target.lastViewed Dropped
Per-user metadata.statuscategorychangedate Dropped
Derived field; not meaningful post-migration.statusCategory Dropped
Derived from status.name.id Dropped
Internal Jira numeric ID; key preserved instead.description Partial
ADF → plain/markdown.body Partial
ADF → plain text/markdown; Monday Updates support markdown but not arbitrary rich blocks.author.accountId Workaround
Monday Updates can't be posted as another user — author name prepended in body.created Dropped
Monday sets created_at on Updates — cannot override.content Workaround
Monday API v2 has no native binary upload mutation. Workaround: post the source attachment URL as text in an Update, with auth-protected URLs that may expire.type.name Dropped
Monday dependencies are untyped — blocks/duplicates/relates merge to a single dependency relationship.
Decisions you will be asked to confirm
Migratly stops and asks rather than guessing when the right answer depends on your instance.
status.name → column.status
Status column must be created on the board with Jira's status labels. Unmapped statuses fall back to the board default.status.name → column_values.task_status
Confirm Jira status → Monday status label mapping.customfield_10016 → column_values.numbers
Confirm Jira story-points custom field ID.status.name → column_values.status
Confirmed during planning.content → unmapped
Decide: drop attachments, embed source URL as text, or pre-rehost to a public CDN before linking.
How a Jira to Monday.com migration runs
- Connect both systems. Jira is connected read-only. Migratly never writes to, archives or deletes anything on the source side.
- Schema discovery. Both APIs are read live, including your custom fields, so the mapping reflects your instance rather than a generic Jira instance.
- Coverage report. All 70 mappings are presented with their coverage. You confirm, reroute or exclude before anything is written.
- Execution in 5 waves. Writes are idempotent and cursor-tracked, so an interrupted run resumes instead of restarting or duplicating.
- Verification. The result is checked back against the source, and every action is in an append-only audit log.
Questions
Can Migratly migrate Jira to Monday.com?
Yes. Jira to Monday.com is a supported pair with a mapping covering 13 entity types and 70 fields. You connect both systems, Migratly reads the live schemas on each side, and it produces a coverage report you approve before any data moves.
What is lost when migrating from Jira to Monday.com?
30 of the 70 field mappings for this pair are flagged rather than clean. For example, `accountId` is marked lossy: Monday users have numeric IDs unrelated to Jira accountId — joined by email. Every flagged mapping appears in the coverage report before the run, with its reason and the routes still open to it. Nothing is dropped silently.
How long does a Jira to Monday.com migration take?
It is bounded by the two APIs' rate limits rather than by Migratly. This pair runs in 5 dependency waves, starting with account matching and ending with cross-references, and every wave is resumable — a run interrupted halfway continues from its cursor rather than starting over or duplicating what it already wrote.
Is my Jira data modified during the migration?
No. The source is read-only for the entire run. Migratly never writes to, archives, or deletes anything in Jira, and every action taken against Monday.com is written to an append-only audit log.
How does a Jira project map onto Monday.com boards?
One folder per Jira project, holding a Tasks board, an Epics board and a Bugs Queue board. Splitting by type keeps each board's column schema meaningful, which a single mixed board cannot do.
Do Jira sprints become anything in Monday.com?
Sprints become groups inside that project's Tasks board, so the sprint an issue belonged to is still visible after the move.
Are Jira comments migrated to Monday.com?
Yes, as updates on the corresponding item. They are written after items exist, and original timestamps are preserved where the Monday API accepts them.
Other migration pairs