---
title: "Gantt and Jira: how to keep the plan and the work aligned"
description: "Syncing a Gantt chart with Jira Cloud: who owns dates and status, dependencies as Blocks links, conflicts and deletions. A step-by-step guide with Planitude."
url: https://planitude.app/blog/gantt-jira-sync
language: en
---

# Gantt and Jira: how to keep the plan and the work aligned

Jira is great at day-to-day work, but it does not calculate dates from dependencies and calendars. How Planitude’s two-way sync works, who owns what and how to connect it in a few minutes.

by Planitude Team · Published October 2, 2026

In many companies the project exists twice. The **plan**, with phases, dependencies and delivery dates, sits in a Gantt chart prepared by the project manager. The **work**, with tickets, sprints and assignments, sits in Jira. As long as the two stay apart, someone has to copy progress from one to the other by hand, and the plan’s dates go stale quickly.

This article explains why Jira on its own is not enough for scheduling, how the two-way sync between Planitude and Jira Cloud works and which limits are worth knowing before you turn it on.

> **Key takeaways**
>
> - Jira shows dependencies on the timeline and flags conflicts in red[^1], but it does not recalculate dates or identify the **critical path**: that is the job of a scheduling engine.
> - With Planitude every task becomes an issue and every finish-to-start dependency a “Blocks” link; changes travel in both directions.
> - **Planitude owns** name, notes, dates and dependencies; **Jira owns** status and assignee. Neither side ever deletes anything on the other.

## Two tools, two different questions

Jira answers the question *what is the team working on right now?* Backlogs, boards and sprints are built for that. A schedule answers a different question: *when will we finish, and which tasks cannot afford a delay?*

Answering the second one takes durations, dependencies with leads and lags, calendars with holidays, constraints and a calculation that pushes every change downstream. If the new server installation slips by three days, testing, training and go-live must move on their own, and the project manager must know straight away whether the delivery date still holds.

## What Jira is missing for scheduling

Jira is not without planning tools. The timeline shows dependencies between linked items with the “Blocks” link type and, when the dates of two linked items overlap, the dependency line turns red to signal a possible delay[^1]. According to Atlassian’s pricing page, dependencies are managed within a single project on the Free and Standard plans and across projects on Premium[^2].

