Portmux is a Jira to Linear migration service that moves your full issue history, sprint context, custom fields, and team workflows into Linear with the issue identifiers (PROJ-123) your engineers cite in PRs and Slack still working.
Most Jira-to-Linear migrations are about getting out of Atlassian's pricing and complexity, not about losing context. The hard part is preserving issue identifiers (engineers grep for them in commit messages), keeping sprint/cycle history intact, and handling custom fields that Linear doesn't natively support. We solve all three.
Jira Projects mapped to Linear Teams; project keys (e.g. PROJ-) preserved as Linear team identifiers so existing PROJ-123 references still resolve.
Every Jira Issue migrated to a Linear Issue with original numeric ID preserved (PROJ-123 → PROJ-123) so commit messages, PRs, and external links keep working.
Jira Issue Types (Story, Task, Bug, Epic, Sub-task) mapped to Linear Issue types via Labels; Sub-tasks become Linear Sub-issues with parent linkage.
Jira Epics mapped to Linear Projects with the Epic's child Issues automatically associated; Epic-level fields preserved on the Project.
Jira Sprints mapped to Linear Cycles with start/end dates, sprint goals, and sprint-issue assignments preserved per team.
All Issue comments migrated with original author (matched by email), timestamp, mentions (re-mapped to Linear users), and Markdown formatting.
Issue attachments downloaded from Jira and re-uploaded to Linear with original filenames; inline images in comments re-linked.
Jira custom fields (text, number, dropdown, multi-select, user picker) mapped to Linear Custom Fields or stored as labels for fields without a Linear equivalent.
Per-project Jira Workflow Statuses mapped to Linear Workflow States (Backlog, Todo, In Progress, In Review, Done, Cancelled).
Jira Labels migrated as Linear Labels; Components migrated as a separate Label set with team scoping.
Jira Versions and Fix Versions mapped to Linear Projects (for releases) or labels (for milestone tracking).
Jira Users matched to Linear Users by email; assignee, reporter, and watcher fields preserved on every issue.
We connect to Jira via API token (Jira Cloud) or PAT (Data Center) with site admin scope, plus Linear via OAuth or API key. The Jira REST API enumerates every project, issue type, custom field, workflow scheme, and screen scheme. Within 48 hours you see a complete Project → Team mapping proposal and a Custom Field translation table for review.
Mapping covers project-to-team, issue type → label, status → workflow state, and custom field → Linear field decisions. The most important mapping is the identifier strategy: we lock down Linear team prefixes so existing Jira issue references (PROJ-123 in commit messages, Slack, GitHub PRs) keep resolving after cutover.
Linear workspace loaded with full issue history in dependency order (Epics → Issues → Sub-issues → comments). Your team validates 5–10 random Issues per Project for fidelity. On cutover day, Jira is set to read-only, the Linear-Jira link in your tools (GitHub, Slack, Figma) is updated, and we deliver an identifier-mapping CSV in case anything needs to be looked up later.
Every migration has its own gotchas. Here's what we plan for on this specific path.
Engineers grep for PROJ-123 in commit messages, Slack, and PR descriptions. Linear assigns its own IDs by default, but we configure Linear team prefixes to match Jira project keys, then load issues in numeric order so the new Linear ID matches the original Jira ID. PROJ-1 stays PROJ-1.
Linear has limited native custom field types. Jira custom fields like Cascading Select, User Picker (multi), and Calculated Fields don't have direct Linear equivalents. We migrate values into Linear Labels or a Description prefix block, and document which fields lost structure so reporting queries can be rewritten.
Jira allows different workflows per project (e.g. Engineering uses In Progress → In Review → Done; Marketing uses Drafting → Approval → Published). Linear has one workflow state set per team. We collapse Jira workflows to the closest Linear states, which may flatten some intermediate statuses, and document each collapse.
Jira Sprints can span multiple boards and have rollover behavior. Linear Cycles are per-team with strict start/end. Past sprints are migrated as Cycles for historical reference; the rollover behavior (issues spilling into the next cycle automatically) is configured fresh in Linear so it matches your team's expectation, not Jira's defaults.
Single-system migrations like Jira to Linear run as Track A engagements: one source, one destination, up to 1M records, 4–6 weeks. Final price depends on object volume, custom field count, and integrations, scoped on a 20-minute call before any commitment. See full pricing →
Tell us what's in the source, where it's going, SaaS or custom, and when you need to be live. You'll walk away with a scoped quote, a named engineer, and a go-live date.