Why Linear's execution graph beat Jira at AI-native organisations.

The named migrations and what they share

Of the 47 migrations INTELAR has tracked, seven are public enough to name with permission from procurement-side sources who agreed to be cited on background. Anthropic's product engineering organisation completed its Jira-to-Linear migration in February 2025, replacing a Jira instance that had been running since the company was 40 people. Perplexity migrated in May 2025, citing the integration burden of Jira's connector framework with the company's expanding agent stack as the primary driver. Modal Labs, the serverless GPU infrastructure company, migrated in June 2025 after running parallel instances for three weeks. Replicate, the model-hosting platform, migrated in August 2025 in conjunction with a broader internal-tools consolidation. Vercel migrated in October 2025 in what the company's engineering blog described as a "structural alignment" of its execution model with its agent-development practice. Hugging Face migrated its internal engineering instance in November 2025, retaining Jira only for the regulated-customer-support function that required its existing audit-trail certification. Mistral migrated its core platform engineering organisation in January 2026, completing a transition that had been discussed since the company's Series B.

The seven named migrations share five structural characteristics. They all involved engineering organisations between 30 and 220 engineers at the time of the migration. They all involved active deployment of at least two agent tools — Devin, Claude Code, Cursor background agents, or comparable — that needed to read and write into the project-management graph. They all involved a documented Jira instance that had accumulated configuration complexity over multiple years, multiple project-management leadership transitions, and multiple acquisition-driven workflow merges. They all involved a procurement-side cost analysis that included not just the seat-licence comparison but the engineering-time cost of agent-integration maintenance against Jira's configuration surface. And they all involved a senior engineering leader — typically a VP of Engineering or a Head of Platform — who had personally used Linear at a prior company and had been advocating for the migration for at least two quarters before the decision was made.

The migration economics, as INTELAR's procurement-side records establish them, ran tighter than the public discussion of Linear-versus-Jira pricing typically assumes. The licence-cost gap was real but smaller than the headline figures suggest: Linear's effective per-user cost at the Plus tier ranged from $14 to $19 monthly, depending on annual-billing discount and procurement leverage. Jira's effective per-user cost at the Premium tier ranged from $11 to $16 monthly across the same buyer cohort. The migration-decisive cost was not the licence. It was the engineering-time cost of agent-integration maintenance, which ran between three and eight engineering hours per week on Jira-anchored stacks and between zero and two on Linear-anchored stacks. At the engineering hourly rates these companies pay — call it $120 per hour fully loaded — the engineering-time differential alone produced a payback period of under four months on the migration cost. The licence delta was a tiebreaker. The integration time was the deal.

The data-model difference, in concrete terms

The conversation about Linear versus Jira tends to flatten into a conversation about user experience, and the user-experience comparison favours Linear by a margin that has been litigated since the tool's earliest releases. The data-model comparison is the more consequential one, and it is the comparison that matters for the agent-integration story. Linear's data model treats cycles, projects, and issues as first-class typed entities. A cycle is a fixed-duration execution window, two weeks by default, against which issues are scheduled. A project is a scoped deliverable against which multiple cycles can contribute. An issue belongs to a cycle and a project, with that membership encoded as a typed relationship the API exposes natively. The typed graph is small but opinionated.

Jira's data model is structurally agnostic. The terms — sprint, epic, story, task — are configurable. The relationships between them are configurable. The workflow states are configurable. The custom fields are configurable. The configuration surface is the source of both the tool's strength and its decline. An engineering organisation that has been running Jira for five years has accumulated a configuration that reflects every workflow decision, every team-merger compromise, and every leadership transition that has touched the tool in that time. The configuration is, in effect, the organisation's project-management history. The history is rarely deliberately designed. It is what the configuration has become.

The agent-integration consequence of the two data models becomes legible when an engineering team tries to wire an agent — Claude Code, Devin, a Cursor background agent — to read project context and write issue updates. Linear's typed graph means the agent can fetch the current cycle, find the issues belonging to a project, and reason about the project state with a minimal prompt context. The agent does not need to learn the schema. The schema is fixed. Jira's configurable graph means the agent needs to learn the schema for every Jira instance it integrates with — which custom fields the team uses, which workflow states represent which lifecycle phases, which epic types correspond to which project shapes. The schema-learning cost is real, and it is borne every time the configuration changes. A team that revises its Jira workflow has to revise every agent integration that consumes the workflow. The maintenance burden is not theoretical. The INTELAR migration sample documented an average of 2.4 schema-related agent-integration outages per quarter across the Jira-anchored stacks, against zero across the Linear-anchored stacks in the same period.

