Mixpanel → PostHog

Step-by-step migration

1. 01

   Export your list from Mixpanel

   Pull a fresh CSV of every active subscriber. Capture the fields you actually use downstream: email is required, name is standard, signup date and tier (free/paid) are useful when Mixpanel provides them.

2. 02

   Provision PostHog

   Sign up, set sender identity, and verify your sending domain (DKIM, SPF, DMARC). Do this before importing the list; sending from an unverified domain is the single fastest way to land in spam at the moment of cutover.

3. 03

   Import the list and map fields

   Upload the CSV. Map email + name + any custom fields. Decide whether to import as one list or split into segments/tags. Mixpanel-style organization rarely maps 1:1, so plan the split before the upload, not after.

4. 04

   Rebuild automations and templates

   PostHog's automation builder is structurally similar but won't import Mixpanel's flows directly. Rebuild only what you actively use; the move is a chance to delete the unused ones rather than lift-and-shift dead infrastructure.

5. 05

   Send a test broadcast

   Pick a small segment and send a real broadcast (not just a preview). Verify deliverability, link clicks, and unsubscribe flow. If anything's off, you find it before the announcement, not after.

6. 06

   Announce the move and cut over

   Send your last broadcast from Mixpanel announcing the new sender domain and what to expect. Cut over DNS and sending from PostHog on the same day, not staggered. A dual-send week creates more confusion than it prevents.

Mixpanel-to-PostHog specific gotchas

Universal steps cover most of the work. These are the failure modes unique to this exact pair.

• #1

  Event-schema migration: Mixpanel events have a slightly different shape from PostHog events (Mixpanel's `distinct_id` and `properties` map to PostHog's `distinct_id` and `properties` but the SDK calls differ). Plan a parallel-tracking window of 2-4 weeks where you instrument BOTH SDKs in your app, verify event parity in PostHog, then deprecate the Mixpanel SDK call. Don't cut over without parallel-tracking; you'll lose data continuity.

• #2

  Historical data import: PostHog accepts a CSV import of historical Mixpanel events but the import preserves event names, properties, and timestamps only. Mixpanel-derived cohorts, saved reports, and dashboards do NOT import; rebuild only the dashboards that drive ongoing decisions.

• #3

  User-property reconciliation: Mixpanel `set` and `set_once` calls map to PostHog `identify` calls but with different deduplication behavior. Audit which user properties are load-bearing in your dashboards before cutover; rebuild the property-tracking logic in PostHog rather than expecting a 1:1 port.

• #4

  Session replay setup: if you're consolidating from Mixpanel + LogRocket / FullStory, the replay SDK is a separate install. PostHog's replay SDK can be enabled via the same posthog-js package but requires explicit configuration (record canvas elements, redact form inputs, enable network capture). Test on staging first.

• #5

  Feature-flag rollout: if you're consolidating from LaunchDarkly, PostHog feature flags don't have LaunchDarkly's targeting-rules language. Plan to rebuild flag rules from scratch using PostHog's user-property and group-membership filters; the rebuild is usually simpler than the LaunchDarkly setup but requires re-thinking the targeting logic.

• #6

  Self-hosted vs cloud: if you're picking PostHog Cloud, the migration is straightforward. If you're going self-hosted, factor the operational cost (Postgres + Kafka + Plugin Server + ClickHouse for replay / large-scale analytics). Self-host pencils for teams with existing platform engineering capacity, not as a way to save money on day one.

Common questions

Is PostHog cheaper than Mixpanel?

Both start at the same headline price (Free). The reason to migrate is the pricing model and feature scope, not the entry-tier number.

Will my data transfer cleanly?

Most analytics data transfers, but rarely 1:1. The "Pair-specific gotchas" section above is hand-curated for this exact migration: it covers what exports from Mixpanel, how it imports into PostHog, and which structural pieces (workflows, integrations, custom domains) require rebuild rather than direct port. The constraint usually isn't the data export; it's the rebuild work for anything PostHog models differently.

How long does the migration take?

A clean migration for this pair is typically 1-2 weeks of focused work: data export, integration reconnection (CRMs, webhooks, payment processors), feature rebuild for whatever doesn't port directly, test run, cutover. The constraint is rarely the export itself; it's the integration reconnection and the rebuild work for any feature that PostHog models differently from Mixpanel.

Are Mixpanel and PostHog direct competitors?

Yes. Both are primarily analytics tools, which is why this is a defensible head-to-head migration rather than a cross-category consolidation.

Where can I see Mixpanel vs PostHog side-by-side?

The /compare/mixpanel-vs-posthog page on TierGauge shows side-by-side plans, headline pricing, included features, and limit comparison at the entry paid tier. This migration guide is the long-form decision narrative; the compare page is the data-only dashboard.