← All playbooks
Project management migration

Jira → Linear

Move Jira issues and epics to Linear with a clear choice between one-time import and transition sync, while handling workflows, identities, custom fields, hierarchy, comments, attachments, automation, and rollback.

Typical timeline15–30 business days60–105 hours active work
Statusneeds review
Source testedJira Cloud and Server transition considerations reviewed 2026-07-19
Destination testedLinear Jira importer and sync guidance reviewed 2026-07-19
Last reviewed2026-07-19
Sources3
Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Jira

Reasons to stay
  • Deep workflow, issue, permission, and reporting controls support complex organizations
  • Structured ownership, status, and workflow views improve operational visibility
Reasons to leave
  • Administration and process complexity can slow teams that need a lighter workflow
  • Custom fields, automations, history, and reporting are difficult to reproduce exactly
New platform

Linear

What gets better
  • Fast, opinionated product-development workflows keep software teams focused
  • Structured ownership, status, and workflow views improve operational visibility
What gets worse
  • Non-software work and highly customized enterprise processes fit poorly
  • Custom fields, automations, history, and reporting are difficult to reproduce exactly
Best of the move

Linear: Fast, opinionated product-development workflows keep software teams focused. This removes a major source-side concern: Administration and process complexity can slow teams that need a lighter workflow.

Worst of the move

What you lose: Deep workflow, issue, permission, and reporting controls support complex organizations. What you inherit: Non-software work and highly customized enterprise processes fit poorly.

01At a glance

Know the shape of the move.

Transfer outcome10 features audited
Transfer outcome distributionClean transfer: 1, Partial transfer: 7, Manual rebuild: 1, Not transferred: 1.
Clean1
Partial7
Manual1
Lost1
Mapping route8 of 8 fields have a destination path

This timeline assumes

  • Up to 20 Jira projects and 50,000 in-scope issues.
  • A Linear admin and Jira administrator run the migration.
  • The team chooses one-time import or configured Jira Sync before importing.
  • Only useful history is moved.
  • Jira remains available read-only during verification.
02Loss matrix

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Issue title and descriptioncleancriticalThe dedicated importer supports core issue content.Test rich descriptions, links, and mentions.
Comments and attachmentspartialhighSupported content can import, but identity and file accessibility still need verification.Reconcile decision-heavy comments and open every critical file.
Assignee, creator, and reporterpartialhighIdentity fidelity improves when users connect accounts; otherwise attribution can fall back.Map and connect users before import or sync.
Epics and issue hierarchypartialcriticalJira epics can become Linear projects, but hierarchy constraints differ.Pilot each hierarchy pattern and redesign unsupported levels.
Workflow statusespartialcriticalUnmapped or constrained statuses can stop updates or fall back incorrectly.Create an approved project-to-team and status map.
Issue typespartialhighLinear does not model Jira issue types the same way.Map useful types to labels, projects, or team conventions.
ComponentspartialmediumSynced components appear as labels with special behavior.Approve component-label semantics and test updates.
Custom and required fieldsmanualcriticalUnsupported required fields can block sync; custom fields need explicit mapping.Remove unnecessary requirements or preserve fields in labels/descriptions/integrations.
Automation, apps, dashboards, and reportslostcriticalJira rules, marketplace apps, boards, filters, and dashboards do not become working Linear features.Inventory and rebuild only essential workflows and reports.
Sprints, releases, and historical metricspartialhighLinear cycles and projects have different semantics and analytics.Preserve historical reports and establish a new metric baseline.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Jira projectLinear teamtransformOne Jira space maps to one team in sync.
SummaryTitleautomaticPreserve Jira key in metadata.
DescriptionDescriptionautomaticVerify formatting.
Assignee/reporterAssignee/creatortransformUsers should connect accounts.
EpicProjectautomaticVerify parent-child relationships.
StatusWorkflow statustransformMap every in-scope state.
Component and labelLabeltransformNormalize taxonomy.
Custom fieldLabel, priority, estimate, project, or descriptionmanualNo universal mapping.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve issues, comments, attachments, schemes, workflows, fields, automation, apps, and reporting definitions.

  1. Inventory projects, issue counts, types, statuses, fields, users, permissions, boards, sprints, releases, automation, apps, webhooks, filters, and dashboards.
  2. Export in-scope issues and attachment evidence.
  3. Record project, status, identity, field, and hierarchy maps.
  4. Capture sync/import configuration and tokens without exposing secret values.
  5. Classify work as import, archive, or discard.

