What a migration will solve
- Cut-over sending live data to Mixpanel
- Historical backfill of existing data (subject to what data can be modeled as events)
- Integrates easily with existing event data collection methods - SDKs, CDPs, DWH, RETL
What a migration won’t solve
- Existing issues with data trust/quality or data governance → As part of the migration, we recommend a data audit as the first step to only transfer your valuable data and clean up trust/quality issues
- Reporting, Dashboards, and Saved Entities → As part of the migration, you should review your top used reports and dashboards from other tools and sit down with each team to re-build them in Mixpanel
What level of effort does the migration take?
A migration primarily consists of 4 phases:- Technical migration of data → Data audit, Live data cut-over, Historical data import
- Change management migration of end users → Champion identification, User interviews, Team by team specific trainings, Ensuring adoption for each team
- Data governance and implementation optimization → Improving/Implementing data governance processes, Identifying missing or incorrect data, Optimizing workflows for adding/editing data
- Ongoing success planning → Building a product analytics practice
Technical migration of data
Migrating live data tracking
Depending on your current setup, the steps for migrating your live data tracking will differ. Please see the appropriate provider specific guides for more details on how to migrate your existing live data tracking and get started with Mixpanel.Data audit
We’ve found from experience that <20% of the data in a product analytics tool is used for 80%+ of the queries. This is especially true the longer you have been using a tool - over time teams add more and more tracking for new events and properties, and without strong data governance practices, you will inevitably have some messy data in your current analytics tool(s). In the spirit of making sense of the mess, we don’t recommended that you bring all historical data into Mixpanel. A common practice is to leverage your current providers’ tooling to understand which reports, events, and properties are queried by your users. No queries in the past 30 days? These events and properties have probably gone stale - there is low value and high effort in bringing them to Mixpanel, so cut them from your import and do not migrate the existing tracking. After you’ve gotten rid of the obvious (the reports, events, and properties no one uses), you can fine tune this approach by doing user interviews with your top users/champions. These users can help you explicitly define the data they need brought along to Mixpanel (mapped to their key questions and KPIs) so you can focus on what matters. Because these users are the ones building reporting others use, capturing their use cases and making them change agents can be highly beneficial to your migration. This data audit step is optional, but highly recommended - It is a larger upfront investment to make it easier for your users to find useful metrics / reports and avoid higher maintenance costs in the future.Loading historical data
To backfill data, we recommend the following approaches:- If you have a data warehouse: Leverage our data warehouse connector or our Import API to import to Mixpanel.
- If you have a data warehouse without your current provider’s data: Export your data to the data warehouse so you have a record, and then use our data warehouse connector or Import API
- If you do not have a data warehouse: Since there is no historical record of data, for this method you will need to export your data from your current provider and move it into Mixpanel - we provide an easy to use helper function for this here
- Have your Mixpanel champion or owner first set up your Organization settings and Project settings. This will ensure the right access level for your team and enable you to prepare the workspace for ingesting data. This can be done later but doing it up front will allow for you to set key settings for data ingestion (US vs EU servers, project timezone, etc.).
- Load a limited subset of the data into a test project (for example, a single day or data or a sample of the entire dataset) to get started. This will help you identify any errors in the end to end process before you do a full historical data load.
- Load a year’s worth (or less) of historical data during your migration. This will allow your team to review year-over-year trends easily and do historical analysis as needed, without sending a bunch of data which is stale and unlikely to be used.
Change management migration of end users
Once data is live, shift our focus to change management and migrating the existing users. You can mitigate risk here by:- Going team by team to assess currently used reports in other analytics providers, as starting with a baseline of key known reports from another tool helps build trust and confidence for new users to Mixpanel
- Running targeted trainings where you re-build known reports side-by-side in Mixpanel to teach users to fish
- Building a product with awesome UI/UX that will make up for the up-front costs in simpler, more powerful analysis down the line
Data governance and implementation optimization
In many cases, your goal in a migration will be to complete the process as quickly as possible - after all, you may be paying for multiple providers at once. Assessing your data quality and governance is likely to be less of a priority in the short term. We recommend once your data and users are migrated to utilize your learnings from these processes to assess the current state of your data trust and where you need to address data issues to gain adoption. This might mean needing to implement new datasets or improve existing tracking to increase the number of use cases which can be explored by end users. You can read more around our recommended approach and questions to ask yourself here.Ongoing success planning
After the migration, we recommend you focus on longer term goals like:- Improving Data Governance → Creating scalable processes and strategies for managing data at scale
- Optimizing Analysis → Helping end users analyze data for more use cases, faster via training and documentation
- Building a Product Analytics Practice → Cultural change to be a self-serve, data democratized organization