Mixpanel to PostHog Migration: A Practical Framework for Engineering Teams

Why Most Mixpanel-to-PostHog Migrations Cost More Than They Should

The financial case for moving from Mixpanel to PostHog is real. Based on public pricing pages accessed March 2026, Mixpanel at 10M events per month costs approximately $2,520/month. PostHog at 5M events costs approximately $250/month. At enterprise tiers, Mixpanel contracts are estimated at $25K–$100K+ per year. The gap is structural, not marginal.

Teams discover PostHog through a pricing comparison, a Reddit thread, or a conference talk. Then they open the migration docs, see a managed import tool, and assume the switch is a weekend project.

That assumption is wrong. The managed import tool moves your historical events from Point A to Point B. It does not deduplicate them, map your property schema, rebuild your dashboards, validate your identity resolution, configure your session replay privacy controls, or train your analysts on a new query language.

The gap between starting a migration and finishing one is measured in weeks of unplanned work, not hours.

This framework covers the full scope so you can budget accurately and avoid the silent failures that surface after you have cancelled Mixpanel.

The structural case for migration is strongest in three situations: when the team is paying for analytics, session replay, and feature flags as separate tools that PostHog consolidates; when Mixpanel's MTU (monthly tracked user) billing is creating cost pressure as the user base grows; and when the team is mid-size or larger with enough event volume that the pricing differential compounds into meaningful recurring savings.

The structural case weakens when Mixpanel is the primary stakeholder-facing reporting tool and the team lacks bandwidth to rebuild every dashboard, or when the product is on Mixpanel's free tier and the one-time migration cost exceeds the near-term saving.

The Three Migration Paths: When Each One Actually Works

PostHog's migration documentation identifies three primary approaches to moving historical event data from Mixpanel. The right choice is not the one with the most features — it is the one that matches your data volume, your historical window, and your engineering capacity.

Managed API Migration

PostHog's built-in migration tool connects to Mixpanel's API and pulls events directly into PostHog. This is the lowest-friction starting point for teams with moderate event volume and less than 12 months of critical history.

The limitation is hard-coded into the tool. The managed migration is limited to a 1-year date range per job. If your Mixpanel history extends beyond 12 months, you need to run separate jobs for each window. At scale, that becomes unwieldy.

If your team has 18 months of history and runs two jobs to cover it, you are managing two jobs. If one times out and restarts, you now have duplicates across both jobs and a recovery problem that requires manual date-range forensics.

The insight: The managed API tool is the right path for teams that have already pruned old data or are comfortable migrating only the past 12 months of history.

S3 Import

Export Mixpanel data to an S3 bucket, then import via PostHog's S3 ingestion pipeline. This approach handles large datasets, multi-year history, and scenarios where API rate limits become a constraint.

The tradeoff is setup overhead. S3 buckets require access credentials, IAM policies, bucket configuration, and an import job that points PostHog at the right prefix. For teams with an existing S3 setup and someone who knows how to configure it, this is more reliable than the API approach for anything beyond 12 months of history.

For datasets exceeding 12 months of Mixpanel history, the S3 path is more practical because it avoids running multiple sequential API jobs with overlapping date ranges.

The insight: S3 import trades a faster start for more reliable completion on large datasets. The setup cost is front-loaded but pays off when the alternative is managing five sequential API jobs.

Stablecog CLI

An open-source CLI tool (community-maintained) automates the Mixpanel export and PostHog import workflow. It is the most flexible option for teams comfortable with command-line tooling who want custom control over batching, retries, and date windowing.

The critical caveat is support. It is community-maintained. Before relying on it for a production migration, verify the repository is actively maintained, check the last commit date, and confirm the tool handles the specific event schema your team uses. Community tools with outdated dependencies can silently drop events or fail on schema mismatches.

The insight: The Stablecog CLI is useful for teams with specific automation requirements and engineering capacity to evaluate and maintain the tool. For teams that want a supported path, it is not the right choice.

The Duplicate Problem That Every Migration Path Shares

None of the three migration paths deduplicates events. If any job pauses mid-run due to a timeout, API rate limit, or network interruption and restarts, the reprocessed events appear as duplicates in PostHog. PostHog's event ingestion does not enforce uniqueness by default.

This is the most common data quality issue in Mixpanel-to-PostHog migrations. It is not a bug — it is a structural property of how incremental ingestion works. Before starting any migration job, document the exact date ranges covered so that if a restart is needed, you can identify and remove duplicates after the fact.

The insight: Deduplication is not handled by the migration tools. It is a post-migration data cleaning task that you must plan for explicitly before you start.

What the Migration Timeline Actually Looks Like

The estimates below assume a mid-sized B2B SaaS product with 12–24 months of Mixpanel history, 5–20 core dashboards, and one engineer with data access handling the migration alongside other work. Larger or more complex stacks extend every phase proportionally.

Week 1: Pre-Migration Audit and PostHog Setup

Audit and document the Mixpanel event taxonomy. Every event name, property, and saved report that is actively used — not the ones created for a quarterly report two years ago. Export the full event list before touching anything in PostHog.

Set up the PostHog project, configure the SDK in a staging environment, and begin parallel tracking — sending events to both Mixpanel and PostHog simultaneously. Parallel tracking is the only reliable way to validate that PostHog is receiving correct data before Mixpanel is decommissioned.

The insight: The audit done before the migration starts prevents the mid-rebuild discovery that nobody documented what the Mixpanel dashboards actually showed.

Week 2: Historical Data Migration and Event Remapping

Run the historical migration via the managed API tool or S3 import. Apply event remapping for Mixpanel-specific property names that do not exist in PostHog's schema. Common remaps include:

