ProductQuant published a Mixpanel-to-PostHog write-up for a healthcare forms platform. Jake McMahon is the consultant. The client is not named. This is a consultant case study, and ProductQuant also sells the same migration as a $10,000 to $20,000 engagement.
They say the product had about 2,700 customers and had been in Mixpanel since 2021. Four years, 906,000 events, 228 event types. Mixpanel’s enterprise pricing sat at $20,000 to $50,000 a year. The team did not fully trust the data.
If you are looking at the same route, start with the Mixpanel → PostHog playbook. PostHog’s managed Mixpanel import is the path they recommended. The compliance work happened before that import ran.
Why they left Mixpanel
The events existed. The questions they needed answered did not. Naming was inconsistent. Properties were missing. Some events had never been checked for protected health information.
A new product was launching at the same time. They needed collection on the old app and the new one without a gap.
ProductQuant put Mixpanel at $20,000 to $50,000 a year. At about 19,000 events a month, they said the same volume fits PostHog’s free tier. Even at 2 million events a month they quoted about $50 a month, with a BAA and group analytics on standard pricing. Those are the consultant’s cost model, not an invoice I can open.
Audit first, then decide what cannot move
They pulled the full Mixpanel set from November 2021 forward. They ranked the top 10 events by volume, marked low-value leftovers, and scored the schema.
Then they reviewed every event type for PHI. The situation section names 4 events with patient identifiers that could not migrate as-is. The later summary says 18 HIPAA-risk event types were excluded and 210 were safe. I am reporting both figures as written. I am not collapsing them into one number.
Exclusion rules went in before any historical copy. Behavioral events could move. The risky ones stayed out.
They also mapped 17 Mixpanel SDK methods. Twelve had a direct PostHog match, so they called about 70% of the conversion automatic. Five methods needed a person. They counted more than 170 SDK calls across the two products.
How the data moved
They ranked four migration paths and picked PostHog’s managed import. PostHog’s current docs match that shape. You create a Cloud project, sit on a paid product-analytics plan so the feature unlocks, and run a managed Mixpanel job. Historical imports are not billed as live ingestion. PostHog connects with Mixpanel credentials, exports a date range, remaps the schema, and loads the events.
Each direct Mixpanel job covers at most one year. Four years means consecutive jobs. PostHog also says Mixpanel’s export API does not like huge extracts, so large estates may need an S3 drop instead. Managed jobs do not deduplicate. If you stop and rerun the same range, you get doubles.
ProductQuant’s timeline was six weeks, with phase gates and QA. They handed developers conversion examples for every SDK method and a two-product cutover plan so both apps kept sending. They claim zero downtime and zero data loss on the events they chose to move.
Live collection ran on both platforms during the launch. That dual-run is the part I would keep even if you skip the paid consultant.
What they gained
They put the annual analytics cut at 90%, from $20,000 to $50,000 down to effectively $0 at current volume. The 906,000 events they approved were preserved. Compliance got a written list of what moved and what did not.
Dashboards were rebuilt on purpose. Unused Mixpanel views were dropped. They ran a side-by-side window and cut over after reconciliation.
I am treating the 90% and the $0 lines as the consultant’s model. The useful outcome is cheaper collection plus an explicit PHI ledger.
What the case study skips
The client is anonymous. There is no Mixpanel project ID, no failed job, and no rollback. “Zero data loss” applies to the events they marked safe, not to the 18 types they left behind.
PostHog will not delete selected imported events later. Get the schema right on a test project first. Their docs say that before you start.
Identity stitching, consent, and Mixpanel cohorts are not in the write-up. The playbook treats those as partial or manual. Reports do not become PostHog insights on their own.
If you need to go back, the reverse playbook is PostHog → Mixpanel.
What I would copy
Inventory every event for identifiers before you hand Mixpanel credentials to anyone. Write down the exclude list. Importing first and cleaning later is how PHI lands in the new warehouse.
Run the managed job against a throwaway PostHog project on a short date range. Check event names, timestamps, and distinct IDs. Then run year-sized jobs in order.
Keep Mixpanel collecting through one full business cycle on both products. Compare a few core funnels before you turn the old SDK off.
Do not rerun a managed job over the same dates. PostHog will not collapse the duplicates.
The Mixpanel → PostHog playbook is the checklist I would run. Use ProductQuant’s page for the “exclude PHI, then import” order, and remember it is a consultant selling the same work.