How to migrate from Mixpanel to PostHog without losing event history
PostHog's managed migration can pull historical events directly from Mixpanel, but the SDK swap, event and property naming, user identities and dashboards all need deliberate work. A renewal, a pricing change or a data residency requirement usually triggers the move, and the first decision is whether the history matters enough to import at all. The managed migration connects with a Mixpanel service account or project secret and converts events into PostHog's schema, remapping event names and properties. Each direct import job covers at most one year of data, so a long history needs several consecutive jobs, and re-running a job on the same data creates duplicates. Because events are not deduplicated and there is no way to selectively delete imported event data, the import plan should be written down and tested on a small window before the full history runs.
Platform or analytics engineering usually owns the work, with a security or data owner approving the credentials, the data location and the retention settings. Expect the effort to sit mostly in the code, not the import: replacing the Mixpanel SDK in each application, agreeing a naming map for events and super properties, and making sure distinct_id values match across old and new data so that cohorts and funnels still resolve to the same people. Dashboards and alerts are rebuilt by hand. Confirm with PostHog which plan unlocks the import features and whether the historical_migration flag applies to your project before budgeting, since the pricing page and migration docs set those terms.
Self-hosting changes the operating model. PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for product or infrastructure questions on them, so the team running the instance must own upgrades, backups, scaling and incident response, or hire a partner to do so under a written scope. Check the PostHog managed migrations documentation and decide, before the first job runs, whether the target is PostHog Cloud or a self-hosted instance, because that choice changes who carries the operational risk.
Which Mixpanel capabilities map cleanly to PostHog and which need rework
This table compares the main Mixpanel capabilities with their closest PostHog equivalents and marks each as clean, needs rework or gap. Use it to scope the migration, then verify each report and funnel against your own definitions before cutover. The main takeaway is that event data and core analytics move well, while dashboards, saved reports and bespoke configuration usually need to be rebuilt.
| Mixpanel capability | PostHog equivalent | Status and what to check |
|---|---|---|
| Event analytics and event data | Product analytics event capture and querying | Clean for event history imported through the managed migration. Confirm that event and property names map as you expect in a test project first. |
| Reports (insights) | Insights in product analytics | Needs rework. Rebuild each report in PostHog and compare results against Mixpanel for the same date range and timezone. |
| Funnels | Funnel insights | Needs rework. Step definitions, conversion windows and breakdowns must be recreated and validated report by report. |
| Cohorts | Cohorts built from person properties and behavior | Needs rework. Confirm each cohort's logic can be expressed in PostHog before relying on it for targeting. |
| Retention | Retention insights | Needs rework. Check the cohort definition and return event choice, since Mixpanel's 2-year default retention differs from PostHog Cloud's plan-based retention. |
| User profiles and identities | Persons and identified users | Needs rework. Identity merging depends on how distinct IDs were set, so test a sample of users across the imported history. |
| Dashboards and saved reports | Dashboards | Gap unless confirmed. Plan on rebuilding dashboards and saved reports. Ask PostHog whether any saved report can be carried over for your account. |
| Feature flags | Feature flags in PostHog | Needs rework. Flags are a separate product area in PostHog, so review targeting rules and rollout states before switching code paths. |
| Session replay | Session replay in PostHog | Clean as a new capability for most teams, but it is not a Mixpanel import. Recordings start only after the SDK is in place. |
| Experiments and surveys | Experiments and surveys in PostHog | Needs rework. Running experiments must be rebuilt, and in-flight tests should finish in Mixpanel before cutover. |
What data can move from Mixpanel and what must be rebuilt
Some Mixpanel data has a documented export or import path into PostHog, and some does not. Treat historical events as the part that can be moved by tooling, and inventory identities, cohorts, group data and downstream integrations as items to confirm and rebuild in your own environment.
Historical events through managed migration
PostHog's managed migration connects directly to Mixpanel with a service account or project secret and converts Mixpanel events into PostHog's schema, remapping event names and properties. Each direct import job covers at most one year of data, so a longer history needs several consecutive jobs. Re-running a job on the same data creates duplicates, and events are not deduplicated, so plan each date range once and record which ranges are done.
Raw Event Export as a fallback
If the managed connector cannot cover a dataset, the Raw Event Export API from Mixpanel is a separate path to extract events as files. Confirm with your Mixpanel project admin that the service account has the export permission, that your data residency region is correct, and how rate limits affect a full-history pull. Loading those files into PostHog is a separate step that you must test on a small date range first.
Identities and user profiles
Mixpanel's distinct_id values and identity merges determine which events belong to the same person in PostHog. Export a sample of users with multiple identifiers and confirm that the merged history lands on one person record. Profile properties set through people updates are not guaranteed to appear in event history, so check which profile fields you need and set them again through PostHog's identify calls where they are missing.
Cohorts and saved reports
Cohorts, saved insights, dashboards and funnels are definitions, not event data, and they do not move with the events. Export each definition from Mixpanel, record its filters and time windows, and recreate it in PostHog as a cohort or insight. Compare results for one known period before retiring the Mixpanel version, because definitions that rely on Mixpanel-specific behavior may not match exactly.
Group analytics data
Group-level properties, such as company or account records used for B2B reporting, depend on how your Mixpanel project assigned group keys. Inventory which groups are in use, map each group type to a PostHog group, and confirm with PostHog's documentation how group properties are imported or set. Do not assume group membership carries over from event history without testing it.
Warehouse syncs, reverse ETL and alerts
Downstream jobs that read Mixpanel data, such as warehouse syncs, reverse ETL flows into CRM or marketing tools, and alert rules, do not migrate with the project. List every destination and owner, then rebuild each one against PostHog's exports or your own pipeline. Run both systems in parallel until each output matches, and confirm that no team still depends on a Mixpanel feed you have not listed.
The migration sequence from inventory to decommission
This sequence moves Mixpanel event analytics to PostHog in controlled stages, so each step produces a written artifact that the next step depends on. Mixpanel stays live until the parallel run reconciles and the export retention question is settled.
Inventory events, properties and dashboards
Your analytics or product owner and a data engineer list every event, event property, user and group property, cohort, funnel, retention report and dashboard in the Mixpanel project, and record which ones teams use and which feed reports to executives or other systems. Note any SDK calls made outside the standard tracking layer and any downstream consumers of Mixpanel data. The output is an event dictionary with owners, usage status and a dependency list. The step is done when the owners confirm the dictionary matches what the product actually sends.
Build the mapping file in a pilot project
Create a PostHog pilot project and map each Mixpanel event name and property to its PostHog equivalent, deciding where names change, where properties are renamed or type-cast, and which identities need to be preserved. Run the managed migration with a Mixpanel service account or project secret against a single short date range to test the conversion. The outputs are a versioned mapping file and a pilot report that lists unmapped or dropped fields. The step is done when analysts confirm that the pilot's converted events read correctly in PostHog.
Import history in consecutive one-year jobs
The platform engineer runs the historical import one job at a time, because each direct import job covers at most one year of data and longer histories need several consecutive jobs. Set the historical_migration flag on each job so ingestion fees do not apply, and confirm that a paid product analytics plan is in place before starting, since the import features require it. Re-running a job on the same data creates duplicates and events are not deduplicated, so keep a log of each job's date range and do not repeat a range. The output is a job log and a deduplication check that compares event counts per day and per event name between Mixpanel and PostHog. The step is done when the counts reconcile within the tolerance the data owner has agreed in writing.
Run a parallel period with both SDKs
Ship the PostHog SDK alongside the Mixpanel SDK in the same releases, so both receive live events while the team compares dashboards and funnels side by side. Your engineers keep the two tracking calls in one shared wrapper so any gap is visible in code review. Analysts check that key metrics, such as active users and conversion funnels, agree within the threshold you set during planning. The output is a reconciliation report covering each tracked metric, the variance found and the fix applied. The step is done when the open discrepancies are either closed or accepted by the business owners.
Cut over SDKs and dashboards
Remove the Mixpanel SDK calls from the application, switch dashboards, alerts and any scheduled reports to PostHog, and update access for analysts and product managers. Confirm that the identity mapping preserves user and group identities across the cutover, so returning users are not counted as new. Update privacy notices and consent configuration for the new collector wherever it runs. The output is a signed-off cutover checklist listing each SDK change, dashboard, alert, user group and consent setting with the person who verified it. The step is done when the checklist is signed by the data owner and the security lead.
Decommission Mixpanel after export retention is settled
Before turning off Mixpanel, the data owner confirms in writing what must be kept from the Mixpanel project, including a full raw export produced with the Raw Event Export API where records are required for audit or legal reasons. Revoke the service account or project secret used for the migration and remove any remaining Mixpanel credentials from the codebase and secret stores. Ask Mixpanel to confirm its retention and deletion behavior for the project in writing before you rely on it. The output is a decommission record that lists the retained exports, their storage location, the revoked credentials and the deletion confirmation. The step is done when that record is approved and filed with the migration documentation.
How PostHog's managed import handles history and duplicates
Plan the import around one hard rule: each PostHog direct import job from Mixpanel covers at most one year of data, so a longer history needs several consecutive jobs with non-overlapping date boundaries. Write the boundaries down before the first run, one row per job, with the start and end date, the Mixpanel project and the PostHog project it lands in. Re-running a migration over data that already arrived creates duplicates, and PostHog does not deduplicate events. Treat every job as one-shot: if a job fails partway, confirm the exact window it covered before you restart it, and never run an overlapping window to fill a gap by guesswork.
Run a test window before the full history. Pick a short, recent period with known event volumes, import it into a non-production PostHog project if you have one, and compare event counts by name and day against Mixpanel for the same window. Confirm that the historical_migration flag is set on the import so the historical events are free of ingestion fees, and confirm with PostHog that your plan unlocks the import features, since a paid product analytics plan is required for them. Check the timezone and identity results in the test as well, because these are harder to correct later.
Assume that imported events cannot be selectively deleted. PostHog documents no way to remove a subset of imported event data, so a bad mapping or a duplicate window usually means living with the data or recreating the project. Agree on the mapping and the boundaries with the analytics owner, record the decision in your migration runbook, and keep the Mixpanel export intact until your reconciliation is signed off.
What drives migration cost and duration
History length is usually the first driver of duration. PostHog's direct Mixpanel import covers at most one year of data per job, so a longer history means several consecutive jobs run in sequence. Each job needs its own date range, and re-running a job over data already imported creates duplicates, because events are not deduplicated. Planning therefore depends on knowing exactly which date ranges have already been loaded.
- Job count: A five-year history needs at least five one-year jobs, plus any reruns after a failed or partial job.
- Duplicate control: Keep a written log of each date range, job identifier and result so no window is imported twice.
- Ingestion fees: Historical imports are free of ingestion fees only when sent with the
historical_migrationflag, so confirm that flag is set on every job. - Irreversibility: There is no way to selectively delete imported event data, so test with a narrow window before running the full history.
- Plan requirement: A paid product analytics plan is needed to unlock the import features.
Before requesting a quote, confirm the earliest event date in each Mixpanel project and the expected number of jobs, and ask the implementer to show how they will track job completion.
The number of distinct event names and properties drives mapping effort more than raw event volume. Each Mixpanel event name and property has to be mapped to a PostHog event or property, and every mapping decision affects dashboards, insights and cohorts built on top of it. Teams with many legacy or inconsistent names spend the most time on this step, and it is labor that is paid once but must be reviewed carefully.
- Name inventory: Export the list of event names and property keys from Mixpanel and count them, including deprecated events still receiving data.
- Naming cleanup: Decide which inconsistent names, such as differing capitalization or duplicated events, should be merged before import rather than carried across.
- Property types: Check that numeric, boolean and date properties keep their types after conversion, since reports depend on them.
- Reserved and high-cardinality properties: Identify properties with very many unique values, which can inflate storage and slow queries.
- Mapping review: Ask for a written mapping table that the client signs off before any job runs.
Ask the implementer to state whether naming cleanup and mapping review are in the fixed scope or charged separately, and to list which events will be renamed in PostHog.
The code that sends events and the analytics content built on them are separate workloads. Replacing the Mixpanel SDK means touching every application that tracks events, across web, mobile and backend services, and each platform has its own release and testing cycle. Dashboards, saved insights and cohorts must be rebuilt or validated against the migrated data, so their count sets the verification effort.
- SDK footprint: Count each platform (web, iOS, Android, server) and each repository or release pipeline that contains a Mixpanel call.
- Identity calls: Check how
identifyand alias calls are used, since they affect preserved identities and must be reproduced in the PostHog SDK. - Dashboards and insights: Inventory saved dashboards and reports, then mark which ones stakeholders still use.
- Cohorts and funnels: Rebuild cohorts and funnels that depend on Mixpanel-specific definitions, and compare results against the source.
- Parallel running: Decide how long both tools will run side by side, since that period doubles some tracking effort.
Ask for the SDK replacement, dashboard rebuild and verification to be listed as separate line items, each with a stated deliverable.
Two decisions change the cost structure more than any single data property. The identity model determines how users are matched before and after migration, and the hosting choice decides who pays for infrastructure and operations. PostHog Cloud is offered in US (Virginia) and EU (Frankfurt) regions and is billed by usage, while a self-hosted PostHog deployment moves infrastructure, upgrades, backups and monitoring to your team or your implementer. PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for them, so this support gap must be covered by a contract or internal staff.
- Identity mapping: Confirm how Mixpanel distinct IDs map to PostHog person identifiers, and whether anonymous history will be linked.
- Hosting region: Choose between PostHog Cloud regions and a self-hosted deployment based on residency rules, not on price alone.
- Self-hosted sizing: PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment, and the README says open-source deployments should scale to approximately 100k events per month before moving to Cloud.
- Kubernetes: New Kubernetes deployments of the paid self-hosted product are no longer supported, which narrows the platform options.
- Licensing: Premium features in the ee directory require a PostHog license on self-hosted instances.
Ask for the identity mapping approach, the hosting region, and a written statement of who runs upgrades, backups and incident response.
The total cost has three components: PostHog plan fees, self-hosting infrastructure and operations, and implementation labor. Labor for mapping, job execution, SDK replacement and verification is largely one-time, although ongoing support and upgrades recur. Plan fees and infrastructure recur for as long as you run the platform. Only the PostHog Free plan's first 1 million analytics events per month and the plan retention limits are stated in the pricing facts, so any other plan figure should come from PostHog's current pricing page at the time of the quote.
- One-time: Mapping, historical job execution, SDK changes, dashboard rebuilds and cutover testing.
- Recurring, cloud: Usage-based plan charges, add-on platform packages such as SSO or audit logs, and retention settings that change storage.
- Recurring, self-hosted: Compute, storage, backups, monitoring, upgrades and any support contract, since PostHog does not provide self-hosted support.
- Cost drivers: Event volume, retention length, number of projects and hosting region all push costs up or down.
- Quote request: Ask for line items separated into one-time labor, recurring infrastructure, recurring support, and any license fee for ee features.
Compare any quote against the plan's written scope and the event volume you measured in your own Mixpanel project, not against an estimate.
What usually goes wrong in a Mixpanel to PostHog move
Most failed Mixpanel to PostHog moves do not fail on the import itself. They fail on duplicates, identity mismatches, reconciliation gaps, missing dashboards and an unowned self-hosted stack. Each risk below has a check to run before cutover.
Duplicate events from re-runs
PostHog's managed migration does not deduplicate events, and re-running a job on the same data creates duplicates. A failed or partially completed job is the usual trigger, so a retry can double counts in funnels and totals. Before each run, record which date window each job covered, and only rerun a window after confirming it was not ingested. Reconcile daily event counts for a sample window against Mixpanel before you move to the next year.
Identity splits that break funnels
Historical events imported from Mixpanel carry distinct IDs that may not match the identities your new PostHog SDK sends after cutover. When the same user appears under two IDs, funnels and retention show drop-offs that never happened. Map Mixpanel distinct IDs and aliases to PostHog person identities before migration, and test a known user across the boundary. Confirm how identity merges are handled for your implementation before relying on cohorts that span the cutover date.
Timezone and date-range mismatches
Mixpanel reports and PostHog queries can apply different project timezones, so the same day can hold different event totals in each tool. Date boundaries at the edges of each one-year import job are the most exposed. Set the timezone in both systems to the same value before reconciling, and compare totals per day rather than per month. Document the boundary behavior your team agreed on so that finance and product read the same numbers.
Dashboards missing after cutover
Imported events do not bring Mixpanel boards, saved reports, cohorts or alerts with them. Teams often discover a missing executive or revenue dashboard only after the old tool is switched off. Build an inventory of every Mixpanel board, report, alert and scheduled export before migration, record its owner and consumers, and assign a rebuilt PostHog equivalent. Keep Mixpanel read access until each item is signed off.
Self-hosting without an operating owner
PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for product or infrastructure questions on self-hosted instances. Open-source deployments are also expected to scale to approximately 100k events per month, with PostHog recommending migration to PostHog Cloud above that, and new Kubernetes deployments of its paid self-hosted product are no longer supported. Name an owner for upgrades, backups, capacity and on-call before choosing self-hosting, and confirm the expected monthly event volume against that ceiling.
How the move differs by starting point
A small product team on Mixpanel's free tier usually has a limited event history, a handful of dashboards and few people who depend on them. The move is mostly about rebuilding a short list of reports and instrumenting the SDK in PostHog, so the historical import is often the smallest part of the work. Because PostHog's free and paid plans differ on projects and retention, check which plan will hold the data before you commit to a cutover date.
- Import scope: Confirm how much history is worth carrying over. A direct import job covers at most one year of data, so a short history may fit in one job.
- Plan requirement: Historical imports require a paid PostHog product analytics plan, even though ingestion fees are waived for imports sent with the historical_migration flag. Ask PostHog to confirm current terms.
- Rebuild over copy: Recreating five or six key funnels and retention charts is often faster than mapping every legacy report.
- SDK swap: Replacing the Mixpanel SDK is usually a small change in a single-page app, but test identity calls on login and logout.
- Hosting choice: Self-hosting PostHog adds server operations for a team with no platform staff, and PostHog states that self-hosted deployments are officially unsupported.
Before starting, confirm which Mixpanel reports your team opens each week and whether anyone outside product needs access to them.
A mid-size team with high event volume, many saved dashboards and cohorts, and several analysts usually needs a staged migration. Mixpanel history will span more than one year in most cases, so the import runs as a series of consecutive jobs, each covering at most one year. Running the same job twice on the same data creates duplicates, and event deduplication is not performed, so the import needs a tracked job plan and a rule for who may start each run.
- Job sequencing: Plan one job per year, oldest first, and record the date range and status of each job in a shared tracker.
- Duplicate control: Freeze re-runs. Events are not deduplicated, so a repeated job cannot be undone selectively because PostHog does not offer selective deletion of imported events.
- Event and property mapping: Build a naming map before the first job, since the import remaps event names and properties into PostHog's schema.
- Parallel running: Keep Mixpanel and PostHog receiving the same events for a validation period so analysts can compare key metrics.
- Dashboard inventory: Export the list of Mixpanel boards and cohorts, then assign each one to a rebuild owner.
Confirm with PostHog how the import handles identities for users who merged accounts in Mixpanel before you start the first job.
Teams whose residency requirement points to the European Union choose between PostHog Cloud in the EU (Frankfurt) region and a self-hosted PostHog deployment in their own infrastructure. PostHog's pricing page lists two Cloud hosting regions, US (Virginia) and EU (Frankfurt), so a Cloud deployment must use the EU region to keep data in the EU. Whichever path you take, the import source, the Mixpanel regional endpoint and the destination region must all be agreed before the first job.
- Region selection: Choose the Frankfurt region at project creation and confirm it applies to the historical import as well as live events.
- Source endpoint: Confirm which Mixpanel data region holds your data, since Mixpanel regional endpoints for EU residency are covered in the export guide.
- Self-host effort: Self-hosting moves hosting, backups, upgrades and security patching to your team, and PostHog's Kubernetes support for new paid self-hosted deployments is no longer available.
- Transfer documentation: For Cloud, record the transfer basis you rely on for any non-EU support access, and confirm it with your counsel.
- Consent scope: Event tracking that identifies users still needs a consent decision under your local rules.
Ask PostHog in writing where support staff access data from, and get your legal team's sign-off before choosing.
Regulated organizations that must control where analytics data is stored, who operates the platform and how changes are recorded usually start with self-hosting. The migration then covers much more than the import: infrastructure design, access control, logging, backup and restore, and change management all need evidence that an assessor can review. DeployOpen can plan, implement and document a self-hosted PostHog deployment inside your own infrastructure, but compliance assessments are performed by independent auditors and certification bodies, not by DeployOpen.
- Licensing check: PostHog is MIT licensed except for the ee directory, which needs a PostHog license for premium features on a self-hosted instance. Decide whether the posthog-foss repository meets your feature needs.
- Operating model: Assign owners for upgrades, backup restores and incident response, since vendor support is not available for self-hosted instances.
- Scale boundary: The README suggests open-source deployments are intended for roughly 100k events per month, with Cloud recommended above that. Plan your capacity against your own event volume.
- Hardware baseline: PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for the hobby deployment, and production sizing must be validated.
- Evidence trail: Keep import job logs, mapping documents and access records as audit evidence.
Confirm your data classification, retention targets and assessor expectations before you approve the import plan.
Questions buyers ask before moving from Mixpanel to PostHog
How long does a Mixpanel to PostHog migration take?
The duration depends mostly on how much history you need and how many event names and properties must be mapped. PostHog's direct import covers at most one year of data per job, so a longer Mixpanel history needs several consecutive jobs run one after another. Each job also has to be checked before the next one starts. Mapping work grows with the number of events, properties and identity rules you carry over, and a test run on a small date range is the best way to size the rest. Ask your team to confirm the time for these steps in your own environment, since no supplied figure applies to every account.
What does a Mixpanel to PostHog migration cost, and what recurs?
The cost has several parts. PostHog's pricing page says the first 1 million analytics events are free every month on Cloud, and that the Pay-as-you-go plan raises project count and retention. PostHog's migration documentation says historical imports carry no ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. Self-hosting adds infrastructure, which PostHog's self-host documentation sizes at a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage as a starting point. Recurring costs include hosting, storage, upgrades and staff time. One-time costs include mapping, testing and cutover. Ask any provider to split the quote into these parts.
Can our team migrate from Mixpanel to PostHog without outside help?
A team with engineers who know both platforms can often run the migration alone, but the work is more than copying data. The job includes choosing a hosting model, running the managed import in one-year blocks, mapping event and property names, keeping user identities consistent, and replacing the Mixpanel SDK in each product. PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances, so in-house skills or a implementation partner must cover operations. DeployOpen plans and implements self-hosted platforms in your own infrastructure under a written, fixed scope, and ongoing support is available as a retainer.
Does PostHog's managed import keep all of our Mixpanel history?
It keeps the history you import, but it does so in pieces and without cleanup. Each direct import job covers at most one year of data, so longer histories need several jobs, and PostHog's documentation says events are not deduplicated. Re-running a migration on the same data creates duplicates, so each date range should be run once and checked. PostHog also states there is no way to selectively delete event data once imported. Confirm the exact date range of each job, the event counts on both sides and the identity mapping before you retire Mixpanel.
What happens to our Mixpanel data after we export it?
Exporting does not delete data from Mixpanel. Mixpanel remains the system of record until you decide otherwise, and the export gives you a copy you control. Keep the exported files, such as JSONL output from the Raw Event Export API, in storage with access controls and a retention rule that matches your policy. Check your contract with Mixpanel for its own retention and deletion terms, and confirm with your legal or privacy team how exported personal data should be handled. Deletion of a Mixpanel project is a separate decision that should follow a verified migration.
Does self-hosted PostHog come with vendor support?
No. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. Support for a self-hosted PostHog therefore comes from your own engineers, from a partner you contract for the work, or from the community. Ask any partner to state in writing what is covered, how incidents are handled, how upgrades are planned and which PostHog components they will operate. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, scoped in writing.
Which PostHog license terms apply if we self-host?
PostHog's repository is under the MIT Expat license, except for content in the ee directory, which has a separate license. The PostHog README states that using premium features from the ee directory on a self-hosted instance requires a PostHog license. Teams that need fully free software can look at the posthog-foss repository, which the README describes as purged of all proprietary code and features. Have your legal team confirm which features you plan to use and which license covers each, because the choice affects what you can run without a paid agreement.
When should we move to PostHog Cloud instead of self-hosting?
The answer depends on event volume, operating capacity and data location requirements. The PostHog README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that. PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions, which can address some residency needs. Compare your monthly event volume, your retention needs and the staff you can dedicate to operations before deciding. Confirm each of these with PostHog and your own data team, since they change over time.
How DeployOpen scopes and runs a Mixpanel to PostHog migration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and that includes the PostHog side of a move away from Mixpanel. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory Mixpanel projects, event names, properties, identities and retention needs before choosing a PostHog deployment model
- Confirm whether PostHog Cloud or a self-hosted instance fits the data residency and support requirements
- Agree in writing which Mixpanel history is imported, the number of one-year import jobs and the cutover plan
How we build
- Set up the PostHog environment and configure the service account or project secret used for the managed migration
- Map Mixpanel event and property names to the PostHog schema and document every rename before import runs
- Replace the Mixpanel SDK calls in the client's applications and test identity handling against a staging environment
How we hand over
- Deliver the event mapping, identity rules, job log and reconciliation results as written documentation
- Walk the client's analytics and engineering teams through dashboards, cohorts and funnels rebuilt in PostHog
- Record the duplicate-prevention steps so that no migration job is re-run against data already imported
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Support scope for the self-hosted PostHog instance is agreed in the written statement of work
- Confirm with PostHog which support options apply to your plan, since self-hosted deployments are not supported by PostHog directly
