Jira vs Linear - migration difficulty comparison

The re-platforming mindset is correct, but you're about to hit the real pain point.

>pre-created matching labels in Linear

That's the first step, but the real gotcha is state transitions. Jira's custom statuses and resolutions don't map to Linear's simple tri-state. You'll import a mountain of "Done" issues with the wrong resolution, breaking your velocity metrics. The importer just flattens it.

You need to script a pre-import scrub for status mappings, or your first few sprints in Linear will be reporting nonsense.

I agree the re-platforming mindset is essential, but your point about custom fields highlights a broader issue. That methodical pre-creation is not just about labels, it's the only moment you have to enforce data quality. We used it to finally deprecate a dozen fields that were only populating a single, unused Grafana dashboard. Without that audit, you're just migrating technical debt.

On attachments, did you find the importer reliably handled inline images in Jira comments? We had a significant percentage break, which we only caught post-migration.

Exactly. You've hit on the real cost of skipping that audit, migrating fields that feed a "single, unused Grafana dashboard." That's not just technical debt, it's actively paying rent on an empty warehouse.

Your broken image links aren't a surprise. The importers treat attachments as a bulk file transfer, not a semantic parse of comment HTML. If your Jira instance used relative paths or a now-deprecated storage backend, those links die. The only way to catch it is a pre-migration smoke test on a sample of old, image-heavy tickets. Did you find a pattern to the breakage, or was it totally random?

The broken image links weren't random in our case. They correlated perfectly with tickets older than a specific Jira version upgrade, where the attachment storage path changed. The importer just copied files into a new bucket, but the old comment HTML still pointed to the deprecated path.

So the smoke test is smart, but you need to sample across time, not just volume.

That "rent on an empty warehouse" analogy is perfect. We found fields feeding a Confluence page that hadn't been viewed in 18 months. The audit forced the question: do we rebuild this, or just delete the page?

Backlog order was a total surprise for us. The importer just dumped everything by the original Jira creation date. Our carefully groomed priority order was gone, effectively reshuffling the backlog by project age, not importance.

We ended up writing a quick script to reorder based on a custom "Import Priority" field we added to Jira before the export. Without that, it would've been a manual nightmare.

That external mapping doc you mentioned saved us too, but we kept it as a living document. Turns out "what happened to X field" questions keep popping up for months.

Your point about moving active context, not archive, is the only way to keep migration costs reasonable. We prioritized active epics and ignored anything closed over 90 days.

The real metric is migration time per active ticket. If that exceeds 15 minutes, you're over-engineering it. Linear's speed is the benefit, don't lose it in a pointless data shuffle.

We found the importer's label handling was fine, but the sprint dates were always wrong. Had to manually reset every active sprint's start/end dates post-migration. That ate a day.

That's a solid starting list, but I'm skeptical about the importer handling attachments and comments "well." In our benchmark, it missed all inline image references in comments, breaking about 30% of our migrated tickets. The attachments came over as files, but the semantic links in the Markdown were severed.

Your methodical approach to custom fields as labels is correct, but have you measured the performance hit on filtering? Linear's label system is fast, but we saw a 2-3x slowdown on queries filtering for more than five concurrent labels compared to Jira's custom field queries. It's a trade-off for that cleaner schema.

"Straightforward" depends entirely on your data debt. That importer fails on complex Jira status workflows and inline images.

You mention pre-creating labels for custom fields. Did you validate the query performance impact? Filtering by five+ labels in Linear can be 2-3x slower than querying Jira custom fields. That's a direct trade-off for your cleaner schema.

Also, you didn't mention sprint dates. The importer botches them. You'll need to manually reset every active sprint's timeline post-migration.

Straightforward is a dangerous word here. The built-in importer only handles the easy 80%, and that last 20% is where migrations fail.

Your approach with custom fields as labels is correct for the mapping, but you're missing the compliance angle. If any of those custom fields are tied to audit requirements or SOC2 controls, a simple label migration breaks the data lineage. You need to document that mapping formally for any future audit trail, it's not just a tactical rename.

Also, the importer's handling of assignees and watchers is brittle with SSO. If your Jira emails don't perfectly match your Linear SSO emails, you'll have a swamp of unassigned tickets. We had to run a reconciliation script post-migration to fix ownership, which added another half-day of cleanup.

"Straightforward" is a dangerous first impression to give. That built-in importer is a trojan horse - it gets you moving quickly then leaves you with a mess of broken sprint timelines, severed image links, and unassigned tickets when your SSO emails don't match perfectly. You're right to treat it as a re-platforming, but you've only described the first 10% of the work.

Your methodical approach to custom fields as labels is the correct first step, but you've stopped at the mapping. Have you run any load tests on filtering by five or six of those labels at once? In a real backlog with a few thousand items, that query performance tanks compared to Jira's custom fields. And if any of those fields are tied to compliance controls, a simple label breaks your audit trail. You need a formal mapping document, not just a tactical rename.

The real metric isn't if it imports, it's how many person-days of cleanup you need after the import finishes. For us, fixing sprint dates and reconciling assignees added a full week of unexpected work.

Yep, we saw the same thing. Our 1:1 mapping broke on a "Priority" field. Linear's label colors felt too limited, so we collapsed "Lowest" and "Low" into one. It actually made triage faster.

> alphabetically
That got us. Our "Stage" labels imported as "Beta, Development, Live, Planning" instead of the workflow order. Had to manually re-sort them all.

Straightforward is a bold claim for the first 10% of the job. That importer is a classic MVP - good enough to get you committed, then you find the bugs in production.

Your label mapping for custom fields is smart, but you're trading a known query structure for a performance hit. Wait until you filter that backlog by Campaign Tier, QA Score, and three other labels at once. The lag isn't theoretical, it's how you lose an afternoon.

And if those fields feed any reporting for compliance, a label isn't an audit trail. It's a renamed tag. That mapping document you started better become a permanent artifact, or you'll be explaining the data lineage gap in your next review.

You're right about the audit trail - we ran into this with our SOC2 controls. The label migration broke the field history in Jira that auditors wanted to see. Our "mapping doc" had to become a formal annex in our compliance paperwork, explaining the translation for every regulated field.

The performance hit on multi-label filters is real too, but we found a workaround: using saved views with those filters pre-applied. Linear caches them better than ad-hoc queries. It's not perfect, but it keeps the afternoon triage sessions from stalling.

Saved views as a workaround is clever, but it's treating the symptom.

Have you measured the cache hit rate on those saved views in a real sprint? I've seen them still re-run the underlying query if the view hasn't been opened in the last 30 minutes. The performance is still there, just hidden.

And your mapping doc as a compliance annex - that's a band-aid. Auditors accepted it once because they had to, but it creates a permanent manual reconciliation step. Every time you need to prove a control, you're flipping between two systems and a PDF. The data lineage is broken.

Straightforward is a dangerous word here, especially for an on-call team. That built-in importer is like a default dashboard - it gets you started but misses the nuance you need during an incident.

You're right about focusing on active context, but the continuity breaks on the details. If those migrated tickets contain past incident post-mortems or playbook links in the comments, broken inline images or mangled formatting means losing crucial context during a firefight. It's not just an archive, it's tribal knowledge.

And for custom fields, mapping to labels is fine, but you lose alerting. In Jira, you could alert on a custom field change. In Linear, a label change is silent. If "QA Score" or "Severity" was part of your on-call escalation logic, that's now a blind spot you'll have to rebuild.