Migrate from Hotjar to PostHog when the Contentsquare move forces a decision
Hotjar now sits inside Contentsquare and new Hotjar accounts can no longer be created, so the decision is where your recordings, heatmaps and survey data live next. Moving to PostHog is a realistic path when you want heatmaps, session replay, surveys and product analytics in one tool that you run yourself. Plan from the start that historical Hotjar recordings and heatmaps do not carry over, so the work is rebuilding what you need going forward, not transferring an archive. Export any Hotjar material you must keep for audit or reference before your access changes, and confirm with Contentsquare what export options your current plan includes.
Most of the effort is configuration, not data movement. Someone must install the tracking snippet on each site, rebuild your heatmap and recording targets, recreate surveys, and set masking rules so that form fields, account numbers and other sensitive elements are never captured. Masking should be tested on real pages with a test account before the old snippet is removed, and the rules should be documented so reviewers can see what is hidden and why. Rebuilding funnels and dashboards is also work that cannot be copied across tools, so inventory the views your teams use today.
Ownership is the decision that matters most. PostHog's self-hosted product is officially unsupported, and PostHog does not offer customer support for infrastructure or product questions on self-hosted instances. Your team, or a partner you contract, must own the servers, upgrades, backups, monitoring and incident response. Confirm which PostHog edition and license your use case needs, since premium features in the ee directory require a paid license on self-hosted instances. Run both tools for a short overlap so you can compare recordings and events before you retire Hotjar.
Which Hotjar capabilities map cleanly to PostHog and which need rework
This table maps each Hotjar capability to its closest PostHog equivalent and labels it as clean, needs rework or gap. Read the status column first, then the notes, because rework items usually carry the effort in a migration. Confirm heatmap and survey parity against the current PostHog documentation for your plan before you commit.
| Hotjar capability | PostHog equivalent | Status and notes |
|---|---|---|
| Historical recordings and heatmaps | No import path from Hotjar | Gap: past Hotjar recordings and heatmaps do not carry over. Export what you need as evidence or reference before the Hotjar account closes. |
| Session recordings | Session replay | Clean for new traffic: PostHog's README lists session replay as a core product. Recording starts only after the tracker is installed. |
| Heatmaps | Heatmaps in PostHog | Needs rework: confirm heatmap feature parity against current PostHog docs for your plan. Rebuild the pages you care about after data collects. |
| On-site surveys and feedback widgets | Surveys | Needs rework: PostHog's README lists surveys in the same product as replay and analytics. Recreate each survey, targeting rule and trigger by hand. |
| Funnels | Product analytics funnels | Needs rework: rebuild each funnel as an insight on the new event stream. Historical Hotjar funnel data does not transfer. |
| Event tracking | Custom events and autocapture | Needs rework: map each Hotjar trigger or tag to a named PostHog event and check property names against your analytics plan. |
| Input and text masking rules | Replay masking settings | Needs rework: recreate masking for every form and sensitive page, then test with real flows before relying on it for compliance. |
| Consent and tracker deployment | Tracking snippet and consent gating | Needs rework: swap the Hotjar snippet for the PostHog snippet and confirm consent behavior with your legal team, since recording is not covered by the analytics exemption. |
What data can move and what must be rebuilt
Hotjar recordings and heatmaps do not move into PostHog, so the migration is mostly re-instrumentation. The cards below separate the few event histories that can be imported from the configuration work that has to be redone by hand on the new side.
Hotjar recordings and heatmaps
Past Hotjar session recordings and heatmap data have no supplied export path into PostHog, so plan on starting a fresh data set on the day PostHog goes live. Teams that rely on a year of replay evidence should decide now whether to keep Hotjar access long enough to review or archive what they need. Ask Hotjar and Contentsquare directly what export options exist for your account and plan before you rely on any of them.
Managed imports cover Mixpanel and Amplitude
PostHog's managed migrations import historical events directly from Mixpanel or Amplitude, or from JSONL files in an S3 bucket. Each direct import job covers at most one year of data, and events are not deduplicated. Hotjar is not on this list, so these imports only help if you also run one of those tools and need its history in PostHog.
Scripted paths from Heap and Google Analytics
PostHog documents scripted migrations from Heap through Heap Connect and from Google Analytics through the BigQuery export. If your product events were captured in Heap or Google Analytics rather than Hotjar, these are the realistic routes for historical event data. Inventory which event history your product, growth and support teams actually query before committing effort to any import.
Event inventory and history needs
Before cutover, list the questions that depend on past data, such as funnel baselines, retention cohorts and survey trends, and the owner of each. Many teams find that only a small set of events needs history, while the rest can start clean. Record which dashboards must be recreated and which can be retired, so the rebuild scope is written down.
Tracking snippet and event instrumentation
Replacing the Hotjar snippet means adding the PostHog SDK and re-instrumenting the events that drive heatmaps, recordings and surveys. Hotjar's tags and attributes do not translate automatically, so map each page, click target and form step to a PostHog event or autocapture rule. Test on staging and confirm that events arrive with the expected names and properties.
Consent, masking and integrations
Consent banners, replay masking rules, survey targeting and downstream integrations such as tag managers, CRM connectors and Slack alerts must be configured again in the new tool. Confirm your consent basis with counsel before the first event is sent, since CNIL's guidance treats recordings differently from simple audience measurement. Document each masking rule so that privacy reviews can trace what is captured.
The migration sequence from inventory to decommission
This sequence moves Hotjar's working setup to PostHog in an order that keeps data collection continuous and leaves a checked record of what was rebuilt, what was dropped and what was exported before Hotjar is switched off. Each step ends with a written output that the next step depends on.
Inventory pages, events, surveys and masking rules
List every site and page where Hotjar runs, every recording and heatmap view your team uses, every survey and feedback widget, and every masking or suppression rule set in Hotjar. Record the owner of each item and whether it feeds a report, a consent banner or a product decision. Include the custom events and identify strings your analysts depend on, since these must be recreated as PostHog events and properties. The output is a signed inventory sheet that marks each item as rebuild, replace or retire, and that the consent and privacy owners have reviewed.
Pilot on one low-risk section
Stand up a PostHog evaluation instance using the free Docker Compose hobby deployment, installed with the deploy-hobby script, on a server that meets the sizing in PostHog's self-host documentation. Add the PostHog snippet to one low-risk site or section, rebuild one heatmap, one recording rule and one survey, and check masking on real pages before anything else. Treat this instance as an evaluation environment, since PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for them. The output is a pilot report listing what worked, what masked incorrectly and what your team cannot run without.
Decide hosting before scaling the pilot
Compare the pilot results with the expected event volume. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that. Also weigh the EU (Frankfurt) and US (Virginia) regions of PostHog Cloud against self-managed hosting in your own infrastructure, and confirm with your privacy team which option meets your data residency rules. Ask the vendor or your implementation partner to confirm current support terms for the chosen option. The output is a recorded hosting decision with its volume estimate and the named owner who will run it.
Run both tools in a short parallel overlap
Load Hotjar and PostHog together on the same pages for a short, fixed overlap agreed in advance. Compare daily session counts, heatmap click totals on the same pages, survey response counts and masking behavior, and note where the two tools disagree and why. Confirm that the PostHog events and properties match the inventory from step one. Keep the overlap short so that duplicate tracking does not add load or confuse analysts. The output is a reconciliation log that the analytics owner signs off on, with each gap either fixed or accepted in writing.
Cut over the snippet and update consent
Replace the Hotjar snippet with the PostHog snippet on each site in the agreed order, and update the consent banner so that the categories and wording match what PostHog collects. If you rely on the CNIL audience measurement exemption, confirm the conditions in CNIL sheet 16 with your privacy counsel before you rely on it, since the exemption depends on how the tool is configured. Remove Hotjar's tag from tag managers and templates so it cannot load by accident. The output is a change record per site showing the snippet swap date, the consent text version and a test that confirms events arrive in PostHog and no Hotjar requests fire.
Export what you can, then decommission Hotjar
Before you cancel or let Hotjar lapse, export every recording, heatmap, survey response and report you need to keep, in whatever formats Hotjar provides for your plan. Record what cannot be exported, because historical recordings and heatmaps do not carry over to PostHog, and tell stakeholders which past views are gone. Confirm the exports open and contain the data you expected, then remove the Hotjar account access for users who no longer need it. The output is an archive index with checksums, a list of lost artifacts accepted by the business owner, and a closed Hotjar decommission ticket.
How to run Hotjar and PostHog side by side without skewing data
Running both tools on the same pages gives the most direct comparison, because every visitor is counted by Hotjar and PostHog at once. It is also the option with the greatest effect on the live site, since two third-party scripts load on every page and both may set cookies or identifiers. Use it only for a short window and only when you need to confirm that heatmap, recording and survey numbers line up closely enough to retire Hotjar.
- Page weight: Measure load time and script execution before and after adding the PostHog snippet, on your slowest templates as well as the homepage.
- Consent scope: Confirm that both tools sit behind the same consent category, so a visitor who declines is not tracked by either one.
- Sampling: Set Hotjar and PostHog recording rates to match, or the session counts will not be comparable.
- Masking: Apply the same input and text masking rules in both tools before any recording starts.
- Fixed end date: Write down when the overlap ends and who removes the older snippet.
Before you start, check that the consent tool blocks both scripts in the same way and that a rejected visitor generates no requests to either vendor.
Running PostHog on a subset of traffic limits the risk to the live site. You can route a fixed share of visitors, such as one section of the site or a set of signed-in test users, to PostHog while the rest stay on Hotjar. This reduces the performance and consent exposure, but it also makes the numbers harder to compare, because the two groups may behave differently. Choose the slice carefully so it resembles the traffic you will eventually move.
- Representative slice: Pick pages or cohorts that cover the same devices, countries and landing pages as the full audience.
- Assignment method: Decide whether assignment happens by feature flag, by path or by a stable visitor ID, and record the rule.
- Comparison caveat: Compare rates within each group rather than raw totals across groups.
- Cookie handling: Confirm that assignment does not place a persistent identifier on visitors who have not consented.
- Exit criteria: Define the metric gaps that would stop the test early.
Ask your team to confirm how the traffic split is implemented in your own tag manager or application before launch, since a split applied in the wrong layer can leak events to the wrong tool.
A staging copy lets you verify the PostHog setup without touching production visitors. You deploy the PostHog snippet to a non-production environment, replay representative journeys, and check that events, recordings and surveys behave as expected. This option carries almost no consent or performance risk for real users, but it cannot prove how production traffic will affect your numbers. Treat it as a rehearsal, and plan a short live overlap afterward.
- Environment separation: Use a separate PostHog project for staging so test events never mix with production analytics.
- Scripted journeys: Run the same test scripts against both tools to confirm event names and properties match.
- Hosting footprint: A self-hosted instance needs its own server. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The hobby Docker Compose deployment, installed with a deploy-hobby script, is an evaluation starting point and is not a production design.
- Support boundary: PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for them, so plan internal or partner ownership before go-live.
- Cleanup: Remove staging keys and test users once the rehearsal ends.
Confirm the current sizing and deployment guidance in PostHog's self-host documentation before you provision hardware, because requirements can change between releases.
Rebuilding replay masking rules before the first recording
Masking has to be configured again in PostHog before any session replay is captured. Hotjar's masking settings, its suppression rules for form fields and any custom selectors do not transfer, so a recording started on day one without them can capture passwords, payment fields, health or identity data and free-text inputs. Treat masking as a go-live gate: list every page template and form on the site, decide which elements must be masked by default (inputs, sensitive text blocks, images that show personal data), and verify each rule on a staging site before enabling replay in production. Keep the decisions in a written record so an auditor or privacy officer can see what was masked and why.
Consent needs its own review and should not be assumed from the old setup. France's CNIL states in its analytics guidance that most large audience measurement tools fall outside the consent exemption regardless of how they are configured, which means recording behavior and cookie consent for PostHog should be checked by legal counsel and the privacy team before launch, not copied from the Hotjar banner. The exemption conditions in CNIL sheet 16 are useful for reference, but session replay and surveys are the features most likely to fall on the consent side of the line. Ask counsel to confirm the lawful basis for each feature, the banner wording and whether replay can start only after an opt-in.
Confirm the data residency choice before any recording is sent. PostHog Cloud offers US and EU hosting regions, and a self-hosted instance keeps data on servers you choose, so the decision also determines who operates the storage, where backups sit and which transfer mechanism, if any, applies. Ask PostHog to confirm the current regional options and terms, and document the chosen location in the processing record. If you self-host, the replay data and masking configuration both live in your environment, so the masking test plan above should run against that same deployment.
What drives the cost and duration of the move
This table lists the cost components of moving from Hotjar to self-hosted PostHog, who is paid for each, and what pushes it up or down. Read it before requesting a quote, because most of the effort sits in inventory and rebuilding rather than in the server itself.
| Cost component | Who is paid or who spends time | One-time or recurring, and main drivers |
|---|---|---|
| Internal inventory and rebuild | Your product, marketing and engineering staff | One-time. Driven by the number of pages, funnels, surveys and recordings you currently run in Hotjar. |
| Self-hosted infrastructure | Your cloud account or data center | Recurring. PostHog's self-host docs recommend about 4 vCPU, 16 GB RAM and over 30 GB storage for the hobby deployment, and storage grows with replay volume. |
| Ongoing operations and upgrades | Your platform team, or a support retainer if you buy one | Recurring. PostHog states self-hosted deployments are unsupported and it offers no customer support for them, so upgrades and backups fall to you or your partner. |
| Masking and privacy review | Your privacy, security and engineering staff | One-time setup, then recurring review. Grows with the number of forms, fields and pages that carry personal data. |
| External implementation | A partner such as DeployOpen, under a written fixed scope | One-time. Scope follows the page count, survey count and masking rules you agree in advance; quotes follow from that written scope. |
| PostHog Cloud comparison | PostHog, if you choose the managed option | Recurring usage. PostHog's pricing page lists 1 million analytics events free each month, but paid plan features are sold separately. |
| Migration of historical data | Your analytics owner, plus any paid PostHog plan needed for imports | One-time. PostHog's migration docs say the import features need a paid product analytics plan, and past Hotjar recordings do not transfer. |
| Team skills | Your in-house staff or the partner you hire | Affects every line above. Teams without experience running Docker or Kubernetes, or without a privacy lead, usually take longer. |
What usually goes wrong in a Hotjar to PostHog move
Most problems in a Hotjar to PostHog move come from assumptions made early: that history will follow the tool, that privacy settings are already correct, and that someone will keep the platform running. The cards below cover the risks that tend to surface after cutover, each with a check to run before the old Hotjar tracking is removed.
Assuming past recordings will import
Hotjar recordings, heatmaps and survey responses are not something PostHog imports from Hotjar, so the historical view of user behavior usually stays behind in the old account. Teams that plan around a clean cutover often discover this only when a stakeholder asks for last quarter's replays. Before you set a date, export what you need from Hotjar while the account is still accessible, record which pages and funnels you must compare against, and agree on how far back the new baseline starts. Ask whether any Hotjar export option remains available to your plan.
Leaving masking unconfigured
A session replay tool that is installed with default settings can record form inputs, account numbers, health details or other personal data on the page. Hotjar's own masking is not carried over automatically, so the PostHog configuration has to be rebuilt from scratch. Before the snippet goes live on any authenticated or regulated page, list every sensitive field, configure masking for those selectors, and test the result with real session replays in a staging environment. Confirm the setting with your privacy and security owners rather than relying on defaults.
Running self-hosting without an operations owner
PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not provide customer support for product, infrastructure or other questions on self-hosted instances. Someone in your organization or a contracted partner must own upgrades, backups, storage growth, TLS certificates and incident response. Name that owner before go-live, write down the upgrade and restore procedure, and confirm who responds when event ingestion stops. Ask for the sizing and hosting model in writing before choosing between self-hosting and PostHog Cloud.
Running parallel tracking too long
Running Hotjar and PostHog side by side is useful for comparison, but both snippets add scripts to every page and load time grows with each one. A parallel run that drifts into months also doubles the data your teams must reconcile and the consent wording you must keep accurate. Set a fixed end date for the overlap, define the metrics you will compare, and remove the Hotjar snippet on that date. Keep the overlap short enough that the team is not maintaining two sets of surveys and heatmaps at once.
Missing the event definitions funnels need
Hotjar shows recordings and heatmaps by page, but PostHog funnels, retention and feature flag targeting depend on named events and properties. If the team does not define these before launch, the first dashboards show gaps, and historical imports from other tools will not line up with the new names. Write a tracking plan that lists each event, its trigger, its properties and its owner, then check that the snippet and any custom capture calls produce exactly those names. Review the plan with product and analytics owners before the new tool becomes the source of truth.
How the move differs by team size and starting point
A small team with modest traffic usually wants the lowest-effort route, and PostHog's managed Cloud free tier can be the simplest starting point for some teams. The free tier is documented with a monthly allowance of analytics events, one project and one year of data retention. The main decision is whether the team wants to run infrastructure at all, since self-hosting shifts patching, backups and uptime onto the team.
- Free allowance: Confirm the current monthly event allowance on PostHog's pricing page against your own page views and custom events, not against visitor counts.
- Retention: The free plan's one-year retention may suit a team that rarely looks back, but check whether anyone needs older recordings for reviews.
- Self-hosting effort: The hobby Docker Compose deployment is a single-server setup, and PostHog states that self-hosted deployments are officially unsupported, so the team carries the support load.
- Volume growth: PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends Cloud above that, so plan an exit path if traffic grows.
- Rebuild scope: Heatmaps, recordings and surveys will be recreated by hand, so keep the list of what the team actually used in Hotjar short.
Before you commit, measure your real monthly event count and confirm the plan limits with PostHog's current pricing page.
A regulated EU team usually needs self-hosting, a documented consent position and control over where data sits. The CNIL analytics guidance says most large audience measurement offerings fall outside the consent exemption regardless of configuration, so a recording tool's consent status should be checked with counsel before go-live. Self-hosting gives the team control over storage and access, but it does not settle the legal basis by itself.
- License check: The PostHog repository is MIT licensed except the ee directory, so confirm whether any premium features your team needs sit in ee and require a PostHog license.
- Fully free option: The posthog-foss repository is described as purged of all proprietary code and features, so verify its feature set matches your requirements.
- Masking and private mode: Configure replay masking rules and test them on sample pages before recording any real user sessions, and document the settings as evidence.
- Consent records: Map each replay, heatmap and survey to a stated purpose and a consent or exemption decision, and keep the configuration under change control.
- Transfers: If any component or vendor touches data outside the EU, review the transfer basis, including whether the recipient participates in the EU-US Data Privacy Framework.
Ask your data protection officer and an independent assessor to confirm the consent position and the masking design before you migrate.
A team that already runs PostHog for product analytics mostly needs to add Hotjar's features to an existing instance rather than start a new deployment. The main work is in the replacement features: heatmaps, recordings and surveys need to be configured in the project that already holds the team's events. Overlap is easier because the analytics data and the replay data can sit side by side in one tool.
- Project structure: Decide whether replay and survey setup belongs in the existing project or a new one, and align event names with the analytics already in place.
- Replay and masking: Review the masking rules currently applied to product analytics and extend them to session replay before turning on recording for Hotjar's audience.
- Capacity: Confirm the existing self-hosted server or Cloud plan can carry the added replay and survey volume, since the free and paid plan limits apply to the combined events.
- Duplicate tracking: Remove or disable the Hotjar snippet only after the PostHog configuration is verified, so the overlap period does not double-count sessions.
- Ownership: Confirm who maintains the existing instance and whether that owner can take on replay configuration.
Before you start, confirm your current plan's event limits and the license status of every feature you plan to switch on.
Questions teams ask before moving from Hotjar to PostHog
Can we move our historical Hotjar recordings and heatmaps into PostHog?
No supplied source documents a way to import Hotjar recordings or heatmaps into PostHog, so plan on starting fresh in PostHog and keeping Hotjar data where it is. Keep your Hotjar account or an export under Contentsquare's terms for any past sessions you need for audits or research, and confirm with Contentsquare what export options your plan includes before the account changes. PostHog's managed import paths cover event data from Mixpanel and Amplitude and scripted paths from Google Analytics and Heap, which is a different data type from Hotjar session replays and heatmaps.
How much effort and time does a Hotjar to PostHog move take?
The effort depends on how many pages, funnels, surveys and masking rules you need to rebuild, and on how many teams consume the results. The main drivers are the number of tracked pages and flows, the number of surveys and their targeting logic, how many masking rules must be defined and tested before any recording starts, and whether the tracking snippet is deployed through a tag manager or hard-coded in several applications. Ask any provider for a written scope that lists each page group, survey and masking rule, because the schedule follows from that list. A short overlap in which both tools run side by side adds verification work but makes the cutover safer.
Can our own team migrate from Hotjar to self-hosted PostHog without outside help?
Yes, a team with engineers who can run Docker and manage a server can do it alone, but the work needs more than the snippet swap. PostHog's self-host documentation describes a free Docker Compose hobby deployment under the MIT license, installed with a deploy-hobby script, and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The team must also handle backups, upgrades, and privacy review. Official support is not included: PostHog states that self-hosted deployments are officially unsupported. Teams that lack these skills can hire an implementation partner for a fixed-scope engagement.
What does our team need to provide before a migration starts?
Before work begins, the team should gather the inventory of what Hotjar does for you today. List the pages and funnels that use heatmaps, the recording sessions you watch, the on-site surveys and their triggers, and the form fields or personal data that appear on screen. Name a decision-maker who signs off on masking rules, and a legal or privacy contact who confirms how the data is processed. You also need access to the website's code or tag manager, a target hosting environment with capacity, and credentials for both tools during the overlap period. Missing inputs are the most common reason a schedule slips.
Is self-hosted PostHog supported, and which parts are paid?
PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances, so support has to come from your team or a contracted partner. The license model also matters. The PostHog repository is MIT licensed except for the ee/ directory, and the README says premium features from that directory need a PostHog license on a self-hosted instance. Teams that need fully free software can use the posthog-foss repository, which removes all proprietary code and features. Confirm which features you need, such as SSO or audit logs, against the license terms before you commit.
How does a quote follow from a written scope for a Hotjar migration?
A quote follows from the written scope, not from a list price. DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and the quote is built from that document. Ask for the page inventory, masking rules, survey list, hosting design, overlap plan, backup and upgrade responsibilities, and any retainer for ongoing support or upgrades. Each line should show who does the work and what is one-time versus recurring. Ask the provider to state which parts they will not cover, such as historical Hotjar data.
How DeployOpen scopes and runs a Hotjar to PostHog migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Hotjar to PostHog move, we start with a written scope that fixes what is replaced, what is retired and what history is accepted as lost.
How we scope
- Inventory every Hotjar heatmap, recording, survey and tracking snippet in use across your sites and apps.
- Agree in writing which Hotjar features map to PostHog and which will be retired.
- Confirm the hosting target, PostHog version and sizing before any installation work starts.
How we build
- Deploy PostHog in your environment and configure it to your data residency and retention requirements.
- Rebuild surveys, heatmaps and replay masking rules, then test masking against sample pages before go-live.
- Replace the tracking snippet in staged releases and run Hotjar and PostHog side by side for the agreed overlap.
How we hand over
- Document the architecture, masking configuration, access controls, backup routines and upgrade steps for your team.
- Record which historical Hotjar data was not migrated, so stakeholders know what can no longer be reviewed.
- Deliver runbooks for retiring the Hotjar snippet and for maintaining consent settings after cutover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any quote to itemize implementation, hosting, masking review and retainer effort so cost drivers are visible.
