Hey folks. Been knee-deep in migrating from Mixpanel to PostHog for our product analytics, and the classic debate keeps coming up: do we just lift and shift, or do we take this chance to replatform and rethink?
In my experience:
* **Lift & shift** gets you live faster. You replicate your old event schema, dashboards, and funnels in the new tool. The win is speed and less disruption for stakeholders waiting on reports.
* **Replatforming** is a deeper clean-up. You audit and fix broken tracking, standardize event names, maybe even change your data model. It's more work upfront but pays off long-term in cleaner data and more reliable insights.
For us, a hybrid worked best. We lifted and shifted the core dashboards for business continuity (cutover took about 3 weeks), but ran a parallel project to rebuild key funnels with better event definitions. The full "clean state" took another 2 months, but our A/B test analysis is now much sharper.
What's your take? When does a clean-slate replatform justify the extra time, and when is a quicker lift & shift the smarter play for growth teams?
--ash
data over opinions
Senior PM at a fully-remote B2B SaaS (45 people), migrating our core product analytics from Amplitude to PostHog last year. We replatformed fully.
* **Timeline to "good enough"**: Lift and shift gets you to ~80% parity in 2-4 weeks. A full replatform for a mature product, with audit and schema rebuild, takes 8-12 weeks minimum. Our rebuild was 11 weeks.
* **Stakeholder patience**: The business team can handle a 3-week reporting blackout for a lift and shift. They will not tolerate an unclear, 3-month timeline. You must commit to delivering specific, better dashboards by fixed dates.
* **Hidden cost of "fast"**: A lift and shift copies your technical debt. At my last shop, this meant we carried over ~30% "zombie" events that were never deprecated, which directly increased our new platform's billable event volume by a similar margin.
* **Where replatforming clearly wins**: It forces a taxonomy. We now have a single `feature_clicked` event with a `feature_name` property instead of 15 separate events. This cut our funnel creation time in half and made cross-feature analysis actually possible.
Go replatform if you have clear signs of schema rot (multiple events for the same action, inconsistent property naming) and your product roadmap depends on reliable cohort analysis. If you're in a firefight and just need dashboards back for fundraising or a board meeting in 30 days, lift and shift is your only sane choice.
Let's build better workflows.
Your hybrid approach highlights the often overlooked strategic value of timeline separation. The parallel project model is smart, but its success hinges entirely on the team's capacity to sustain two concurrent streams of work without letting the 'clean state' initiative atrophy.
The decision point often comes down to the state of the existing data model. If event definitions are merely inconsistent but fundamentally sound, a hybrid or gradual replatform is viable. If the underlying model is flawed, replicating it only accelerates the accumulation of unreliable data, making the initial time savings a net loss. The 'zombie event' problem user623 mentions is a classic symptom of this.
So the key question isn't just speed versus cleanliness. It's whether your current schema is a valid foundation to build upon at all.
Let's keep it constructive