The agent-integration story in production

The agent integrations that drove the 2025 migration wave were not theoretical. They were running in production at each of the named migrations before the migrations completed, and the production patterns are what justified the migration cost. The most consequential pattern is Claude Code's read-write integration with Linear, which Anthropic shipped to public availability in March 2025. The integration lets an engineer running Claude Code on a feature branch query the relevant Linear issue, read the acceptance criteria, write progress updates back to the issue, and close the issue when the feature passes the team's CI pipeline. The integration depends on Linear's typed schema in ways that would be either expensive or fragile against Jira's configurable schema. The engineering teams that depend on Claude Code's Linear integration did not have a structurally comparable Jira path.

Devin's Linear integration produces a different but equally instructive pattern. Cognition Labs shipped Devin's Linear connector in May 2025, with the design objective that a senior engineer could assign a Linear issue to Devin and the agent would execute the work end-to-end — code, tests, pull request, status updates — without further intervention. The connector relies on Linear's typed issue-state model to determine when the agent should commit and when it should escalate. The same pattern against Jira would require Cognition to model every customer's workflow configuration, which Cognition has declined to do for the technical and commercial reasons the company has publicly discussed. Devin's Linear integration is officially supported. The Jira integration is documented as available but not officially supported, and the supportability gap is the commercial signal the buyers have been reading.

Cursor's background agents represent the most recent and most production-critical of the integrations. The background agent — a Cursor feature that lets the IDE run multi-step development tasks against the codebase asynchronously — depends on a project-context substrate that defines what the agent should work on and how it should report progress. Cursor's official guidance, published in October 2025, recommends Linear as the project-context substrate for background agents. The recommendation is not exclusive — the company supports a Jira integration — but the recommendation is editorial in the way that vendor recommendations are editorial: it tells the buyer where the supported, tested, defensible path runs. The buyers that have been adopting Cursor at scale have been reading that recommendation and migrating off Jira to remove the friction the recommendation implies. The pattern compounds across vendors. Each new agent integration that lands first or best against Linear is a structural reason for the next migration to happen.

Cycles, projects, and the sprint that doesn't quite map

The migration friction Linear's typed model produces is most visible at the moment the migrating team has to map their Jira concepts onto Linear's primitives. The mapping is rarely clean. Jira's sprint and Linear's cycle are nominally equivalent — both are fixed-duration execution windows — but the operational reality is that most Jira sprints in mature organisations have accumulated practices that don't translate. The sprint-spillover concept, where issues that don't complete in one sprint roll forward to the next, is a Jira-specific workflow that Linear's cycle model deliberately discourages. Linear's design position is that an issue that does not complete in a cycle should either be returned to the backlog for re-prioritisation or be explicitly carried into the next cycle with a documented reason. The discipline is more rigorous. The migration friction is real.

The project-versus-epic mapping is similarly imperfect. Jira's epic is configurable; Linear's project is opinionated. Linear projects have status, lead, target date, and a defined scope; Jira epics inherit whatever fields the team has configured. The migrating team typically discovers that their Jira epics have been used for at least three different things — quarterly themes, individual features, and customer-specific deliverables — that do not all map cleanly onto Linear's project primitive. The remediation work is the conversation the migrating team has to have with itself about what its epics actually represent and how the work should be organised. The conversation is uncomfortable and necessary, and it is one of the migration's most underestimated costs. INTELAR's sample shows that engineering organisations took an average of 11 working days to complete the epic-to-project mapping conversation, with the variance explained mostly by the maturity of the pre-existing Jira configuration and the patience of the engineering leadership for the meeting overhead the conversation requires.

The benefit, on the other side of the friction, is the project graph that the team produces. A clean Linear instance — issues belonging to cycles, cycles contributing to projects, projects scoped to deliverables, the typed relationships between them encoded in the schema — is a substrate against which an agent can reason without further prompt engineering. The agent reads the project. It infers the deliverable. It identifies the cycle. It executes against the issue. The substrate is the work, and the work pays off every time an agent integrates against it. The Jira instance the team left behind, in the words of one VP of Engineering INTELAR spoke with, "was carrying nine years of decisions we'd never gone back to clean up. The migration was the cleanup. The agent stack was the reason we finally did it."

