Amplitude → PostHog
Move Amplitude events, identities, properties, conversions, cohorts, consent, collection, and historical evidence into PostHog with a schema map, identity aliases, and a labeled historical import.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Amplitude
- Strong behavioral analysis, funnels, cohorts, and product experimentation workflows
- Product-focused reporting helps teams understand behavior beyond page views
- Instrumentation breadth and pricing can be excessive for simple analytics needs
- Event schemas and historical cohorts are expensive to redesign or move
PostHog
- Open product analytics, session replay, feature flags, and experiments consolidate product tooling
- Product-focused reporting helps teams understand behavior beyond page views
- Event volume, deployment choice, and broad feature scope add operational complexity
- Event schemas and historical cohorts are expensive to redesign or move
PostHog: Open product analytics, session replay, feature flags, and experiments consolidate product tooling. This removes a major source-side concern: Instrumentation breadth and pricing can be excessive for simple analytics needs.
What you lose: Strong behavioral analysis, funnels, cohorts, and product experimentation workflows. What you inherit: Event volume, deployment choice, and broad feature scope add operational complexity.
Jump to a section
Know the shape of the move.
This timeline assumes
- Up to 50 properties, 500 events, and five years of retained reports
- A signed measurement plan defines the metrics and conversions that must remain comparable.
- Both collectors can run in parallel for at least one representative business cycle.
- Imported history is labeled separately from destination-native collection.
- The migration team records evidence for every blocking verification check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Raw events and Amplitude export archives | partial | critical | Amplitude exports a ZIP of JSON files through organization settings, the Export API, or S3. PostHog needs those events converted to its schema before capture. | Pilot a short range, convert event names and properties, and set historical_migration before a full import. |
| Event names, properties, and timestamps | partial | critical | PostHog’s Amplitude guide remaps names such as [Amplitude] Page Viewed to $pageview, EMPTY user properties to null, and event_time to ISO 8601. | Keep an event dictionary and reject unmapped critical events or properties. |
| Anonymous and identified users | partial | critical | Amplitude attributes pre-login events to a device ID. PostHog requires an alias from that device ID to the user ID so early events attach to the person. | Alias each device and user pair once and record which identities have already been sent. |
| Export API range, size, and timing | partial | high | Amplitude limits one Export API request to 365 days and 4 GB. Ranges use server_upload_time in UTC, not chart time, and recent hours can return 404 until the export delay passes. | Chunk exports, use S3 when an hour exceeds 4 GB, and reconcile against upload time rather than dashboard time. |
| Managed Amplitude import jobs | partial | high | PostHog’s managed Amplitude import transforms and loads events for up to one year per job and needs a paid product analytics plan even though historic imports are free. | Run a test batch in a test project, then chain consecutive year-long jobs for longer history. |
| Historical reports and aggregate metrics | partial | critical | Imported events can support new queries, but Amplitude chart totals can differ from export totals because of timezone and upload-time selection. | Record source baselines and annotate imported versus native periods. |
| Bot traffic and DAU totals | partial | high | PostHog states it blocks bot traffic by default and Amplitude does not, so event and DAU counts can land lower after a faithful import. | Approve the expected drop before treating lower totals as data loss. |
| Dashboards, explorations, and saved reports | lost | high | Amplitude visualization and query configuration does not become PostHog insights. | Rebuild only the signed reporting set against destination events. |
| Audiences, cohorts, and segments | manual | high | Dynamic membership rules must be re-expressed against destination data. | Test known members and exclusions for each active audience. |
| Tracking code and data collection | manual | critical | SDKs, server events, consent, domains, and filters require a new implementation. | Run both collectors in parallel and verify live payloads. |
| Conversions, attribution, and revenue | manual | critical | Names may import while triggers, attribution windows, and revenue fields need destination setup. | Create an event dictionary and test every business conversion end to end. |
| Consent, retention, and deletion | manual | critical | Privacy configuration does not transfer with the event archive. | Rebuild opt-out, deletion, and retention and test them before source collection stops. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Amplitude project or organization | PostHog project and cloud region | manual | Record timezone, currency, domain, and US or EU host. |
| [Amplitude] Page Viewed | $pageview | transform | Map page URL, domain, and path properties. |
| Custom event and event_properties | PostHog event and properties | transform | Keep the signed dictionary and reject unmapped critical keys. |
| user_id or device_id | distinct_id plus alias | transform | Alias anonymous device IDs after identified events exist. |
| event_time | ISO 8601 timestamp | transform | Do not confuse export upload time with event time. |
| EMPTY user_properties | null person properties | transform | Use $set and $set_once as documented. |
| Goal, conversion, or revenue event | Destination conversion or revenue event | manual | Recreate the trigger and test it live. |
| Cohort or audience | PostHog cohort or action | manual | Rebuild membership rules from the measurement plan. |
| Saved chart or dashboard | PostHog insight or dashboard | unsupported | Rebuild from signed questions, not exported pixels. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Amplitude data, configuration, and operating evidence before any destination write.
- Export Amplitude project, event, property, cohort, chart, integration, and privacy configuration.
- Save dated metric, conversion, attribution, and traffic baselines from Amplitude charts.
- Download a rehearsal Export API or organization export for a known range and hash the ZIP.
- Record timezone, retention, filters, consent, and data-deletion settings.
Proof to capture: A signed manifest reconciles every scoped record class, export file, count, and hash.
Amplitude-to-PostHog schema map
Define event names, properties, identity aliases, and expected metric breaks.
- Inventory source events, properties, and identity rules.
- Map Amplitude keys to PostHog names, including $pageview and $autocapture.
- Reject unmapped critical records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Parallel collection and historical import
Build trustworthy live data while loading supported history.
- Run a test batch in a test project first.
- Import with historical_migration and alias device IDs.
- Reconcile accepted, rejected, and transformed events.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
Metric differences are mistaken for data loss
Timezone, upload time, bot filtering, and identity aliasing produce different totals.
- Consequence
- Teams reject valid data or make bad decisions.
- Mitigation
- Approve definitions and expected variance before cutover.
Stop if: A critical metric lacks an owner-approved interpretation.
Conversions silently stop
Pages load while events, server calls, consent, or revenue payloads fail.
- Consequence
- Business reporting and optimization become blind.
- Mitigation
- Test every conversion end to end in live traffic.
Stop if: A critical event has no verified destination receipt.
Collection continues in both tools unintentionally
Old tags remain active beyond the comparison window.
- Consequence
- Privacy scope and operating cost exceed approval.
- Mitigation
- Keep a dated parallel-run plan and remove old collectors only after sign-off.
Stop if: An unowned source collector remains active.
Do the work in this order.
- Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting- Inventory Amplitude events, properties, identities, cohorts, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Amplitude and PostHog administrator access
Stop / go checkpointExport?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
- Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting- Configure PostHog and import a representative Amplitude range.
- Run live collection in parallel and compare identity, events, and conversions.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
- Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedImport or sync propagation waiting- Finish historical jobs and freeze new Amplitude instrumentation changes.
- Make PostHog the production collector and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Counts reconcile and one destination system owns production measurement.
Stop when: A source collector remains the only production source or a blocking check fails.
- Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.
Cut over with a way back.
Cutover
Make PostHog the only production measurement system without losing the final Amplitude delta.
- Finish approved historical imports and freeze Amplitude instrumentation changes.
- Confirm live PostHog collection for every critical client and server event.
- Switch reporting, audiences, and downstream integrations to PostHog.
- Keep Amplitude collection only for the signed comparison window.
- Run every blocking verification check and keep the source intact.
Proof to capture: PostHog owns production measurement, totals reconcile, and every blocking check has durable evidence.
Rollback
Return production measurement to Amplitude without losing destination-era changes.
- Stop treating PostHog as the production collector.
- Restore Amplitude tags, SDKs, and downstream integrations.
- Export PostHog events captured after cutover if they must be preserved.
- Review and apply safe destination-era instrumentation changes to Amplitude.
- Run the same blocking checks against the restored source.
Proof to capture: Amplitude again owns production measurement with current collection and no duplicate destination action.
- Unexplained critical count or value variance
- Missing or exposed critical data
- Duplicate production action
- Failed access, routing, delivery, or integration check
- A critical feature has no safe destination replacement
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Live event receipt | Trigger every critical client and server event. | One valid destination event with approved properties. | Event log. | |
V-02Blocking | Business outcome tracking | Complete every approved conversion path. | Conversion and revenue values reconcile. | Conversion report. | |
V-03Blocking | Event and property mapping | Compare the signed schema with live and imported payloads. | No critical event or property is unmapped. | Schema diff. | |
V-04Blocking | Parallel-run interpretation | Compare daily metrics for the approved overlap window. | Variance is explained and owner-approved. | Metric comparison. | |
V-05 | Imported-event coverage | Compare available dates, event counts, and identity aliases. | Every supported period is imported or explicitly archived. | History ledger. | |
V-06Blocking | Device-to-user aliases | Replay anonymous-then-identified journeys. | Pre-login events attach to the identified person. | Alias report. | |
V-07Blocking | Consent, retention, and deletion | Test opt-out, deletion, access, and retention configuration. | Collection and lifecycle match policy. | Privacy evidence. | |
V-08Blocking | Reporting ownership | Inspect tags, SDKs, APIs, exports, and dashboards. | PostHog owns approved production measurement. | Ownership checklist. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.
- Create final Amplitude exports and archive verification evidence.
- Revoke temporary credentials, API keys, webhooks, and elevated roles.
- Remove obsolete tags, SDKs, jobs, integrations, and unused collectors.
- Keep the source intact through the approved retention window.
- Cancel paid plans only after billing, legal, and recovery review.
- Schedule the next PostHog backup, access, and migration-playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
PostHog’s Zealot case study quotes CTO Brandon Jakobson on running Amplitude and PostHog side by side for an AI customer-activation product. He says Amplitude felt clunky and missed data points that PostHog captured in the same period. The team then invited more people because PostHog did not price by seat, and later removed Amplitude and BugSnag after error tracking plus session replay covered the same daily work. This is a vendor-published interview, not an independent write-up.
- Run both collectors on the same product traffic before you retire Amplitude, and compare missing events rather than dashboard polish.
- Decide whether seat-based pricing is pushing you to keep analytics in a small group, because that changes who can validate the new project.
- The quoted decision followed a parallel run, not a one-shot historical import.
- Error tracking and replay were part of why Amplitude left the codebase, so this move was broader than swapping one analytics SDK.
Modestas Jurčius posted that Persikas replaced Amplitude with PostHog because setup was faster and the team could debug incoming events, including a live stream. He also wrote that the change would save about 500 euros a month. The post is short and does not describe export, identity mapping, or historical import, so treat the cost figure as the author’s claim rather than a measured migration study.
- Use a short first-person note like this only to confirm demand, then still run a signed event dictionary and a parallel collection window.
- If cost is the reason for the move, export current Amplitude spend and event volume before you compare PostHog invoices.
- Live event debugging was the product reason given, alongside the monthly saving.
- The post does not prove that charts, cohorts, or history transferred, only that the team changed collectors.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- PostHog: migrate from AmplitudeAccessed 2026-10-23
- Amplitude: Export APIAccessed 2026-10-23
- PostHog: managed migrationsAccessed 2026-10-23