How to migrate your PostHog self-hosted to PostHog Cloud


At Qovery, we were using PostHog self-hosted for 8 months in production. It was running nicely on Qovery (yes, we deployed PostHog with Qovery 😎 #eatYourOwnDogFood), but we decided to move to the PostHog Cloud. Here are the two main reasons why we decided to make this move:
If you are not yet using it, give it a try with Qovery or PostHog Cloud version.
- To support the PostHog project: Because we love their product, keeping them by using their Cloud version makes complete sense to us.
- Stay focused on our business: Using the self-hosted version of PostHog requires you to spend time to maintain it. Meaning, you have to handle the upgrade yourself and make sure the service is up and running all day long.
How to migrate
Looking at their documentation, there is no guide to migrate from PostHog self-hosted to their Cloud version. I asked them the procedure on Slack, and Paolo from the PostHog team responded that it should not be too complicated to transfer the data by fetching the data from the PostHog source and pushing them to the PostHog destination via the web API.

So the idea was to make a Python script to fetch the data from our self-hosted PostHog instance and forward the data to the PostHog Cloud version.
(Self-hosted PostHog) <--[fetch event data via web API]-- Python Script --[send event data via web API]--> (PostHog Cloud)
Before migrating
As I know that we have more than one million events to send, I notified the PostHog support team that we will migrate our self-hosted version. Just in case they have to adjust their infrastructure. Who knows :) Paolo (once again, he is everywhere 🙂) responded to me and was super proactive.


I encourage you always to keep informed the support team of service when you are about to migrate. They can help you. It was the case here with the PostHog support team.
We can migrate now
To migrate, I made a simple Python script using no external dependencies. Only HTTP requests, and that's it. Note: This script is compatible with Python 3.6+.
Before running the migration script, I strongly recommend making your apps send the data to the PostHog Cloud instance before and waiting for the old instance to stop receiving new events.
Now it is time to:
- Copy this script.
- Change the value of the variables source_posthog_scheme_and_host, source_api_key, dest_project_api_key
- Run the script and wait until it is done 👌
Wrapping up
The migration went smoothly and took one day because we had more than 1 million events. We are super excited to use PostHog Cloud. It is fast and efficient for improving the developer experience on Qovery. Any questions about our usage of PostHog? Join our Discord to chat about it.
Resources:

Suggested articles
.webp)