Amplitude to PostHog Migration: The Complete Guide

Why teams migrate from Amplitude to PostHog

Amplitude's MTU pricing model is the most common trigger. Monthly Tracked Users charges you the same whether a user fires one event or five hundred. As your product matures and engagement deepens, your MTU count stays flat but your event volume grows, which means Amplitude's per-user cost feels increasingly disconnected from the value you're extracting.

The 8% annual automatic price increase compounds this. A $2,000/month Amplitude Growth plan becomes $2,160 at renewal, then $2,333, without any change in usage. Teams that signed two-year deals are now looking at invoices they did not budget for.

That math runs in the background. No conversation, no renegotiation. The invoice changes and you find out when it arrives.

Feature scope drives the second category of migrations. PostHog bundles session replay, feature flags, A/B experiments, and surveys on the same event pipeline as product analytics. Teams paying for Amplitude analytics plus a separate feature-flag tool often find PostHog consolidation saves more than the raw analytics cost difference. Regulated teams get everything under a single BAA.

Open source is the third reason. PostHog is MIT licensed and self-hostable. Teams with strict data residency requirements cannot get this from Amplitude at any price tier. Teams that simply prefer owning their analytics infrastructure get that option on the free plan.

Before you start: the migration audit

The single most important pre-migration step is auditing your Amplitude implementation before you replicate it. Most mature Amplitude implementations contain a significant number of events that nobody queries anymore, events added during a feature build that shipped years ago, events with inconsistent naming conventions from different engineering teams, events with properties that are always null.

Carrying those events into PostHog replicates the data quality problems of your old setup into the new platform. Migration is the one moment when it is socially acceptable to say "we are not carrying that forward", take it.

What to keep, clean, and cut

Go through your Amplitude event list and categorize each event into one of three buckets before writing a single line of migration code.

• Keep as-is: events that are queried regularly, have consistent property schemas, and answer questions your team makes decisions from
• Keep with cleanup: events that answer valid questions but have naming inconsistencies, missing properties, or properties with low fill rates, redesign the schema and implement the clean version in PostHog
• Cut: events that were added for a specific feature, never fed a dashboard or funnel, and have not been queried in the last 6 months. Do not migrate these.

A clean migration that carries 60% of your Amplitude events into PostHog is better than a complete migration that carries 100% of the data quality problems too.

Mapping Amplitude events and properties to PostHog

Amplitude and PostHog use the same conceptual model. Events with properties, tied to users via a distinct identifier. The APIs are different but the mapping is straightforward.

User properties are the most likely source of confusion during migration. The concept is identical. The API is different.

In Amplitude, you call identify via the SDK's Identify object and amplitude.identify(). In PostHog, you call posthog.identify() with the distinct ID and a properties object. The result is the same. Person-level properties attach to the user profile, available for segmentation and cohort filtering.

Running Amplitude and PostHog in parallel

Dual-tracking is non-negotiable for a reliable migration. Running both platforms simultaneously for 2-4 weeks gives you the data to validate that PostHog is capturing events correctly before you turn Amplitude off.

Implementing dual-tracking

The simplest approach is to fire events to both SDKs from the same event handler. Keep the code collocated so it is obvious which events are being dual-tracked.

// Shared event helper — fires to both platforms during migration
function trackEvent(eventName, properties = {}) {
  // PostHog
  posthog.capture(eventName, properties)

  // Amplitude (legacy — remove after cutover validation)
  amplitude.track(eventName, properties)
}

// Shared identify helper
function identifyUser(userId, userProperties = {}) {
  // PostHog
  posthog.identify(userId, userProperties)

  // Amplitude (legacy)
  const identifyEvent = new amplitude.Identify()
  Object.entries(userProperties).forEach(([key, value]) => {
    identifyEvent.set(key, value)
  })
  amplitude.identify(identifyEvent)
}

// Usage — no changes needed at call sites
trackEvent('Feature Used', { feature: 'export', format: 'csv' })
identifyUser(user.id, { plan: user.plan, company: user.company })

