The method, regardless of source platform
- Event and property mapping. Every event and property in the source platform gets a deliberate mapping decision in PostHog - not a blanket recreate. This is also where we apply the autocapture vs. explicit events framework, since a migration is the natural point to fix a taxonomy that drifted on the old platform.
- Parallel run. Both platforms track in production simultaneously for a defined window, so numbers can be reconciled before anyone trusts PostHog as the source of truth.
- Verification. Key funnels, retention curves, and dashboards get compared side by side. Discrepancies get root-caused - usually a mapping gap, not a PostHog limitation - before cutover.
- Cutover with a rollback path. The old platform stays reachable until the team is confident, not switched off on migration day.
Migration guides by source platform
| From | Guide | Notes |
|---|---|---|
| Amplitude | Amplitude to PostHog migration guide | Dedicated guide - we also run an Amplitude practice, so this direction is worked from both sides |
| Mixpanel | Mixpanel to PostHog migration guide | Dedicated guide - narrower analytics-only scope usually simplifies mapping |
| Google Analytics / GA4 | Scoped per engagement | Often a partial migration - see PostHog vs Google Analytics for how the split usually works |
| Heap | Scoped per engagement | Heap's autocapture-heavy model needs a deliberate re-architecture, not a straight event copy |
Why the migration guides exist even without search volume behind every direction
Search-volume research for this site found essentially no measured search demand for literal phrases like "amplitude to posthog migration" - a finding we label plainly rather than pretend otherwise. We build these guides anyway because the underlying questions get asked constantly in engineering conversations and to AI assistants, even when they don't show up as Google search volume yet. The method above is what we actually run regardless of how someone found this page.