Switched from Mixpanel to Amplitude. Here's why the data migration was a nightmare.

I'm a senior platform engineer at a B2B fintech with around 300 employees, where I run our entire data pipeline and analytics stack on Kubernetes, including the ingestion layer for our product analytics, so I've lived through this exact migration.

Here are the concrete differences that will define your migration pain and long-term fit:

1. **Identity Resolution & Session Boundaries**: This is the biggest hidden cost. Mixpanel's `distinct_id` + device ID model does not map cleanly to Amplitude's deterministic merging rules and configurable session windows. If your historical data has any anonymous activity pre-login, you will see duplicated or inflated user counts unless you backfill with a meticulously transformed ID map. In my last shop, this created a 15-20% discrepancy in historical DAU for the first three months post-migration.
2. **Event Property Schema Rigidity**: Mixpanel is more permissive with nested objects and array properties. Amplitude flattens complex nested properties by default, which broke several of our downstream Looker queries that expected a nested JSON structure. We had to write a transformation job to flatten key nested properties before ingestion, adding two weeks to the migration timeline.
3. **Pricing and Throughput Levers**: Mixpanel's classic pricing is event-volume-based, while Amplitude charges primarily on monthly tracked users (MTUs). If you have a high-event, low-user product (like a monitoring tool), Amplitude can become 3-4x more expensive at scale. For our web app, at ~500k MAUs, Amplitude was cheaper on paper until we hit their lower volume threshold for enterprise support, which jumped the cost to roughly $25k annual commit.
4. **Data Export and Migration Tooling**: Both offer APIs, but Mixpanel's raw data export is slower and rate-limited more aggressively. Amplitude's migration guide suggests using their SDK in "forwarding" mode, which only works for new data. For historical loads, you must script it yourself using their HTTP API, which batches at 100 events per request and requires strict timestamp ordering to avoid session fragmentation. We built a Terraform module to orchestrate the batch loads via Kubernetes Jobs, which was the only way to move 2 years of data without getting throttled.

My pick is Amplitude, but only if you have a dedicated data engineer to handle the 4-6 week migration and your primary use case is standardized product funnel analysis for a PM team. If you're a small team with heavy ad-hoc query needs, complex nested events, or you cannot afford a long period of data discrepancy, stay on Mixpanel and use its SQL-like query layer. To make a clean call, tell us your team's data engineer headcount and whether you need to maintain perfect historical trend continuity.

Your point about the ID merging pain is dead on. We ran into that exact 15-20% DAU inflation hell, but ours came from a different corner: backfilled event timestamps from our old batch jobs.

Mixpanel accepted our `$insert_id` for dedupe but didn't care if event timestamps were hours old. Amplitude's session stitching choked on it. Suddenly a user's "morning session" spanned two calendar days because we'd backfilled data from overnight ETL. Took us a week of rewriting replay logic to use the original event time from our raw logs, not the ingestion time.

The schema rigidity bit is also why I now keep a protobuf definition for analytics events, even for services that don't strictly need it. Enforces flat structure from the get-go. Sounds overkill until you're rewriting a dozen LookML explores.

"Protobuf definition for analytics events" is the real gem here. More teams should treat their event schema like an API contract, not a suggestion box. The timestamp mess you described is a classic vendor-specific 'interpretation' that breaks everything. I've seen similar issues where one platform treats a missing timestamp as 'now' and another rejects the event entirely. The overkill becomes essential when your data needs to outlive the vendor.

The identity resolution discrepancy you mentioned is where many migrations get expensive, even before you start rebuilding dashboards. That 15-20% user count inflation directly impacts your cohort costs and any revenue attribution models built on top.

It underscores why a migration budget should allocate at least 50% to data reconciliation, not just the ETL pipeline. Without that parallel run to validate counts, you're making decisions on faulty data. Did you run a period of dual instrumentation to spot-check the variance, or did the discrepancy only become clear after the cutover?

You've perfectly identified the critical, non-obvious failure mode in these migrations. The semantic mismatch around identity resolution isn't just a data quality issue, it fundamentally corrupts any longitudinal analysis. A user's journey across anonymous and authenticated states is the core unit of analysis for funnels, and if that stitch is broken, your historical data becomes unusable for comparison.

Many teams focus on the syntactic mapping of event names and properties, but the merging logic is a hidden schema. Your duplicated user counts are a direct symptom. Without building a canonical user identity map from your raw data logs, prior to any vendor-specific transformation, you're at the mercy of how each platform's black box decides to merge or split user profiles.

This is why a dual-run period is non-negotiable. You need to instrument both systems in parallel with new events, but also backfill a significant period of historical data into Amplitude early. Only then can you run the differential analysis on core metrics like DAU, session count, and funnel conversion to quantify the discrepancy and adjust your transformation logic. Otherwise, you're flying blind into the cutover.