This pattern means every call site in your codebase continues to work unchanged. When you cut over, you remove the Amplitude lines from trackEvent and identifyUser and delete the Amplitude SDK, no call site changes needed.

Validating event parity

During the parallel-tracking window, compare event counts in both platforms daily. Expect 2-5% variance from timing differences, session boundary handling, and bot filtering. More than 5% variance on a specific event is a tracking gap, not a rounding difference.

Stop at 5%. Do not rationalise a 9% gap as close enough. It is not.

Focus validation on your top 10 funnels by query frequency. These are the dashboards your team looks at every week. If they are not accurate in PostHog, you will lose trust in the platform before you even complete the cutover.

Importing historical Amplitude data into PostHog

PostHog supports historical data import from Amplitude through two paths. The first is a managed migration via the PostHog UI. The second is a manual import using the Python SDK with the historical_migration flag.

Managed migration (recommended)

In your PostHog project settings, navigate to Data Management and look for the migration option. PostHog's managed Amplitude migration handles the export, transformation, and import automatically. You provide your Amplitude API credentials; PostHog does the rest.

Prerequisites for the managed migration are a paid PostHog product analytics plan (the import itself is free and does not count against your event quota) and your Amplitude organization API key and secret key.

Manual import via Python SDK

For teams who want control over the transformation step, for example, to clean event names or drop events during import, the Python SDK approach lets you write the transformation logic yourself.

import requests, zipfile, json, io
from posthog import Posthog
from requests.auth import HTTPBasicAuth
from datetime import datetime

# Step 1: Export from Amplitude
amp_key = '<amplitude_api_key>'
amp_secret = '<amplitude_secret_key>'
start = '20240101T00'
end = '20241231T23'

response = requests.get(
    f'https://amplitude.com/api/2/export?start={start}&end={end}',
    auth=HTTPBasicAuth(amp_key, amp_secret)
)

# Step 2: Import into PostHog with historical_migration=True
posthog = Posthog(
    '<ph_project_token>',
    host='https://us.i.posthog.com',
    historical_migration=True  # disables quota counting for these events
)

# Step 3: Transform and send
with zipfile.ZipFile(io.BytesIO(response.content)) as zf:
    for name in zf.namelist():
        with zf.open(name) as f:
            for line in f:
                event = json.loads(line)

                # Map Amplitude event to PostHog format
                posthog.capture(
                    distinct_id=event.get('user_id') or event.get('device_id'),
                    event=event['event_type'],
                    properties={
                        **event.get('event_properties', {}),
                        '$timestamp': event['event_time'],  # ISO 8601
                        '$ip': event.get('ip_address'),
                        '$os': event.get('os_name'),
                        '$browser': event.get('os_name'),
                    },
                    timestamp=datetime.fromisoformat(event['event_time'].replace(' ', 'T'))
                )

posthog.flush()
print("Import complete.")

Timestamps must be ISO 8601 format and at least 48 hours before the import date. PostHog will reject events with future timestamps. Run the import in batches of 30-90 day windows rather than all at once to avoid timeout issues on large datasets.

Rebuilding Amplitude dashboards in PostHog

Do not try to replicate every Amplitude chart, replicate the decisions those charts inform. For each Amplitude dashboard, ask what question it answers and build a PostHog equivalent that answers the same question. Some charts will simplify; a few will need HogQL for the exact same calculation.

Amplitude to PostHog chart type mapping

The dashboard rebuild is the most time-consuming part of the migration for teams with large Amplitude chart libraries. Budget 1-2 weeks. Prioritise dashboards that are checked weekly or used in leadership reviews. Those are the charts that will block cutover sign-off if they are not ready.

Start the rebuild in week 4, while parallel data is still accumulating. Not in week 7 after parity is confirmed.

Cutting over and decommissioning Amplitude

