Migrating from PostHog: A Downsizing Guide That Keeps the Signal

PostHog migrations are downsizing projects, and downsizing succeeds by inventory, not nostalgia. The platform does a dozen jobs; you were probably using three. Name them precisely, port them deliberately, and the migration shrinks from a scary quarter-long epic to a focused week. Here is the inventory-first plan.

Step 1: inventory what PostHog actually did for you

Go through the product areas and mark each one honestly:

• Web/product analytics: almost certainly used → ports directly.
• Custom events + identify: used → ports directly (same API shape).
• Session replay: often installed, often disabled for privacy/cost. If genuinely load-bearing, note it — this is the one real gap.
• Feature flags: if used, they need a dedicated replacement (flags are not analytics; pick a flags tool, not a compromise).
• A/B experiments: light usage ports to variant events; heavy usage means keeping a dedicated experimentation tool.
• Surveys / data warehouse: if these are core, you are PostHog's target customer — reconsider leaving, as we say outright in the alternative guide.

Step 2: port the analytics core

The translation is nearly mechanical:

// PostHog                        // Clycyo
posthog.capture('signup', p)  →  window.webanalytics.track('signup', p)
posthog.identify(id, props)   →  window.webanalytics.identify(email, props)
// autocapture pageviews      →  automatic (incl. SPA routes)
// pageleave/clicks           →  automatic click capture

Two upgrades come free: the tracker drops from tens of kilobytes to 1.1 KB (your INP will notice), and revenue moves from client capture to a server-side webhook joined to first-touch attribution.

Step 3: fill the replay gap, the privacy-first way

Most replay usage at startups is forensic: 'show me what the user who hit the bug experienced'. Clycyo's per-visitor timeline — pages, clicks, load times, and JavaScript errors in sequence — answers the same forensic question without recording keystrokes or DOM video, which also means no replay consent problem. Open a few journeys in the live demo and check whether the timeline covers your actual replay use cases; for most teams it does.

Step 4: history and the two-week proof

1. Export the dashboards anyone opened recently as CSVs; archive raw events via PostHog's export if you want cold storage.
2. Run both tools in parallel for two weeks. Expect more recorded visitors on the cookieless side if you had a consent banner gating PostHog.
3. Cut over: remove the SDK, keep the PostHog project read-only for a quarter, done.

The migrations that go badly are the ones that try to port the platform. Port the answers instead — acquisition, activation, revenue, and what-broke — and a free-tier week tells you whether the simpler tool covers them. That is the entire bet, and it is testable for nothing.