Skip to main content

Microsoft Project and Jira: How to Run One Schedule in Both Without Losing Data

For a lot of delivery organizations, two tools refuse to die. Jira is where the team actually works — issues, sprints, boards, worklogs. Microsoft Project is what the PMO, the steering committee, and the external customer still expect to see — a formal schedule with a critical path, baselines, and dependencies that look like a "real" plan.

So the project manager ends up maintaining the same project twice: once in Jira for the team, once in an .mpp file for the report. They drift apart within a week. The schedule that gets presented to stakeholders is already a polite work of fiction by the time it hits the projector.

This guide explains how to stop running two disconnected plans — how to export a Jira schedule to Microsoft Project, edit it there, and import it back without breaking the link to your live Jira issues.

Why Jira and MS Project don't talk to each other natively​

Jira and Microsoft Project model work in fundamentally different ways, which is exactly why naive "convert the file" approaches fall apart:

  • Jira thinks in issues and status — a backlog of work items that move across a board. It has no native concept of a critical path, a schedule baseline, or finish-to-start dependency types (FS/SS/FF/SF).
  • MS Project thinks in tasks and time — a deterministic schedule where every task has a calculated start/finish driven by dependencies, calendars, and effort.

You can technically export issues to CSV and open them in Project, but it's a one-way dump. The moment you edit the schedule in Project, there's no way back: nothing knows that "row 14" is PROJ-218. Re-importing creates duplicates, breaks assignees, and detaches the plan from the work. The round trip is where every simple integration breaks.

What "true round-trip" actually means​

A useful MS Project ↔ Jira integration has to preserve identity across the boundary. That means every task in the exported file carries a durable marker tying it back to its Jira issue and the people on it, so when the file comes back, the system knows:

  • which row corresponds to which live Jira issue (no duplicates, no re-keying);
  • which assignment maps to which Jira user;
  • which rows are schedule-only (milestones, external dependencies, the PMO's own structure) and have no Jira issue behind them at all.

That last point matters more than it looks. Real schedules are hybrid: some tasks are team work tracked in Jira, and some are external commitments or governance milestones that should never become Jira tickets. A proper bridge lets both live in one schedule.

How to run one schedule across Jira and MS Project​

Here's the practical workflow, using MSP Planner for Jira — a Forge-native app that adds a professional scheduling layer on top of Jira and exchanges it losslessly with Microsoft Project.

1. Build the schedule on top of your Jira data​

Start in Jira, not in Project. Pull your Jira issues into a structured schedule — nest them into a hierarchy, set real dependencies (FS/SS/FF/SF), and add schedule-only milestones for the things Jira doesn't track. The result is a deterministic plan with a deadline-aware critical path, driven by the same issues your team is already working.

tip

Keep your Jira board as the operational source of truth for what the work is. Use the schedule for when it happens and what it depends on. Mixing those two responsibilities is what makes most Jira-only plans inaccurate.

2. Export to Microsoft Project for formal review​

When the PMO or an external customer needs the plan in their format, export the schedule to a standard MS Project file. Because the export preserves dependency types, hierarchy, baselines, and resource assignments, what opens in Project is a real schedule — not a flat list of issues. Your stakeholders review and annotate it in the tool they already trust.

3. Edit in Project, then import back — without losing structure​

This is the step ordinary integrations can't do. Someone re-plans dates in Project, shuffles dependencies, adjusts a milestone — and you import the file back into Jira. Thanks to the identity markers carried in the file, the app reconciles each row to its existing Jira issue instead of creating a duplicate. Your live links survive the round trip.

4. Reconcile deliberately, with no silent overwrites​

Synchronization should never be a black box that quietly clobbers someone's work. Use explicit push / pull flows to reconcile the schedule against Jira: you decide what gets written back and when. Sync boundaries are anchored to server-side timestamps, so "who changed what, and when" stays accurate regardless of anyone's browser clock — which is what makes the round trip safe to do repeatedly.

5. Keep the plan honest with actuals​

A schedule is only credible if it's measured against reality. Because the app reads Jira worklogs, you can compare planned work against actual logged time, and set a baseline at kickoff to see exactly where and why the schedule is drifting — the same baseline-vs-actual view the steering committee wants, sourced from the work your team is already doing.

A note on where your data lives​

It's worth flagging, because it usually surfaces during security review: many "Jira + MS Project" tools work by extracting your project, schedule, and people data onto the vendor's own servers.

MSP Planner for Jira runs on Atlassian Forge, which means it operates inside Atlassian's infrastructure — your planning data stays within the Atlassian environment and isn't copied to an external server. For any organization with data-residency or vendor-risk requirements, "runs on Atlassian" turns a procurement objection into a non-issue.

FAQ​

Can I import an existing MS Project plan into Jira? Yes. You can bring an .mpp-style schedule into the app and map its tasks onto Jira issues, then keep working the round trip from there. Tasks that shouldn't become Jira issues can stay as schedule-only rows.

Will round-tripping create duplicate Jira issues? No — that's the whole point of identity preservation. Each exported task carries a marker tying it back to its Jira issue, so re-importing updates the existing issue instead of creating a new one.

Do I need a Microsoft Project license for every team member? No. The team works in Jira. Only the people who actually review or produce the formal MS Project file need Project — typically the PMO or a project manager, not the whole delivery team.

Does this support task dependencies and a critical path? Yes. The schedule supports the four standard dependency types (FS/SS/FF/SF), task hierarchy, and a deadline-aware critical path, which is what makes the exported file a genuine MS Project schedule rather than a flat task list.

Is this a Gantt chart tool? It includes scheduling visuals, but the point is the professional planning engine underneath — critical path, baselines, calendars, and the lossless MS Project bridge — not just drawing bars on a timeline.

Next step​

If you're currently maintaining the same project twice — once in Jira for the team and once in MS Project for the report — the fastest way to feel the difference is to model one real project once and export it both ways.

See how it works on the MSP Planner for Jira product page, read the documentation, or book a walkthrough.