Proof to capture: A project manifest reconciles every issue class, field, hierarchy, user, workflow, and dependency.

Transformation · Jira-to-Linear mapping workbook

Workflow and hierarchy map

Prevent Jira configuration from being flattened unpredictably.

  1. Map projects to teams.
  2. Map every status and hierarchy level.
  3. List unsupported constraints and required fields.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Linear importer preview

Identity and scope review

Preserve ownership without importing useless history.

  1. Map users.
  2. Choose active and required history.
  3. Review totals before confirmation.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Design

Import and sync are configured in the wrong order

criticalpossible likelihood

Imported issues are expected to sync but Jira integration was not configured first.

Consequence
Two independent issue sets diverge.
Mitigation
Choose the operating mode before import.

Stop if: The team cannot explain which records are synced and which are not.

Sync

Required fields block creation

criticalpossible likelihood

Linear reports permission or required-field errors.

Consequence
Issues fail to appear in one system.
Mitigation
Simplify requirements and monitor sync banners.

Stop if: Any critical issue has unresolved sync error.

Cutover

Automation runs in both tools

highpossible likelihood

Jira rules and Linear integrations both act on the same event.

Consequence
Duplicate issues and status changes.
Mitigation
Disable source rules before destination activation.

Stop if: A test event produces duplicate work.

06Precise timeline

Do the work in this order.

Estimate forUp to 50,000 issues across 20 Jira projects
Total elapsed15–30 business days
Active work60–105 hours
BufferAdd time for Server/Data Center, complex schemes, marketplace apps, or extended sync.
01
Days 1–4Inventory and mode choice4 days
02
Days 5–6Export and preserve2 days
03
Days 7–11Pilot projects5 days
04
Days 12–22Project waves7–11 days
05
Days 23–30Freeze and observation5–8 days
  1. Days 1–4 · inventory

    Inventory and mode choice

    16–24 hours active4 days elapsedAdmin and owner review waiting
    • Inventory Jira configuration and work.
    • Choose import-only or transition sync.
    • Design Linear teams and workflow.

    Depends on: Jira and Linear admins

    Stop / go checkpoint

    Pilot?

    Go when: Mode, scope, mappings, and owners are approved.

    Stop when: Critical required fields, apps, or hierarchy are unknown.

  2. Days 5–6 · backup

    Export and preserve

    7–12 hours active2 days elapsedExport processing waiting
    • Export issues and evidence.
    • Preserve files, schemes, rules, and reports.

    Depends on: Approved scope

    Stop / go checkpoint

    Configure?

    Go when: Counts and dependencies reconcile.

    Stop when: Any project or critical attachment class is absent.

  3. Days 7–11 · pilot

    Pilot projects

    15–24 hours active5 days elapsedImporter/sync processing waiting
    • Configure destination and optional sync.
    • Import representative projects.
    • Test identity, workflow, hierarchy, comments, and errors.

    Depends on: Backup

    Stop / go checkpoint

    Waves?

    Go when: Each Jira archetype passes.

    Stop when: Critical mapping or sync error remains.

  4. Days 12–22 · waves

    Project waves

    18–34 hours active7–11 days elapsedImport and owner verification waiting
    • Import by dependency wave.
    • Reconcile and repair each project.
    • Rebuild automation and reporting.

    Depends on: Passed pilot

    Stop / go checkpoint

    Cut over?

    Go when: Every wave is complete or excepted.

    Stop when: Counts, access, or sync states are unexplained.

  5. Days 23–30 · cutover

    Freeze and observation

    4–11 hours active5–8 days elapsedNormal workflow and scheduled jobs waiting
    • Freeze Jira writes and automation.
    • Apply final delta.
    • Switch intake and observe one cycle.

    Depends on: Completed waves

    Stop / go checkpoint

    Close rollback?

    Go when: All blocking checks and owner approvals pass.

    Stop when: A critical workflow or integration remains source-only.

