TL;DR

  • Mixpanel and PostHog SDKs are nearly identical — mixpanel.track() becomes posthog.capture(); mixpanel.identify() becomes posthog.identify(). The code conversion is straightforward.
  • The risky part of migration is not the SDK swap — it is deciding which events to bring. Migrating a bad taxonomy into a new platform just moves the problem. The pre-migration audit determines which events are worth keeping.
  • Three historical data options: PostHog's managed migration (no code required), S3/GCS intermediate export (most reliable for large datasets), or start fresh (recommended when the existing taxonomy has significant technical debt).
  • For healthcare SaaS: conduct a HIPAA risk review before migrating. Any event with patient-identifiable properties (patient names, record IDs linked to individuals) must be redesigned before cutover — not migrated as-is into PostHog.
  • PostHog at $2,004/yr for 1.5M events/month with group analytics included — compared to Mixpanel at ~$2,100/yr and Amplitude at $3,348/yr for the same volume. PostHog also includes 7-year data retention vs 1–2 years at competitors.

If you are evaluating Mixpanel to PostHog migration, the commercial case is usually one of three things: HIPAA compliance requirements, the group analytics pricing gap, or data retention limits (Mixpanel's free plan retains 5 years; paid tiers vary; PostHog retains 7 years on all plans).

The migration itself is technically straightforward. PostHog's SDK is nearly identical to Mixpanel's — the two platforms were designed around the same core event model, and most function names have direct equivalents. An engineer who knows one can work with the other within hours.

The harder question is what to bring with you.

"Migrating a bad event taxonomy into a new platform doesn't fix it. You just have the same unusable data in a different tool."

The pre-migration audit — deciding which events to carry forward, which to redesign, and which to leave behind — is where most of the value in a migration comes from. This guide covers both: the audit process and the technical migration steps.

Why Teams Migrate from Mixpanel to PostHog

The three most common migration drivers:

HIPAA Compliance

Mixpanel's HIPAA Business Associate Agreement (BAA) is only available on enterprise plans, which require custom pricing negotiations. PostHog includes BAA coverage at standard pricing tiers — no enterprise contract required, no minimum commitment. For healthcare SaaS teams who need both a BAA and group analytics (for practice-level tracking), PostHog is the only platform that provides both at standard pricing.

Group Analytics Cost

Group analytics — the ability to analyse behaviour at the account or organisation level rather than just the individual user level — is an enterprise add-on at Mixpanel and Amplitude. At typical B2B SaaS event volumes (1.5M events/month), the verified pricing comparison is:

Platform Annual Cost (1.5M events/mo) Group Analytics HIPAA BAA Data Retention
PostHog Cloud $2,004/yr Included Included 7 years
Mixpanel ~$2,100/yr Add-on Enterprise only 1–5 years (plan dependent)
Amplitude $3,348/yr Enterprise add-on Enterprise only 1 year (free), longer on paid

Pricing verified November 2025 from platform pricing pages and calculators at 15,000 MTUs / 1.5M events per month. Mixpanel/Amplitude enterprise BAA + group analytics costs $20,000–50,000+/yr.

Open Source and Self-Hosting Option

PostHog is open source, with a self-hosted deployment option for teams with strict data residency requirements. Mixpanel and Amplitude are cloud-only. For teams that need to keep event data on their own infrastructure, PostHog is the only major product analytics platform that makes this possible without custom development.

Step 1 — The Pre-Migration Audit

Before any data moves, audit your existing Mixpanel events. The goal is to make two lists: events to carry forward and events to redesign or drop.

Export Your Full Event List

In Mixpanel: Lexicon → Events → export the full event list with fire rates and last-fired dates. This gives you the inventory to work from.

In a recent healthcare SaaS migration, the audit surfaced 228 event types with 905,981 historical events spanning ~4 years. The audit found:

  • Events that answered no analytical question — tracked because they were technically easy to fire, not because they informed any decision. These were dropped.
  • Events with inconsistent naming — the same user action tracked under three different names from three different development sprints. These were consolidated.
  • HIPAA-risk events — events containing potential patient-identifiable information that needed to be redesigned before any migration. In this audit, these included Records View Patient (31,337 events), Records Add Patient Initiated, and others. These were not migrated.
  • Events with zero properties — events that fired but captured no metadata, making them unsegmentable. These were either redesigned with properties or dropped.
HIPAA Compliance Note

If you are in healthcare, the pre-migration audit is a compliance step, not just a housekeeping step. Any event containing patient-identifiable properties must be identified and removed before migration. Events like "view patient record" that include patient IDs or names in properties are potential HIPAA violations — and migrating them from Mixpanel to PostHog just moves the liability. The correct approach is to redesign these events using internal staff IDs and remove all patient-identifiable properties before or during the migration.

Pre-Migration Audit Checklist

Pre-Migration Checklist
  • Export full event list from Mixpanel Lexicon with fire rates and last-fired dates
  • Classify each event by functional area (authentication, core objects, collaboration, billing, etc.)
  • Apply the JTBD test: does this event tell us if users are getting the job done?
  • Identify events with no properties — flag for redesign or removal
  • Identify events with inconsistent naming — consolidate before migration
  • For healthcare: identify events with potential PHI in properties — redesign, do not migrate as-is
  • Check the user identity schema: is the distinct_id an internal staff ID or a customer-facing identifier that could constitute PHI?
  • Identify events fired fewer than 10 times in 90 days — candidates for removal
  • Document which events are P0 (activation-critical) vs P1 (adoption) vs P2 (secondary) — migration can proceed priority-first

Step 2 — Historical Data: Three Options

Once you know what to migrate, decide how to handle historical Mixpanel data. Three options, ranked by recommendation depending on your situation:

Option A — PostHog Managed Migration (Recommended for Most)

PostHog provides an automated managed migration from Mixpanel directly in the PostHog interface. No code required.

  1. Go to PostHog → Settings → Data Management → Managed Migrations
  2. Connect your Mixpanel service account credentials (Project Settings → Service Accounts)
  3. PostHog automatically exports, transforms, and imports your event history

PostHog handles the schema transformation automatically — including Mixpanel-specific event names like $mp_web_page_view which become $pageview in PostHog format. Migrated events are tagged with historical_migration: true so you can filter them from live dashboards if needed.

Best for: Teams with fewer than 5M historical events who want the migration complete quickly without writing Python scripts.

Option B — S3/GCS Intermediate Export (Most Reliable for Large Datasets)

For larger event volumes or when Managed Migration encounters rate limits, export from Mixpanel to cloud storage first, then import into PostHog from S3 or GCS.

# Export via Mixpanel's Export API (1 day at a time for large datasets) # Rate limits: 60 queries/hour, 3/second import requests import gzip import json def export_mixpanel_day(from_date, to_date, username, secret, project_id): url = "https://data.mixpanel.com/api/2.0/export" params = { "project_id": project_id, "from_date": from_date, # "YYYY-MM-DD" "to_date": to_date, } response = requests.get(url, params=params, auth=(username, secret)) # Upload response to S3/GCS, then import to PostHog from storage

Best for: Large event volumes (5M+), teams who want full control over the transformation, or when PostHog's managed migration hits rate limits.

Option C — Start Fresh (Recommended When Taxonomy Has Significant Debt)

If the audit revealed that a large proportion of existing events are unusable — wrong names, missing properties, HIPAA-risk events, no analytical value — starting with a clean PostHog implementation is often faster and produces better results than migrating bad data.

Starting fresh means: implement the new JTBD-focused taxonomy directly in PostHog, set a cutover date, and keep Mixpanel accessible for historical lookback only (Mixpanel free plan retains data for up to 5 years for export, even after you stop sending events).

Best for: Teams where the audit revealed that fewer than 40% of existing events would survive the JTBD quality test. Migrating the other 60% is pure noise.

Step 3 — SDK Conversion

The PostHog SDK is architecturally identical to Mixpanel. Most function calls have direct 1-to-1 equivalents. The conversion can be largely automated with a find-and-replace pass, followed by a review for edge cases.

Core Function Mapping

// INITIALISATION mixpanel.init('YOUR_TOKEN') posthog.init('YOUR_TOKEN', { api_host: 'https://us.i.posthog.com' }) // IDENTIFY (user) mixpanel.identify(userId) posthog.identify(userId) // SET USER PROPERTIES mixpanel.people.set({ plan: 'business', role: 'admin' }) posthog.people.set({ plan: 'business', role: 'admin' }) // TRACK EVENT mixpanel.track('form_published', { element_count: 12 }) posthog.capture('form_published', { element_count: 12 }) // GROUP ANALYTICS (PostHog adds this — not available in Mixpanel standard) posthog.group('practice', practiceId, { location_count: 3 }) // RESET (on logout) mixpanel.reset() posthog.reset()

What PostHog Adds That Mixpanel Doesn't Have at Standard Pricing

  • Group analytics: posthog.group('company', companyId, properties) — associates events with an organisation, enabling account-level analysis. No equivalent in Mixpanel standard.
  • Feature flags: posthog.isFeatureEnabled('flag-name') — built-in A/B testing without a separate tool.
  • Session recordings: Automatic session replay included at no additional cost on PostHog Cloud.
  • Data warehouse integration: Native Stripe, Salesforce, and BigQuery connectors for cross-source analytics.

Autocapture

PostHog's autocapture fires events automatically for clicks, form submissions, and page views — without explicit tracking calls. This is useful during the transition period (you get coverage even before the new taxonomy is fully implemented) but should be audited and configured carefully before production deployment.

For HIPAA-compliant healthcare products: autocapture should be disabled or carefully configured to exclude any DOM elements that might capture patient-identifiable content. PostHog provides an exclusion list for autocapture that can be set during initialisation.

// HIPAA: configure autocapture exclusions posthog.init('YOUR_TOKEN', { api_host: 'https://us.i.posthog.com', autocapture: { dom_event_allowlist: ['click'], element_allowlist: ['a', 'button'], css_selector_allowlist: ['.track-this'] } })

Step 4 — HIPAA Compliance Layer (Healthcare SaaS Only)

For healthcare SaaS migrating from Mixpanel to PostHog, the migration is also a compliance remediation opportunity. Events that were sending potential PHI in Mixpanel need to be redesigned before they enter PostHog — not after.

User Identity Schema Redesign

The most common HIPAA risk in product analytics is the user identity schema. If your Mixpanel distinct_id is a customer-facing identifier that could be linked to a patient record — an email address, a patient portal login, or a record ID — this constitutes a potential HIPAA violation.

The correct schema for HIPAA-compliant analytics:

// HIPAA-safe: use internal staff DB ID as distinct_id posthog.identify(internal_staff_user_id, { plan_tier: 'business', role: 'admin', practice_id: practice_uuid, account_age_days: 47 }) // NOT: posthog.identify(patient_email) // PHI — patient-identifiable posthog.identify(patient_record_id) // PHI — links to patient data posthog.identify(user_full_name) // PHI — directly identifiable

Contact Reference Hashing

For events that need to reference a patient or contact without capturing their identity directly, use one-way hashing. The hash allows you to track longitudinal patterns for a contact without storing any identifying information:

// One-way hash for contact reference — server-side only import hashlib contact_hash = hashlib.sha256(contact_id.encode()).hexdigest() posthog.capture('form_sent_to_contact', { contact_hash: contact_hash, // non-reversible reference form_type: 'intake', delivery_method: 'email' })
Related Article

Full HIPAA analytics architecture

The detailed guide to HIPAA-compliant product analytics — safe event taxonomy design, which properties are allowed and which aren't, and the full PostHog configuration for healthcare SaaS.

Read the HIPAA analytics guide →

Step 5 — Cutover and Verification

Run both platforms in parallel for 1–2 weeks before cutting over. This lets you verify that PostHog is receiving events correctly and that properties are being captured — before you remove the Mixpanel SDK.

Verification Steps

  1. Check the Activity feed in PostHog for a test user and verify your P0 events are appearing with all expected properties.
  2. Check that group events are being captured correctly — verify in PostHog's Group Analytics that organisations are being created and associated with events.
  3. Compare event counts between Mixpanel and PostHog for the parallel period. A significant discrepancy indicates missing events or a tracking gap.
  4. For HIPAA: run a property audit — export a sample of events from PostHog and verify that no patient-identifiable information appears in any property value.
  5. Test the QA events — fire each P0 event manually in a development environment and confirm it appears in PostHog with the correct property values before declaring the migration complete.

The most common post-migration finding is missing properties — events firing but without the metadata needed for segmentation. Catching this during the parallel period, before Mixpanel is decommissioned, avoids weeks of collecting unsegmentable data.

Frequently Asked Questions

How long does a Mixpanel to PostHog migration take?

The technical migration — SDK swap and PostHog setup — typically takes 1–3 engineering sprints depending on event volume and taxonomy complexity. The pre-migration audit (deciding what to bring) and any HIPAA compliance remediation are often the longest steps. For a product with 100–200 events and no compliance requirements, total migration time from audit to cutover is typically 4–8 weeks. For a healthcare SaaS product with PHI remediation required, add 2–4 weeks for event redesign and compliance review. The parallel-running period (both platforms live simultaneously for verification) should be at least 1–2 weeks before decommissioning Mixpanel.

Will I lose my historical Mixpanel data?

No — Mixpanel retains data for export even after you stop sending events. The free plan retains data for up to 5 years. You have three options for historical data: PostHog's managed migration tool (no code required, handles schema transformation automatically), an S3/GCS intermediate export for larger datasets, or keeping Mixpanel accessible read-only for historical lookback while running PostHog for all new events going forward. The "start fresh" approach is often the right one when audit reveals significant event debt — historical Mixpanel data can be queried directly if needed without cluttering the PostHog event namespace with legacy events.

Does PostHog support the same reports as Mixpanel?

PostHog supports funnel analysis, retention analysis, user path analysis, cohort analysis, and custom dashboards — the core report types that Mixpanel is known for. The interface is different, and PostHog's query model (HogQL, a SQL dialect) gives more flexibility for custom analysis than Mixpanel's visual query builder. The main practical difference is that PostHog encourages SQL-level analysis via HogQL, which is more powerful but requires more familiarity with data querying. For teams used to Mixpanel's visual interface, the learning curve is 1–2 weeks for standard reports; more for complex retention and cohort analysis. PostHog's documentation is thorough, and their community forum is active.

Is PostHog's data as reliable as Mixpanel's?

PostHog Cloud uses ClickHouse as its underlying data store — the same columnar database used by Cloudflare, Uber, and ByteDance for high-volume analytics. Query performance on large event datasets is excellent. The main reliability consideration is that PostHog's Stripe connector (for Data Warehouse integrations) deduplicates at query time rather than at ingestion — meaning queries against Stripe data require explicit deduplication logic to avoid double-counting. This is a known quirk to document when handing off to analysts. For core product event data, reliability is comparable to Mixpanel at equivalent event volumes.

Should I self-host PostHog or use PostHog Cloud?

PostHog Cloud is the recommended option for most teams. It eliminates infrastructure management overhead (servers, ClickHouse maintenance, backups), includes the HIPAA BAA at standard pricing, and scales automatically with event volume. Self-hosting makes sense only when you have strict data residency requirements (event data must stay within a specific geographic jurisdiction or on your own infrastructure) or when event volumes are high enough that cloud pricing exceeds self-hosting infrastructure costs. PostHog provides open-source deployment documentation for self-hosted instances, but the operational burden of maintaining a ClickHouse cluster is substantial. For most B2B SaaS products at under 10M events/month, PostHog Cloud is the right call.

Sources

Jake McMahon

Jake McMahon

Jake is a product analytics specialist with 8+ years building measurement systems for B2B SaaS. He has run Mixpanel-to-PostHog migrations for healthcare SaaS platforms — including the pre-migration audit, HIPAA compliance remediation, event taxonomy redesign, and developer handoff documentation. He leads analytics and research engagements at ProductQuant, and his work typically begins with an analytics audit before any migration work starts.

See the Analytics Audit →

Analytics Audit

Before you migrate, audit what you have

The Analytics Audit maps your existing instrumentation against the questions your team needs to answer — identifying what to keep, what to redesign, and what to leave behind before the migration begins.

See the Analytics Audit →