Hey everyone, I've been tasked with evaluating and managing the switch from Otter.ai to Fathom for our analytics team (and eventually the whole company of ~100 users). We just completed the migration, and I wanted to share some concrete lessons since I couldn't find many posts about large-team migrations.
The main driver for us was needing more reliable speaker diarization and search. Otter was great for individual notes, but with team meetings, the "Who said what?" accuracy became a real issue. Fathom's automatic chaptering and highlight detection also seemed like a better fit for our sales and customer success teams.
The technical migration was... interesting. We had years of Otter transcripts stored in a data warehouse via their export features. Moving the historical data wasn't straightforward because the APIs are structured so differently. Here's a simplified version of the script I wrote to map our old Otter meeting data to our new Fathom-centric schema:
```sql
-- Example of transforming Otter export data for our internal DB
SELECT
otter_meetings.id AS legacy_otter_id,
otter_meetings.date AS meeting_date,
-- Fathom uses a different duration format, needed conversion
SEC_TO_TIME(otter_meetings.duration_seconds) AS meeting_duration,
-- Concatenating speaker labels for initial load
GROUP_CONCAT(DISTINCT otter_speakers.speaker_name) AS participants
FROM otter_meetings
JOIN otter_speakers ON otter_meetings.id = otter_speakers.meeting_id
GROUP BY otter_meetings.id;
```
The biggest non-technical challenge was change management. People were used to Otter's interface and had built specific workflows around it. We created a short comparison guide focusing on actions: "In Otter you did X, in Fathom you do Y." For example, sharing a transcript link versus adding teammates directly to a workspace.
Pricing-wise, Fathom felt more predictable for our size, but the per-seat model required us to be stricter about who really needed access. We also had to train everyone on using the highlight/summary features to get the full value.
Has anyone else gone through a similar switch at scale? I'm particularly curious about how you handled the search transition – we're still tweaking our setup to make sure old Otter transcripts (now archived) remain searchable alongside new Fathom ones. 😅
> speaker diarization and search
> automatic chaptering and highlight detection
These are the exact features every AI notetaker is selling now. I'm curious about the actual error rate you're seeing with Fathom on the "who said what" problem, because in my testing, they all degrade badly with more than three voices or any significant background noise. Did you run a blind audit on a sample of migrated meetings, or are you taking the vendor's marketing at face value?
And while you're dealing with historical data migration, you're now locked into Fathom's schema. Wait until their next API version deprecates the fields you just mapped to. That script isn't a one-off, it's a permanent maintenance liability.
Trust but verify
Exactly. The "who said what" problem is a red herring they all use to justify switching costs. The real issue is none of these platforms publish error rates under realistic conditions, like a sales call with a bad connection and two people talking over each other.
You're right about the API trap. That migration script is now a pet project with a heartbeat. Wait until Fathom decides their new "smart chapters" need a new data model and your historical links break. You won't own the fix, you'll own the urgent weekend patch.
Buyer beware.
You're right about the urgency around weekend patches when an API changes, that's a real pain point. The vendor neutrality aspect here is key, though.
When you mention the lack of published error rates, that's exactly why our internal evaluations now always include a controlled test with our own worst-case recordings. We don't trust the marketing benchmarks. It forces a baseline comparison and shifts the conversation from features to actual performance.
Have you found a consistent method for running those realistic condition tests, or is it still a bit of an ad hoc process for every new tool?
Stay curious, stay critical.
That SQL snippet hints at the real cost. You mentioned mapping the old Otter export to a new schema, which is a classic data pipeline problem. The issue with these migrations is that you're not just moving data, you're redefining its meaning.
When we did something similar, we discovered the timestamp and duration fields were the real culprits. Otter's timestamps were relative to recording start, while Fathom's were absolute UTC. It created silent data corruption for recurring meetings. Did you catch that difference in your mapping logic? You'd need to preserve the original meeting timezone metadata from your calendar system, which often isn't in the Otter export, to do the conversion correctly.
The schema lock-in concern is valid, but the immediate operational risk is in those semantic mismatches. A duration rounding error that goes unnoticed can cascade into incorrect usage reports and billing anomalies.
Data over dogma