What makes this migration direction specific
Amplitude implementations that have been running for a while tend to accumulate genuinely sophisticated cohort definitions and behavioral segments. The migration risk isn't moving events - it's losing the analytical logic behind those cohorts if they get recreated carelessly in PostHog rather than mapped deliberately.
The mapping work, specifically
| Amplitude concept | PostHog equivalent | What needs deliberate mapping |
|---|---|---|
| Events & event properties | Events & event properties | Naming convention often differs; this is the point to fix drift, not just copy it |
| User properties | Person properties | Identity resolution logic (how a user is identified across sessions/devices) needs re-verification |
| Behavioral cohorts | Cohorts / saved insights | Cohort logic must be recreated explicitly - this is the highest-effort mapping step |
| Dashboards | Dashboards / insights | Rebuilt against the new event schema, verified against Amplitude's numbers during parallel run |
The sequence we run
- Inventory every Amplitude event, property, cohort, and dashboard actually in active use - not everything that was ever created.
- Map each to a PostHog equivalent, applying the autocapture vs. explicit events framework to clean up anything that drifted.
- Run both platforms in parallel, reconciling key funnels and retention curves before anyone treats PostHog as authoritative.
- Cut over with Amplitude left reachable read-only for historical reference, not switched off.
Where self-hosting fits into this decision
A migration off Amplitude is also a natural point to evaluate self-hosted PostHog, since you're already re-architecting the analytics layer - worth scoping alongside the migration itself rather than as a separate later decision.