Atlassian's response and the strategic stakes

Atlassian has not been passive in the face of the migration acceleration. The company shipped Rovo, its agent-platform layer, to general availability in late 2024 and has been extending the surface across 2025 and early 2026. The Rovo strategy positions Atlassian as the agent-substrate for the Jira-anchored stack: rather than ask buyers to move to a typed schema, Atlassian proposes to provide an agent-aware adaptation layer that reads the buyer's Jira configuration, learns the schema, and exposes a typed interface to integrating agents. The architectural argument is defensible. The commercial question is whether the adaptation layer can deliver the integration ergonomics that Linear achieves natively, and at what cost.

The buyer-side evidence so far is mixed. Rovo's adoption inside the existing Jira customer base reached 27 per cent of paying organisations by the close of 2025 on Atlassian's published figures, which is a meaningful share given the product's first-year availability. The agent-integration ergonomics, against the agents the migrating cohort cares about — Claude Code, Devin, Cursor's background agents — remain imperfect. Each of those agents has shipped or improved Linear integrations during 2025 and has shipped or maintained Jira integrations as second-class citizens. The vendor pattern is consistent. The vendor pattern is the signal Atlassian needs to reverse. Each quarter in which the agent vendors continue to treat Linear as the primary integration target and Jira as the compatibility target is a quarter in which the migration gravity continues to favour Linear.

Atlassian's strategic options narrow as the migration cohort matures. The company can continue to invest in Rovo as the adaptation layer, accepting that the integration ergonomics will lag Linear's native schema for some period. The company can acquire a typed-schema product and re-platform Jira against it, which is the most expensive option and the one that would face the most disruption to the existing customer base. The company can compete on the dimensions where Jira's incumbency is structural — the regulated industries where audit-trail certification, GDPR-data-residency commitments, and enterprise compliance infrastructure remain Atlassian's enduring advantages. The third option is the one the company's recent strategic communications have most clearly pursued. The 2026 question is whether the regulated incumbency holds the migration share above zero in the AI-native segment, or whether Linear's enterprise compliance maturation closes the gap fast enough to make even the regulated industries vulnerable. INTELAR's procurement-side records show Linear's enterprise compliance roadmap accelerating: SOC 2 Type II, ISO 27001, HIPAA-eligible deployment, and FedRAMP Moderate are all either complete or on the 2026 roadmap. The gap that protected Atlassian's regulated incumbency is closing on a published timeline.

What to watch

The Linear-Jira migration story is not finished. The 2026 question is whether the next cohort of migrations comes from the enterprise tier — organisations above 500 engineers and the regulated buyers — or whether Atlassian's strategic response is sufficient to hold that tier through the next renewal cycle. The signals worth tracking:

• Whether Linear's enterprise compliance roadmap delivers FedRAMP Moderate and HIPAA-eligible deployment on the 2026 timeline; if both ship on schedule, the structural barrier that has protected Atlassian's regulated incumbency falls, and the migration cohort expands to include healthcare, financial services, and federal-customer-facing buyers that have not previously been in scope.
• Whether Rovo's adoption inside the Jira base translates into agent-integration parity; the share figure is the leading indicator, but the buyers care about the integration ergonomics with their preferred agents, and the next four quarters will produce the evidence on whether Atlassian's adaptation layer can deliver Linear-equivalent integration against Claude Code, Devin, and Cursor's background agents.
• Whether Linear's typed-schema approach attracts competition from a new entrant; the agent-coding cohort has created a structural demand for project-management substrates that are agent-friendly, and the venture pipeline contains at least two early-stage companies INTELAR is tracking that are positioning against the same demand with different architectural choices.
• Whether the engineering-time-cost calculus that has driven the migrations holds as the agent vendors mature their Jira connectors; Atlassian's commercial argument depends on the connector ergonomics improving fast enough that the engineering-time differential between the two stacks compresses below the migration cost, and Cognition's, Anthropic's, and Cursor's product roadmaps will determine whether that compression happens.
• Whether Linear's pricing discipline holds as the buyer mix shifts toward larger enterprise contracts; the company has been able to maintain its premium positioning because the migrating cohort has been willing to pay for the integration ergonomics, but the enterprise tier comes with procurement-side leverage that the SMB cohort did not exercise, and the question is whether Linear's commercial team can hold the price points as the deal sizes grow.

