Hey everyone! 👋 I've been seeing a lot of chatter lately about teams contemplating the big switch from Jira to something like Asana, especially for larger dev shops. We actually went through this exact migration about 18 months ago at my previous company, which was right around the 100-engineer mark. It was a massive undertaking, and the question of historical data haunted us for weeks.
Let me share our journey, the good, the bad, and the ugly, especially around that history loss dilemma. For us, the driving factors were cost, a desire for a less complex workflow for our non-engineering teams, and Asana's cleaner interface for project tracking. But losing all those Jira tickets felt like we were erasing our team's memory.
Here’s how we broke down the problem and what we decided:
* **The "Keep Everything" Camp:** Our initial plan was a full migration using various third-party tools. We spent nearly a month testing them. The result? A mess. Custom fields broke, links were dead, and subtask hierarchies became unusable. The fidelity was just never there, and the effort to clean it up post-migration was projected to be another 3-4 months of part-time work from a dedicated engineer.
* **The "Essentials Only" Compromise:** We pivoted hard. We realized we didn't need every single bug report from 2015. What we *needed* was:
* All active epics, stories, and bugs for in-flight projects.
* Key historical decisions linked to specific tickets (we exported these as PDFs and attached them to a central wiki page).
* A clean, searchable archive of *completed* epics from the last two years, which we exported as CSV and stored in a dedicated S3 bucket, indexed by project and quarter.
* **The Cutover & Buy-in:** This was the hardest part. We ran the two systems in parallel for a single 6-week sprint. It was painful and double the work, but it was absolutely critical for team adoption. We held daily office hours for the first two weeks. The key was having champions in each scrum team who we trained intensively beforehand.
So, was it worth the history loss? For us, **yes, but with a huge asterisk.** The immediate boost in clarity and cross-team collaboration was tangible. However, that "archive" in S3 has been queried maybe three times in 18 months. The real value was in preserving the narrative of *why* we built things, not every single ticket.
My advice? Don't migrate history for history's sake. Audit what you actually reference. The energy you save from a failed full-data migration is better spent on meticulous planning for active work and change management. The team's willingness to move forward is more valuable than a perfect archive of the past. I'm curious—for those who've made a similar jump, how did you handle the knowledge preservation piece? Did anyone find a graceful way to keep linked issue histories intact?
null
Hey OP, I'm Maya - marketing ops at a 110-person SaaS company. We run Asana for project tracking and campaign management, with a dev team of about 30 that uses it for sprint work alongside engineering's Jira (they stayed put).
Here's our breakdown after a year:
**Fit & workflow:** Asana is built for cross-functional project tracking, not pure software development. For your 100-dev shop, the lack of native branching/merging ties or built-in release trains is a real limitation. We use it for marketing because the timeline view and dependency tracking is fantastic for campaign launches.
**Real pricing:** Asana's "Business" tier is where you get the advanced workflows and forms, running $24.99/user/month billed annually. The hidden cost is that you'll likely need to keep a separate tool for true bug tracking or code-heavy sprints, which is a duplicate license cost.
**Integration effort:** Connecting Asana to our data warehouse (Snowflake) for reporting took about 40 hours of our data engineer's time to get custom fields flowing correctly. Native integrations are great for Slack and Google Drive, but deep API work for custom statuses was a project.
**Where it breaks:** Asana's strength is simplicity, so complex Jira ticket hierarchies with layered sub-tasks will flatten. We lost the ability to auto-create tickets from commits, which our devs hated. Reporting is good for velocity and deadlines, but weak for burn-down charts.
I'd pick Asana only if your primary goal is unifying non-dev teams (product, marketing, support) onto a single platform and devs can accept a simpler workflow. If dev workflow is paramount, stick with Jira.
To make a clean call, tell us: 1) what percentage of your tickets are pure dev work vs. cross-team projects, and 2) is your main pain point Jira's cost or its complexity for non-technical users?
You're absolutely right to highlight the "Keep Everything" fallacy. I've seen this derail more migrations than any technical hurdle. The sunk cost fallacy in data migration is a brutal psychological trap.
Teams fixate on preserving every comment and status change from five years ago, when 80% of that data has zero operational value post-migration. The effort you described, cleaning up broken links and hierarchies for months, becomes a tax on future velocity. Sometimes a controlled burn of the historical underbrush is the pragmatic choice for a healthier system, even if it feels like amnesia.
Did you quantify the *active* reference rate of tickets older than, say, 18 months? Most shops find it's shockingly low, which reframes "loss" into "archival."
James K.
Totally agree about the "active reference rate" being key. We tried to pull that data during a CRM migration and it was eye opening. Maybe 5% of tickets older than a year were ever reopened or referenced.
But I'd add one caveat - don't forget about compliance or audit needs. We had to keep a frozen, read-only archive of the old system just for that reason, even though no one used it day-to-day. It was a cheap insurance policy.
How did you handle the actual "cut off" date for what to bring over? Was it purely age based, or did you filter by ticket type or project too?
MartechStruggles