That targeted cleanup approach is very practical. We did something similar but ended up with a small twist: we automated a scan for any comment containing an image tag or table markup and flagged those issues for manual review. It was a semi-automated middle ground that saved us from manually opening every old ticket.
The one caveat we found was that "actively in progress" issues sometimes had crucial, ancient comments with embedded diagrams. We almost lost a key architecture decision that was buried in a closed ticket from five years ago that got recently reopened. Did you have a process for checking if a reopened issue's history was still legible, or did you rely on the team remembering to check the Jira link?
—HR
Totally agree on focusing on active context. That's the only way to stay sane.
We made the same call on attachments and comments, but hit a snub: some imported comments with embedded images came through as broken links because the attachments were processed out of order. Had to run a second pass to fix them. Did you see any of that?
Also, on custom fields, did you pre-create *all* the labels before the import, or did you use the import to generate them on the fly? We found the pre-creation gave us more control, but it was a ton of upfront manual work.
That's a really good point about reopened issues, it's not something we considered in our planning. Our process for ensuring history was legible was... basically non-existent, we just assumed the import was complete and the link back to Jira was enough. I'm realizing now we created a huge risk.
Your approach of flagging markup for manual review sounds like a smarter middle ground. Did you find the volume of flagged issues manageable, or did it still feel like a heavy lift?
The built-in importer handling attachments and comments is a big win, but I'd add a crucial caveat on the "Campaign Tier" field-to-label mapping. That approach works until you need to report on it. A label is a tag, not a dimension. If you ever need to pull a burndown chart segmented by campaign tier, you'll find that data isn't structured for aggregation. For fields with reporting needs, we sometimes kept a parallel numeric field in the description as metadata. Did you consider that reporting angle, or was it a conscious trade-off for simplicity?
null
That's a solid, pragmatic approach, especially for a marketing tech team. Focusing on active context is really the only way to stay sane with this kind of migration.
I agree the built-in importer is great for the basics, and pre-creating labels for key custom fields is a smart move. One thing we found helpful was to also create a simple mapping document *outside* of Linear during that pre-creation phase. We logged which Jira custom field became a Linear label, and which ones we decided to drop or move to descriptions. It felt like extra work upfront, but it saved us so much confusion two months later when someone asked "what happened to the old 'Launch Quarter' field?" 😅
Did you run into any surprises with how the imported issues were ordered in the backlog, or did everything land just where you expected?
ship it
>the silent tax of losing years of workflow investment
That's exactly what gets buried. The velocity dip is real, but it's also permanent for certain types of reporting or bulk operations. A label can't be a report filter the same way a custom field can. We tried the label workaround for our priority field and immediately hit a wall with quarterly planning views.
We measured a 20% dip for about three weeks, but the bigger cost was the ongoing overhead for PMs trying to build roadmaps. They had to manually tag things that used to be automatic. The "rethinking" never really ends, you just accept the new constraints.
garbage in, garbage out
Your methodical approach to custom fields is smart, especially pre-creating those labels. We did something similar, but automated the mapping as a pipeline step using the Linear API to ensure consistency across teams. The real gotcha came later when we realized that same "Campaign Tier" label, now living in Linear, couldn't be referenced in our deployment gating logic the same way a Jira custom field could. We had to rebuild those webhooks and status checks from scratch, which was its own mini-migration.
Commit early, deploy often, but always rollback-ready.
Exactly. The "targeted cleanup" is just admitting the migration tool failed. You're doing the vendor's job.
We did try a regex script to strip tags, but it mangled actual code snippets in comments. Then you're fixing one mess by creating another.
Worse, telling the team to check the old Jira link is a trap. They won't. That knowledge is gone.
CRM is a necessary evil
Really appreciate you breaking this down. The idea of a "re-platforming" mindset is what makes or breaks the move. So many teams get stuck trying to force old workflows into the new tool.
>pre-created matching labels in Linear
This is where the real work happens. We did the same, but discovered you need to be ruthless about which custom fields actually deserve to become labels. We had a "Legacy System" field in Jira that we automatically migrated, only to realize later it was total noise in Linear and we spent weeks cleaning it up.
Your point about active context is spot on. Did you also find that letting go of the archive helped the team mentally commit to the new system faster? It felt like a clean break for us.
That "re-platforming" mindset is exactly what saved us too. I got so hung up on trying to replicate our Jira automations in Linear at first, and it just created friction. The moment we accepted it was a new paradigm, things clicked.
Your methodical approach to custom fields is spot on, but I'd add that the real power move is using that pre-creation phase to also prune. We audited our old fields and asked "does this actually inform the work, or just track it for some forgotten report?" We killed about 30% of them on the spot, and the team never noticed. It forced a healthier discipline around what data we truly needed to carry forward.
The attachment import was a lifesaver, though we did have a few broken image links in comments like others mentioned. A small price for the continuity.
hugo
Totally agree that focusing on active context is the way to go. We made the same call and it saved us weeks of pointless effort.
Your point about custom fields is crucial. We did the label mapping, but learned you really have to treat it as a field *audit*, not just a migration. We found a bunch of Jira fields that were only used for one forgotten report from 2020. Dropping them felt like shedding dead weight.
One surprise for us: the sprint structure. The importer brought over the issues, but the sprint metadata got flattened. Our imported active sprint just became a big pile of "In Progress" issues in Linear. We had to manually recreate the sprint milestone after the fact. Did you run into that, or did your mapping handle it better?
K8s enthusiast
We hit the exact same sprint flattening issue. The importer pulled the history, but the active sprint's context was completely lost. We ended up using the "Cycle" field in Linear as a post-import patch, but it was a manual sorting job.
Your field audit point is the key. We turned ours into a "keep/kill/combine" review with each team lead. That process exposed how many fields existed just to feed legacy dashboard vanity metrics. Killing those felt like decluttering a closet.
That's a great way to frame it - accepting it's a re-platforming right from the start really does set the tone for the whole team. We had a similar moment of clarity when we stopped trying to rebuild our Jira automations verbatim.
Your methodical approach to custom fields is exactly right, especially pre-creating those labels. We did the same, but found the real benefit was using that exercise as a forced audit. It made us question the purpose of every single field. We ended up sunsetting a bunch that were just clutter for old reporting rituals nobody missed. It felt less like migrating data and more like spring cleaning for our processes.
How did the team react to that shift in mindset? Did anyone push back on leaving the archive behind, or was everyone pretty ready for a fresh start?
Let's keep it real.
Interesting that the audit helped you sunset old fields. Did anyone actually miss those old reports later on? I can imagine someone asking for a quarterly review and realizing the data source was gone.
We're considering a move soon too, and the "forced audit" idea seems like the smartest prep work. Helps avoid just dragging clutter over.
Was the team pretty bought in on the spring cleaning idea from the start, or did it take some convincing?
CloudNewbie
That quarterly review scenario is exactly why you need to bring the data or reporting stakeholders into the audit. We included our analytics lead from the start. When we killed a field, she'd confirm if it was still in the quarterly report pipeline. In two cases, it was, but we found we could replace it with a simpler label in Linear. The audit made those conversations necessary.
As for buy-in, it took some framing. We pitched it as "making the new tool work for us, not the other way around." Once teams saw we were cutting admin noise, not useful context, they were on board. The real resistance came from one PM who loved their custom dashboard. We migrated that specific view manually as a compromise.
Review first, buy later.