Frequently asked

What is Linear's execution graph, and why does it matter for agent integrations?

Linear's execution graph is the typed schema connecting cycles, projects, and issues as first-class entities with defined relationships. The schema is fixed: a cycle is a two-week execution window, a project is a scoped deliverable, an issue belongs to both with typed connections the API exposes natively. The agent-integration consequence is that an agent — Claude Code, Devin, Cursor's background agents — can reason about the project context with a minimal prompt because the schema is not negotiable. Jira's configurable schema requires the agent to learn the configuration for every instance it integrates with, and the schema-learning cost is borne every time the configuration changes.

Which AI-native organisations have publicly migrated from Jira to Linear?

Of the 47 migrations INTELAR has tracked, seven are public enough to name with permission from procurement-side sources. Anthropic completed its migration in February 2025. Perplexity migrated in May 2025. Modal Labs migrated in June 2025. Replicate migrated in August 2025. Vercel migrated in October 2025. Hugging Face migrated its internal engineering instance in November 2025. Mistral migrated its core platform engineering organisation in January 2026. The shared structural characteristics — 30 to 220 engineers at migration, active agent stack of two or more tools, accumulated Jira configuration complexity, senior engineering advocate — define the migrating cohort more precisely than the public discussion of Linear-versus-Jira typically captures.

How does the migration cost compare to the engineering-time savings?

The migration cost runs primarily as engineering-time investment over a six-to-twelve-week transition window. The named migrations INTELAR tracked invested between $80,000 and $340,000 in engineering time on the migration, with the variance explained by the complexity of the pre-existing Jira configuration. The engineering-time savings on agent-integration maintenance run between three and eight hours per engineer per week on Jira-anchored stacks against zero to two on Linear-anchored stacks. At fully loaded engineering hourly rates of approximately $120, the payback period on the migration investment ran under four months across the named cohort. The licence-cost delta — Linear runs slightly higher than Jira at the per-seat tier these companies negotiate — is the tiebreaker, not the deal.

Why are Claude Code and Devin treating Linear as the primary integration target?

Because the typed schema makes the integration economics defensible. An agent integration against Linear can be built once, tested against the published schema, and deployed across every Linear customer with predictable behaviour. An agent integration against Jira has to handle the schema variation of every customer's configuration, which means either limited functionality across the population or per-customer schema-learning that the agent vendor has to amortise across the customer base. Anthropic, Cognition, and Cursor have all made the same commercial decision: invest in the Linear integration as the supported, tested, defensible path, and treat the Jira integration as a compatibility target rather than a first-class product surface.

What is Atlassian's strategic response, and is it working?

Atlassian's strategy centres on Rovo, the company's agent-platform layer, which positions itself as an adaptation layer that learns the buyer's Jira configuration and exposes a typed interface to integrating agents. Rovo reached 27 per cent adoption inside the Jira customer base by the close of 2025 on Atlassian's published figures. The agent-integration ergonomics, against the agents the migrating cohort cares about, remain imperfect. The next four quarters will produce the evidence on whether Atlassian can deliver Linear-equivalent integration via the adaptation layer, or whether the migration acceleration continues. The company is also competing harder on the dimensions where Jira's incumbency is structural — regulated industries, audit-trail certification, enterprise compliance infrastructure — and the question is how long those structural advantages hold as Linear's enterprise compliance roadmap closes the gap.

Is the Linear migration appropriate for every engineering organisation?

No. The migration is most defensible for AI-native organisations with active agent stacks, between 30 and 300 engineers, and accumulated Jira configuration complexity that has become a tax on the agent-integration work. Organisations below 30 engineers rarely have the integration burden that justifies the migration cost. Organisations above 500 engineers with mature Jira deployments and significant regulated-compliance requirements face migration costs that may not pay back within the renewal cycle, and Atlassian's incumbency in regulated environments is structurally hard to displace. The migration is appropriate for the segment where the agent integration economics make the difference, which is currently the AI-native mid-market — and that segment is precisely where Linear's commercial focus has been.