Oscar Health is a US health insurer founded in 2012. Linear’s customer page lists about 2,400 people company-wide and a June 2025 switch.
Staff engineer Pete Zalewski moved more than 600 people off Jira onto Linear. Engineering, product, data science, IT, and security. Linear says the whole move took just over a month.
The public write-up is a Linear customer story, so it is a vendor page. I searched Oscar’s public engineering posts and did not find a matching write-up. This case study stays with what Pete and VP of Engineering Greg Chagnon said there, plus the official docs that match the steps.
If you are looking at the same route, start with the Jira → Linear playbook. Linear’s Jira importer is the generic path. Oscar’s version looks short because they imported projects and backlog history, then dropped the custom fields instead of rebuilding them.
Why they left
Pete had been a Jira admin earlier in his career, not as his main job. He watched teams take every custom field they were offered. Those fields piled into a workflow that fit nobody.
Oscar’s instance looked like that again, with hundreds of custom fields and years of process stacked on process. Pete said Atlassian once told them it was among the three most complex Jira instances in the world.
Then they hit Jira’s custom field limit. Teams started reusing fields that already existed, with different meanings in different workflows. One field they named was Provider Specialty Details. Provider-network corrections used it. Engineering also used it on bug reports for expected behavior.
Linear says Oscar wanted to get faster. The page does not give a cost number, so I am not quoting one.
Atlassian now documents field limits in Jira Cloud: 700 fields per space, enforced from March 2026. Oscar switched in June 2025, so that 700 figure is current Cloud policy, not the exact cap they hit. The reuse is the part the case study names.
What they moved
Linear’s importer pulled projects and backlog history. Pete said the export and import were straightforward even at their size. Atlassian’s issue export is the Jira-side counterpart, CSV or otherwise.
Linear’s import guide tells you to decide which history is still worth having. Oscar kept the backlog and dropped the field scheme.
The importer map covers titles, descriptions, comments, assignees, priorities, statuses, labels, estimates, due dates, created dates, parent/child links, and epics-as-projects. Issue types and components become labels. Images come over as files, and other attachments land as URLs back to Jira.
Custom fields are not in that map. Linear says they will not import. Oscar framed the gap as a cleanup, and Pete said people have not missed those fields or the old workflows.
The Jira → Linear playbook says the same thing in the loss matrix. Custom fields need a manual map, or you drop them. Jira automation, marketplace apps, boards, filters, and dashboards do not become Linear features. You rebuild the ones you still need.
Pete said they did not have to herd people onto Linear. Engineers started using it, and the rest of the company followed.
What they gained
Infrastructure and platform teams had been taking one-off requests in chat. Those threads were hard to track or prioritize. They put that intake into Linear Asks, which turns Slack, email, or form requests into issues.
Greg used to spend hours each week assembling status from spreadsheets and Google Docs. He now opens a Custom View before Monday meetings.
He said people seem happier on Linear, which is his line on a vendor page, not a measured score.
The interview does not give a velocity number or a dollar figure.
What the vendor page skips
Linear’s story does not list a failed import, a broken integration, or a rollback. We only know what they chose to leave behind: the custom fields, the old workflows, and the Jira apps and dashboards the playbook says will not travel.
If some of those fields still mattered, the data is still in Jira unless they archived it. The case study does not say they shut Jira down.
Linear also offers Jira Sync for a dual-running period. Required fields on the Jira side can block issue creation, unmapped statuses do not update, and a parent change in Linear can fail Jira’s hierarchy rules. Oscar’s write-up talks about import and a fast switch, not about months of two-way sync. I am not inventing a sync setup they did not describe.
If GitHub Issues is the destination instead, that is a different route. We already wrote about Spring Framework’s move, and the Jira → GitHub Issues playbook covers it.
What I would copy
Inventory every custom field before you import. Mark each one as map, archive, or drop. Oscar left them behind, and Linear cannot import those fields anyway, so a pilot that expects them in Linear is testing the wrong thing.
Run the importer against one team first. Confirm comments, assignees, and attachments. Open a few non-image files and see that they still point at Jira. If you need those files after Jira goes read-only, copy them now.
Put chat requests into Asks before you call the migration done. That is how Oscar made the one-off platform work visible.
Give leadership one Custom View that replaces the status spreadsheet. Greg’s Monday meeting view is the example Linear published.
Keep a rollback path. The playbook’s reverse route is Linear → Jira, which Oscar did not describe using.
The Jira → Linear playbook is the checklist I would run. Use the Linear interview for the “leave the fields behind” call, and remember it is a vendor page.