Monitor for duplicates if any jobs fail and restart. Verify event counts against Mixpanel totals for the same date ranges before moving to Week 3.

Week 3: Dashboard Rebuilds and Identity Verification

Begin rebuilding core dashboards, funnels, and cohorts in PostHog. There is no migration path for any of these artefacts — every saved report must be recreated from scratch.

Validate that user identity is resolving correctly across anonymous and identified states. B2B teams should configure group analytics (account-level analysis) at this stage, not after go-live. PostHog's group analytics require upfront configuration that Mixpanel handles differently, and retrofitting it later means rebuilding the cohorts that depend on it.

The insight: Identity resolution breaks silently. The first event a historically anonymous user triggers after migration will appear as a new user unless you explicitly merge identities using PostHog's person merging API.

Weeks 4–8: Team Training, Go-Live, and Decommission

Train the team on PostHog's interface, query patterns (HogQL for custom analysis), and dashboard workflows. Run PostHog as the primary tool while keeping Mixpanel available for reference queries during the overlap period.

Decommission Mixpanel once the team is operating confidently from PostHog data and no outstanding queries require Mixpanel access. Do not cancel Mixpanel on day one of PostHog go-live. The overlap period pays for itself in data confidence.

The insight: The migration timeline compresses on the technical side, not the human side. Dashboard rebuilds and team adoption take as long as they take — budgeting only for data transfer is where teams consistently run over.

What Actually Breaks During Migration

Most migration guides cover the data transfer mechanics. The issues below cause the most rework and are consistently undercounted in planning. Address each one before you start, not after you discover them.

1. Duplicate Events from Paused Migration Jobs

PostHog's migration tool does not deduplicate. If a job pauses due to a timeout or API rate limit and restarts, the reprocessed events appear as duplicates. Before starting any migration job, document the exact date ranges covered so that if a restart is needed, you can identify and remove duplicates afterward.

The insight: Deduplication is a post-migration data cleaning task, not a migration tool feature. Plan for it before the first job runs.

2. Saved Reports and Dashboards Do Not Migrate

There is no migration path for Mixpanel dashboards, saved funnels, cohorts, or reports. Every artefact must be rebuilt in PostHog manually. Teams that do not audit their active reports before starting migration frequently discover mid-rebuild that they lack a clear record of what existed. Conduct the audit before the migration starts, not after it.

The insight: The Mixpanel dashboard audit is not a preparatory step. It is the first deliverable of the migration project.

3. Identity Resolution Breaks for Existing Users

Mixpanel's identity model and PostHog's identity model handle anonymous-to-identified resolution differently. When historical events are imported as historical facts rather than live events, the anonymous-to-identified stitching that would normally occur at ingestion time does not happen automatically.

The practical consequence: a user who was anonymous in Mixpanel for 6 months before signing up will appear as two separate users in PostHog after migration unless you explicitly handle the person merge via PostHog's person merging API. This breaks cohort composition, funnels, and retention calculations that depend on continuous user identity.

The insight: Identity resolution gaps are invisible in aggregate reporting but surface immediately in cohort and retention analysis. Validate user identity continuity on your top 50 accounts before decommissioning Mixpanel.

4. Property Schema Mismatches After S3 Import

S3 imports preserve the raw property names from Mixpanel. Properties like $city, $region, and Mixpanel-reserved names do not automatically map to PostHog's equivalent property names. PostHog's geoip enrichment applies to incoming events, not to imported historical data.

If dashboards or cohorts reference these properties, they will return empty results after import until the property names are remapped.

The insight: S3 import preserves the data but not the schema behaviour. Property name remapping is a post-import transformation step that must be scoped before the migration job runs.

5. Query Syntax Is Not Directly Portable

PostHog's custom analysis uses HogQL — a SQL-dialect query language — which superficially resembles Mixpanel's JQL (JavaScript Query Language) but is not compatible. Direct translation of saved Mixpanel queries to PostHog will fail. Every custom query, especially those embedded in dashboards, needs to be rewritten.

The insight: Query migration is not a find-and-replace operation. Budget analyst time for each custom query in the audit, not as an afterthought.

HIPAA Considerations for Healthcare Teams

If your product handles protected health information (PHI), the migration has a compliance layer on top of the technical work. This is not optional and it is not a post-migration cleanup task.

Business Associate Agreement (BAA)

A BAA must be signed with PostHog before any PHI is transferred to their infrastructure. PostHog offers HIPAA-compliant infrastructure through their Enterprise tier with a signed BAA. This process takes time — it is not a checkbox you complete on migration day. Initiate it early in Week 1.

The insight: Initiating the BAA process in Week 1 of a migration project is standard practice for healthcare teams. Starting it in Week 3 creates a hard dependency on the technical migration timeline.

Session Replay Privacy Configuration

PostHog's session replay feature captures DOM mutations, form inputs, and user interactions. When PHI is present in the DOM — patient names in form fields, medical record numbers in URLs, diagnosis data rendered in the interface — it can end up in session recordings without explicit configuration.

PostHog's session replay privacy controls offer three levels: mask all text, mask all inputs, or use a allowlist. By default, it masks passwords and credit card fields automatically. For healthcare forms, you need to configure custom CSS selectors or use the programmatic masking API to redact specific form fields before they reach PostHog's ingestion pipeline.

The insight: Session replay privacy configuration is not complete until you have tested it against your actual patient-facing forms with production data. Default masking covers standard password fields, not the custom form fields that contain PHI.

Review PostHog's HIPAA compliance documentation and session replay privacy controls documentation before enabling session replay in any healthcare context.