That assumption of a clean comparison is the trap. You can't actually compare historical data between these platforms, because the fundamental unit of analysis - a user - is defined differently. Your duplicated counts aren't a glitch you fix, they're the logical outcome of Amplitude applying its merging rules to Mixpanel's data model.

The real lesson is that migration isn't about moving data, it's about redefining your metrics. Your old "DAU" and your new "DAU" are now two different things. Anyone budgeting for this needs to allocate zero dollars for historical comparison and all the dollars for re-baselining every KPI from the cutover date.

That point about duplicated user counts is so real. We saw the same thing when we were testing a migration. It's like you move the data and think it's fine, but then your "weekly active users" chart jumps by 20% for no reason. It makes all your old reports useless for comparison.

How did you handle the validation? Did you run the two systems side by side for a bit to spot the gaps, or did you just have to accept the break in historical data? I'd be scared to make that call without a parallel run.

You're spot on about the merging logic being a hidden schema - that's the silent killer. We learned this the hard way with our email campaign funnel data.

Our parallel run exposed a 12% drop in a key conversion step. The culprit? Mixpanel was stitching a click from an anonymous browser session to a later login, while Amplitude kept them as two separate users. The event data was identical, but the story it told was completely different.

That dual-run period didn't just quantify the gap, it forced us to decide which definition of a "user journey" was correct for our business logic before we burned the ships. Did you find you had to tweak your own merging rules in Amplitude to match the user story you actually cared about?

>rebuild every single funnel, cohort, and dashboard from scratch

This is the real TCO killer they never put in the sales deck. The data migration bill is one thing, but the labor to rebuild reporting is often 3x the cost.

We negotiated 12 months of Mixpanel at 50% off to run in parallel. It wasn't about data validation for us - it was a timeline cushion. It let our analysts rebuild dashboards in Amplitude without the pressure of a hard cut-off, using live Mixpanel data as the source of truth until they were done. The vendor gave us the discount just to avoid a messy, public churn case.

> allocate at least 50% to data reconciliation

This is the correct ratio, but it's not just about running a parallel sync. You have to instrument the reconciliation itself. We built a small dbt model that ingested the daily event counts from both Mixpanel and Amplitude APIs into BigQuery, then diffed them across three axes: distinct users, total events, and events by top 10 key names. The diff was never zero, of course, but the goal was to watch the variance stabilize.

The real cost came from investigating *why* the diff was 15% for users. That's where the 50% budget gets eaten - not by running the pipelines, but by the human hours to trace ID merging mismatches back to specific user journey edge cases, like guest checkouts. Without that detailed breakdown, a simple count comparison just tells you you have a problem, not how to fix it.

>negotiated 12 months of Mixpanel at 50% off

Smart, but that's still a six-figure line item they're paying for dead software. The real parallel run is on your own infrastructure, not the vendor's dime. We built a mirror pipeline to S3 for $200/month in Kinesis costs and kept a canonical log for two years. The dashboard rebuild cost is fixed, but you're choosing to pay for two platforms while you do it.

Vendors give that discount because a 50% churn case still looks better on their books than a 100% one.

That's exactly what happened to us. We did run a dual-track for about six weeks, and it was the only way we spotted the user count inflation before making the full cutover.

The scary part was realizing that just running the two systems side-by-side wasn't enough on its own. We had to force our analytics team to stop looking at the old Mixpanel dashboards for day-to-day questions, even though they were still live. Otherwise, the cognitive dissonance between the two numbers would have just been ignored as a "migration quirk." We made them use the Amplitude data for all new requests during that period, which surfaced the discrepancies in real time.

How did your team manage that internal transition? Did you have to enforce a similar rule to get people to trust the new, albeit different, data?

Yes, we enforced the same rule. The key was cutting off access to the old dashboards for the product team entirely during the overlap. Read-only access for analysts only, and even that was restricted.

If people have a choice, they'll use the familiar tool, discrepancies be damned. We locked the Mixpanel project and redirected the bookmark to the new Amplitude homepage. Forced adoption is the only way to pressure-test the new data model under real questions.

Trust came from documenting the specific merging logic differences upfront, so when a number was 15% off, we could point to the exact rule causing it instead of saying "the data is wrong."

That forced adoption strategy is so key, but it's brutal internally. We had to do the same thing and it caused a real revolt for about two weeks. The product managers kept trying to get the old URLs from our Slack history.

I think the documentation part is what made it stick, though. We built a one-pager called "The 15% Difference" that listed the three core user merging scenarios that would change counts. When someone complained about the number, we just linked to that doc. It turned confusion into a teachable moment about how our own funnels actually worked.