A warning, however, is not a recalculation: dates stay as they were entered, and the critical path is not among the features described. The result is that the plan lives somewhere else, in a file or another tool, and drifts out of sync. For a full comparison of the two tools, see [Planitude vs Jira](https://planitude.app/blog/planitude-vs-jira).

## How the two-way sync works

The integration connects **one Planitude project to one Jira Cloud project**. Sign-in uses Atlassian OAuth 2.0: Planitude never sees your password, stores the tokens encrypted and renews them with the rotating refresh tokens Atlassian provides, which expire after 90 days of inactivity[^3].

The first time you connect, you choose the initial alignment:

1. **Send the plan to Jira**: an issue is created for every task and a “Blocks” link for every dependency;
2. **Import from Jira**: every existing issue becomes a task at the bottom of the plan, with start date, duration, progress and assignee;
3. **Both**: first the import, then the tasks that are not in Jira yet are sent.

From then on, changes travel both ways. From Planitude to Jira, every change to the plan is detected and sent within seconds, wherever it comes from: the grid, the Gantt chart, an import or the AI assistant. From Jira to Planitude, changes arrive through the webhooks registered by the integration, which Planitude renews before Atlassian’s 30-day expiry[^4], and a check every five minutes picks up any missed events.

Summary tasks can stay in Planitude only or become **Epics**, with the tasks underneath as child issues.

## Who owns what: the field rule

A reliable sync needs a simple rule for every field. In Planitude it is this:

| Planitude | Jira | Owner |
| --- | --- | --- |
| Name | Summary | Planitude |
| Notes | Description | Planitude |
| Start | “Start date” field | Planitude |
| Finish | Due date | Planitude |
| Finish-to-start dependency | “Blocks” link | Planitude |
| Progress | Status (through a transition) | Jira |
| Assignment | Assignee | Jira |

The logic mirrors real work: the plan decides **when**, the team decides **how far along** a task is and **who** is doing it. Status is translated into a percentage with an editable map: by category, to do is 0%, in progress is 50%, done is 100%. If a task is already at 30% and its issue moves to “In Progress”, its progress is not overwritten with a flat 50%.

People are matched automatically by email when the Jira user makes it visible; otherwise you pick the match by hand on the integration page.

## Dependencies, conflicts and deletions

**Dependencies.** Finish-to-start links become “Blocks” links: the predecessor blocks the successor. Start-to-start, finish-to-finish and start-to-finish links have no equivalent in Jira and stay in Planitude only. “Blocks” links added by hand in Jira are neither imported nor deleted.

**Dates changed in Jira.** Because dates are calculated by the plan, a date changed in Jira is set back to the plan’s value and the rejected change appears in the integration log. To move a task, you move it in the plan: the engine also recalculates every task that depends on it.

**Conflicts.** For each field Planitude compares three values: the last agreed value, the current value in the plan and the current value in Jira. If only one side changed, the change goes to the other. If both changed to different values, the field’s owner wins and the conflict is logged with both values. The rule depends only on the data, not on the two servers’ clocks.

**Deletions.** Neither side deletes anything on the other. A task deleted in Planitude leaves the issue in Jira with the `planitude-unlinked` label; an issue deleted in Jira leaves the task in the plan, and the page offers two actions: recreate it in Jira or stop syncing it.

## Connecting Jira step by step

1. Open the project in Planitude and choose **⋯ › Integrations › Jira**.
2. Click **Connect Jira** and grant access on Atlassian’s consent screen.
3. If your account can see several sites, choose the right one, then the **Jira project**.
4. Review the options: default issue type, summary tasks as Epics or not, start date field, label for issues created by Planitude.
5. Choose the **initial alignment**: send, import or both.
6. Check the **People** section and complete any matches that were not found by email.

Planitude writes to Jira as the person who connected the project, so that person needs the Jira permissions to browse the project, create, edit, assign and link issues, and transition them. Owners and editors of the Planitude project can configure the integration; people with read-only access only see its status. The other available integrations are described on the [Integrations](https://planitude.app/integrations) page.

## Known limits

- **Jira Cloud** only: Jira Data Center and Server are not supported.
- **Finish-to-start** dependencies only; one assignee per issue (the person with the most units on the task).
- Dates at **day granularity**: times stay in Planitude.
- Atlassian allows an OAuth app **5 webhooks per user per site**[^4]: beyond the fifth project connected by the same person on the same site, changes from Jira arrive through the five-minute check.
- With the “leaf tasks only” option, a task that becomes a summary is treated as removed and its issue gets the `planitude-unlinked` label.

**Try Planitude with your own plan** [Create a free account](https://planitude.app/signup)

## Frequently asked questions

### Do I need Jira Premium to use the integration?

No. The integration uses the standard Jira Cloud APIs. The critical path and date recalculation come from Planitude, which is free.

### Can I change dates directly in Jira?

You can, but the change is set back to the plan’s value and logged, because dates are calculated from dependencies and calendars. To move a task, you change it in Planitude.

### What happens if I disconnect the project?

Planitude deletes the webhooks and the credentials. The issues stay in Jira with their label and no task in the plan changes.

### Can I connect Azure DevOps as well?

Yes, through an integration built on the same model: Planitude owns the dates, Azure DevOps owns status and assignee. It is described in the [guide to integrations](https://planitude.app/blog/planitude-integrations-guide).

## Sources

Every fact about the products mentioned comes from these official pages, checked in September 2026. Prices are list prices, in the currency and billing period shown by the vendor, and may change.

[^1]: [Atlassian Support: dependencies on the timeline](https://support.atlassian.com/jira-software-cloud/docs/manage-dependencies-between-epics-on-the-timeline/)
[^2]: [Atlassian: Jira pricing](https://www.atlassian.com/software/jira/pricing)
[^3]: [Atlassian Developer: OAuth 2.0 (3LO) apps](https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/)
[^4]: [Atlassian Developer: Jira webhooks](https://developer.atlassian.com/cloud/jira/platform/webhooks/)

## Try Planitude with your own plan

Create a free account, import your .mpp file or start from a template: within minutes you will see the Gantt chart with dependencies, calendars and the critical path.

[Create a free account](https://planitude.app/signup)