Cutover is a business decision, not just a technical one. Before you turn off Amplitude, confirm that the people who make product decisions using analytics data have validated their primary dashboards in PostHog and are comfortable using them.

Cutover checklist

Work through this list before removing the Amplitude SDK from your codebase.

• Event parity validated: PostHog event counts are within 5% of Amplitude on your top 10 funnels over a full two-week window
• Dashboard rebuild complete: all decision-critical charts rebuilt and reviewed by the relevant stakeholders
• Historical import confirmed: historical data visible in PostHog and date ranges align with what was in Amplitude
• Identify and person properties verified: user profiles in PostHog are populated with the correct person properties
• Session replay sampling confirmed: recordings are appearing for sessions on your primary product surfaces
• Stakeholder sign-off: product, data, and leadership teams have confirmed they can do their work in PostHog
• Amplitude contract reviewed: you know your renewal date and notice period so you can cancel before the next billing cycle

After cutover, leave the Amplitude SDK in place but commented out for two weeks as a safety net. Once you confirm PostHog is running cleanly with no data gaps, remove the Amplitude code completely and cancel your subscription.

What PostHog does not replicate from Amplitude

Most Amplitude use cases map directly to PostHog. A few do not, and it is worth knowing them before you commit to the migration.

• Amplitude Predict: ML-based churn and conversion prediction trained on your event data. PostHog has no equivalent. Teams who rely on Predict outputs need to replicate this in a data warehouse or with an external ML pipeline.
• Compass: Amplitude's engagement scoring system. PostHog does not have an out-of-the-box engagement score. You can approximate it with HogQL using event frequency and recency signals, but it requires custom query work.
• Revenue LTV dashboards: Amplitude's Monetization and Revenue analysis features assume a specific revenue event structure. PostHog can do revenue analytics but requires building it from your event data using HogQL rather than using a pre-built module.
• Deep linking with Amplitude's Experiment: Amplitude's Experiment product has deep integration with Amplitude Analytics for sequential analysis. PostHog's experiments work well but the integration with its own analytics is somewhat different in practice.

For most B2B SaaS product analytics teams, activation tracking, churn analysis, feature adoption, funnel optimization, these gaps are not blockers. They become relevant primarily for growth-stage consumer apps that rely on Amplitude's ML features as a core part of their retention workflow.

Migration timeline and how to start

A well-run Amplitude to PostHog migration takes 6-8 weeks end to end. Rushing the parallel-tracking window is the most common mistake, two weeks is the minimum; four weeks gives you enough data to validate seasonal patterns and low-frequency funnels.

1. Week 1: Audit and planning. Audit your Amplitude event list. Categorize events into keep, clean, and cut. Map your top 20 Amplitude charts to their PostHog equivalents. Create your PostHog project and confirm the managed migration is available in your account settings. This week produces a document, not code.
2. Weeks 2-3: PostHog implementation. Install the PostHog SDK alongside Amplitude using the dual-tracking wrapper. Start on your highest-traffic surfaces, validate event counts, then roll out to the rest of the product.
3. Weeks 4-5: Parallel tracking. Run both platforms simultaneously. Compare event counts daily. Five percent variance is normal. Above that, stop and investigate before moving forward. Start rebuilding priority dashboards now, not after parity is confirmed.
4. Week 6: Dashboard rebuild and stakeholder review. Complete the rebuild and walk each team through their primary charts in PostHog. Collect explicit sign-off from the people who will depend on these dashboards. If sign-off stalls, cutover stalls. Schedule these sessions at the start of week 6.
5. Week 7: Historical import. Run the managed Amplitude migration. Verify date ranges and event counts match what you saw in Amplitude before deciding parity is confirmed.
6. Week 8: Cutover. Remove Amplitude from production. Comment out the code rather than deleting it immediately. Cancel Amplitude at your next renewal window.

The sequence matters. Do not start the historical import until parallel-tracking validation is complete. If you discover tracking gaps during parallel tracking, fix them in the live implementation first. Importing the same flawed schema historically does not fix the problem.