07The point of change

Cut over with a way back.

Go live

Cutover

Make Linear authoritative after a reconciled final Jira delta.

Recommended window: After the last sprint review, before a staffed low-change day.

  1. Announce and enforce the Jira freeze.
  2. Disable source automation and intake.
  3. Import or reconcile final changed issues.
  4. Switch integrations, forms, email, and developer links.
  5. Make Jira read-only.
  6. Run triage, planning, delivery, and reporting.

Proof to capture: All active issues reconcile and one system owns intake, status, and automation.

Return to safety

Rollback

Restore Jira without losing Linear changes.

Deadline: Within one sprint or cycle.

  1. Freeze Linear.
  2. Export post-cutover issues and changes.
  3. Restore Jira access and rules.
  4. Apply reviewed deltas.
  5. Restore intake and run policy tests.

Proof to capture: Jira contains current work and Linear is read-only.

Rollback immediately when
  • Missing active issues
  • Unresolved sync errors
  • Wrong hierarchy or status
  • Access failure
  • Critical integration failure
08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingIssue reconciliationCompare by Jira key.100% imported, archived, or excluded.Issue report.
V-02BlockingUsers and attributionCompare assignees, reporters, and comments.Approved identity mapping.User report.
V-03BlockingStatus mappingRun every transition scenario.Correct allowed result.Transition log.
V-04BlockingEpics and sub-issuesCompare representative trees.Approved relationships.Hierarchy diff.
V-05BlockingComments and filesInspect critical issues.Required history and files work.Context log.
V-06BlockingDirection and errorsCreate and update test issues both ways where configured.Declared direction works with no error.Sync log.
V-07BlockingSingle actionTrigger each workflow.One correct destination action.Automation report.
V-08BlockingPermissionsTest admin, member, guest, and unauthorized accounts.Least privilege passes.Access matrix.
09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete sprint or delivery cycle and all project-owner sign-offs.

  1. Archive exports, schemes, mappings, and evidence.
  2. Revoke migration and sync tokens when no longer required.
  3. Remove obsolete Jira automation, webhooks, and apps.
  4. Keep Jira read-only through retention.
  5. Update delivery and reporting documentation.
  6. Schedule quarterly access and workflow reviews.
10Experiences from the field

When the plan met reality.

First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.

Linear’s Oscar Health case study describes moving more than 600 people across engineering, product, data science, IT, and security in just over a month. Oscar imported projects and backlog history but intentionally left behind hundreds of accumulated custom fields and workflows. Adoption expanded after engineers began using the new system, and the simplified structure removed the need to reproduce one of Jira’s most complex configurations.

What they recommend
  • Treat the migration as a chance to delete stale workflow complexity instead of recreating every Jira customization.
  • Start with motivated teams and a clear deadline, then let demonstrated usefulness support wider adoption.
Worth noticing
  • The migration moved useful history but deliberately abandoned custom fields that teams discovered they did not miss.
  • More than 600 users switched in roughly a month despite the source instance’s unusually high complexity.
Sources and maintenance

Built to be reviewed.

Tested 2026-07-19. Next scheduled review: 2026-10-19.

  1. Linear: Jira import and syncAccessed 2026-07-19
  2. Linear: importerAccessed 2026-07-19
  3. Atlassian: export Jira issuesAccessed 2026-07-19