Linking MS Project with Jira Issues: How to Keep the Schedule and the Board Aligned
Two tools, one project: the MS Project schedule says the API work is on track, and the Jira board says PROJ-218 was reassigned three weeks ago. Both are "correct." Neither is connected.
This is the failure mode of every DIY Jira ↔ MS Project setup — and it's not a scheduling problem, it's an identity problem. A schedule row is not an issue. "Row 14" is not PROJ-218. The moment your link between the two is by row position or by task name, the first rename or reordering quietly breaks it, and from then on the two tools drift apart in silence.
This guide is the practical answer: how to make every schedule row durably bound to its Jira issue and its people, map the fields that keep both tools honest, and know when CSV is enough — and when it structurally can't be. (For the export/edit/import mechanics themselves, see the companion Microsoft Project and Jira guide.)
Why "row 14" is not an issue
Jira and MS Project model the same work in fundamentally different shapes:
- Jira thinks in issues and status — a backlog of work items moving across a board, identified by a durable key (PROJ-218).
- MS Project thinks in tasks and time — rows in a work breakdown structure, identified by position, name, and dates.
Nothing in either tool natively knows that a particular row is a particular issue. Teams that have lived with this converge on the same workaround: carry the Jira issue key inside the schedule file. The two common ways to do it:
- A dedicated text custom field (e.g.
Jira_ID= PROJ-218) — the robust practice. The identity is separate from the description, so renaming the task, reordering the WBS, or re-syncing never breaks the link. - Appended to the task name (
[PROJ-218] Fix login bug) — visible to humans, but fragile. One rename, one overwritten import, and the "link" is gone.
The first is what any serious integration uses as its foreign key. The second is what breaks in production.
How MSP Planner keeps the link: the identity marker
Here's the practical model, using MSP Planner for Jira — a Forge-native scheduling layer that exchanges schedules with MS Project through the MSPDI (Microsoft Project Detailed Interchange) standard, which Microsoft Project opens natively.
1. Every task carries a durable identity hash
On export, MSP Planner writes a unique identity hash — derived from the Jira issue key — into a reserved MS Project custom field (Text30). The point of the hash is exactly what the task-name trick gets wrong: it survives renaming, reordering, and the file being passed through several stakeholders. On import, the app doesn't guess which row is which — it reads the identity field and maps each row directly back to its live Jira issue.
2. Map the fields that keep both tools honest
Identity is only the anchor; the schedule and the board also have to agree on the facts. MSP Planner's mapping contract is strict and explicit:
| What | Jira | MS Project (MSPDI) |
|---|---|---|
| Task identity | Issue key | Identity hash in Text30 |
| Task label | Summary | Name |
| Timing | Due date | Finish |
| Effort | Story points | Work (converted per project settings) |
| People | Assignee | Resource name (linked via the resource's identity) |
Note what this buys you: when the schedule comes back, a changed finish date lands on the right issue, a changed work value lands as effort on the right issue, and a changed assignment lands on the right Jira user — because each of those fields is mapped to a stable identity, not to a label.
3. Keep the workforce in sync, not just the dates
The second identity runs through people. Each Jira user has its own identity (a system resource hash, written to the resource's Text30 field), so assignments round-trip against real Jira users, not name strings. That's the difference between "someone named 'S. Ivanov' got 50% of the task" (which breaks the first time someone changes their display name) and a specific Jira user carrying a specific allocation (Max Units, 100% = 1.0) that re-associates cleanly on import.
4. Let schedule-only rows stay schedule-only
Real schedules are hybrid: some tasks are team work tracked in Jira, and some are milestones, external dependencies, or PMO structure that should never become Jira tickets. MSP Planner handles the boundary explicitly — a row in the returned file with a matching identity updates the linked issue; a row without an identity (a milestone a stakeholder added in MS Project) comes in as a schedule-only task, with no "ghost" issue created in Jira.
CSV vs native: when each is enough
Because it shows up constantly in practice, the CSV question deserves a straight answer:
- CSV (or XML) export is a fine one-way snapshot. A weekly dump of issues into a spreadsheet or into MS Project works for occasional reporting. It has no identity — nothing comes back. The moment someone edits the schedule in Project, there is no way to tell which row is PROJ-218, so re-importing creates duplicates and detaches the plan from the work.
- The native MSPDI round-trip is an integration. It preserves dependencies (including lead/lag and SS/FF/SF types), hierarchy, constraints (start/finish no-earlier/no-later), scheduling modes (Fixed Work/Duration/Units), and — crucially — the identity markers that make the return trip lossless.
The decision rule is simple: if data must flow back into Jira, CSV is a report, not an integration.
Reconcile deliberately: no silent overwrites
A professional import is not an overwrite. When the modified file comes back, MSP Planner runs a review-oriented sync:
- Detect — it identifies which rows changed since the last export (dates, work, assignments).
- Review — you see a diff of the proposed changes, not a mystery merge.
- Commit — you explicitly push the accepted changes into the schedule, and from there into Jira.
Deletions get the same courtesy: a task that was in the export but is missing from the return file is flagged — the app does not silently delete your Jira issues on your behalf.
This is the mechanism behind the industry "golden rule" of dual-tool setups: MS Project is the authority for the timeline (deadlines, milestones, dependencies — PM territory), Jira is the authority for execution (status, worklogs, day-to-day work — team territory). The explicit push/pull boundary is what keeps the two authorities from fighting over the same date.
A note on where your data lives
A round-trip integration means your full schedule structure, people, and dates cross the tool boundary — which is exactly what a security review examines. Many "Jira + MS Project" products do this by extracting everything onto the vendor's own servers.
MSP Planner for Jira runs on Atlassian Forge, so the schedule and its identity data operate inside Atlassian's infrastructure — the file exchange is with your own MS Project files, and nothing is parked on an external server. For organizations with data-residency or vendor-risk requirements, that "runs on Atlassian" property turns a procurement headache into a non-issue.
FAQ
How do MS Project tasks stay linked to Jira issues? Each exported task carries a durable identity hash (derived from the issue key) in a reserved MS Project field — Text30. On import, the app reads that field and maps the row to its live issue, instead of matching by name or position.
What happens if someone renames a task in MS Project?
Nothing breaks — the identity hash is separate from the task name. That's precisely why name-based links ([PROJ-218] … in the title) are fragile and identity-based links are not.
Can I use CSV export/import instead? Yes, as a one-way snapshot for occasional reporting. No, as a round-trip — CSV carries no identity, so edited data can't be matched back to the right issues on import.
Does the round trip keep assignments (the workforce) in sync? Yes. Each Jira user carries its own identity in the file, so assignments map back to the actual Jira user with their allocation (Max Units) — not to a name string.
What happens if the returned file is missing a task I exported? It's flagged as a deletion for you to decide. MSP Planner never auto-deletes Jira issues — protecting your board from a stakeholder's accidental edit in MS Project.
Next step
If your MS Project file and your Jira board currently disagree about the same project, the fastest way to feel the difference is to export one real schedule, have a stakeholder edit it in MS Project, and watch the identity-matched diff come back.
See how it works on the MSP Planner for Jira product page, read the MS Project round-trip documentation and the import & export mapping reference, or book a walkthrough.