Migrating from Hotjar to OpenReplay: what the move involves
If Hotjar has become a decision point since the Contentsquare merger, the first thing to know is that moving to OpenReplay is a rebuild of tracking, masking and heatmaps, not a transfer of Hotjar data. Past Hotjar recordings and heatmaps do not move into OpenReplay, so the project starts with the tracker, the masking rules and the funnels you need on day one. Plan for a new history that begins at go-live, and decide early whether you need to keep old Hotjar exports for reference or for a compliance file. This work is usually run by a platform or analytics engineering team, with a security or privacy reviewer signing off on the masking configuration before any production traffic is captured. The engineers handle the VM, the installation, the tracker snippet and the event naming, while the reviewer checks which fields are masked, which are skipped and what the retention setting should be. Effort and risk concentrate in two places: the first VM sizing, which OpenReplay's README describes as a starting point of 2 vCPUs, 8 GB of RAM and 50 GB of storage, and the capture-time sanitization, where a gap leaves personal data in recordings.
OpenReplay runs in your own infrastructure, on the cloud account, data center or Kubernetes cluster you choose, so recordings stay under your control and first-party tracking from your own domain is not blocked by ad blockers, as the README notes. Ask the vendor or your own team to confirm the current deployment steps for your target platform in the OpenReplay deployment documentation, and confirm which edition covers your needs, since the open-source edition has community support and self-managed retention. The cost is mostly labor and infrastructure. Infrastructure is recurring and grows with session volume and retention. Labor is largely one-time for installation, tracker work, masking review and dashboard rebuilds, plus ongoing upgrades and backups that your team or a partner carries. When you request a quote from DeployOpen or anyone else, ask for the written scope to name the environments, masking test plan, Hotjar feature mapping (heatmaps, recordings, on-site surveys) and handover documentation.
Which Hotjar capabilities map cleanly to OpenReplay
This table maps the Hotjar capabilities most teams rely on to what OpenReplay documents, marking each as clean, needs rework or gap. Read the status column first, then the notes, because heatmaps and funnels are rebuilt as new definitions rather than copied across. The main takeaway is that session replay and masking map well, while on-site surveys need a separate tool.
| Hotjar capability | OpenReplay status | What to plan for |
|---|---|---|
| Session recordings | Clean | OpenReplay records sessions from its own tracker. Past Hotjar recordings do not move, so plan a parallel run for new traffic. |
| Heatmaps | Needs rework | OpenReplay lists heatmaps under product analytics. Rebuild each heatmap as a new definition for the pages and events you care about. |
| Funnels | Needs rework | OpenReplay documents funnels within product analytics. Redefine each funnel step in OpenReplay and check it against a known user path. |
| Console and network data | Clean | DevTools covers network activity, console logs and JavaScript errors. Confirm the capture settings you need for your application. |
| Input and text masking | Needs rework | Masking by CSS selector, input redaction and private mode exist. Rebuild your Hotjar masking rules as selector rules and test them on real pages. |
| Cobrowsing | Clean | OpenReplay documents cobrowsing with WebRTC calls. Confirm that your support staff can use it under your access policies. |
| On-site surveys and feedback widgets | Gap | OpenReplay does not provide on-site surveys. Choose a separate survey tool and plan how its responses will link to session data. |
What data can move and what must be rebuilt
Hotjar recordings and heatmaps do not come across to OpenReplay, so the migration is a rebuild with an archive step in front of it. The cards below separate what you export or keep from what you recreate, and what to confirm with Contentsquare before you cancel.
Historical recordings and heatmaps
Past Hotjar recordings and heatmaps do not transfer to OpenReplay. Before you cancel, export or archive any Hotjar data you need for audits, complaints, UX research or a retention obligation of your own. Ask Contentsquare what export options your Hotjar plan includes, which formats they use and how long data stays available after the merge, because the answer decides what you can keep. Record the date from which OpenReplay data starts so reviewers know the gap.
Tracker snippet swap
Replace the Hotjar snippet with the OpenReplay tracker in the same template or tag location so both do not run on every page for long. Confirm the tracker version and project key your deployment generates, and check that single-page app route changes are captured. Test on a staging domain first, because the tracker sends data to your own ingest endpoint and a wrong host or project key produces silent gaps.
Masking rules and sanitization
Rebuild masking in OpenReplay rather than copying Hotjar settings. OpenReplay masks or skips data at capture time, including CSS selector masking and input redaction, and offers a private mode that masks all text and inputs by default. Write a list of every Hotjar suppression rule and every form, account or health field on your pages, then test each one in a recording before go-live. Masking that is only applied at playback does not protect stored data.
Funnels, dashboards and heatmaps
Hotjar dashboards and saved heatmap filters do not carry over, so recreate each one as an OpenReplay funnel, trend or heatmap. Start with the pages and funnels your product and compliance reviewers use weekly, and document the event definitions and URL patterns behind each one. Expect a period where numbers differ from Hotjar because the definitions are not identical, and agree on that difference with stakeholders in advance.
Tag manager and consent banner
If Hotjar loads through Google Tag Manager or a consent management platform, remove the Hotjar tag and add the OpenReplay tag under the same consent category, or have it fire only after the visitor has accepted the category it depends on. Session replay captures inputs and behavior, so treat it as a tracking purpose in your consent records. Check the tag sequence in a preview session and confirm the consent banner text matches what is actually recorded.
Surveys and feedback widgets
Hotjar's on-site surveys and feedback widgets are a separate function that OpenReplay does not replace, so decide where those responses will live before cancelling. Inventory each active survey, its targeting rules and the responses you still need, export them where Hotjar allows, and plan a replacement tool. Confirm with your team which survey data is subject to retention rules before any export is stored outside Contentsquare.
How the cutover sequence runs
The sequence moves Hotjar traffic to a self-hosted OpenReplay instance in controlled stages, so each stage produces evidence that the next one can rely on before Hotjar is switched off.
Inventory pages, events and existing Hotjar settings
List every site and page where Hotjar runs, the recordings, heatmaps and surveys each page uses, the custom events and the tracking snippet placement. Record which pages carry forms, account data or other sensitive content. Your analytics owner and a developer who knows the tag manager should sign off the list. Output: a page and event inventory with a sensitivity flag on each row, which becomes the input for every later step.
Size and install a first OpenReplay instance
Deploy one OpenReplay instance in your own cloud account or data center, using the deployment guide for your target (Docker, Kubernetes with Helm, or a supported cloud). The README describes a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage as enough to start, but treat that as a starting point and confirm it against your expected session volume and retention. Confirm the release you install against the current releases page. Output: a running instance with a test project, an admin account and a documented install record that names the version.
Configure masking rules and private mode
Write a masking rule register before the tracker goes live. For each page, list the CSS selectors to mask, the input fields to redact and the pages where private mode, which masks all text and inputs by default, should apply. Capture-time sanitization runs in the browser, so data that is masked or skipped never reaches your server, and that is the setting to verify. Have a security or privacy reviewer approve the register. Output: a signed-off masking rule register and a test session showing that masked fields are unreadable in playback.
Pilot on low-risk pages
Install the tracker on a small set of low-risk pages, such as marketing or documentation pages with no account data, and keep Hotjar running there as well. Check that sessions appear, that the masking rules hold on real traffic, and that performance and page load stay within your tolerance. Review sample recordings with the people who will use them. Output: a pilot report listing the pages tested, defects found, fixes made and an explicit decision on whether to widen the rollout.
Run both tools in parallel
Expand the OpenReplay tracker to the agreed set of pages while Hotjar continues to record. Rebuild the funnels, heatmap views and event tags that the team uses from Hotjar, and compare what each tool reports for the same pages over a period you agree in advance. Note the gaps: Hotjar's on-site surveys have no direct OpenReplay equivalent, so plan a separate survey tool for that need. Output: a parity log that lists each Hotjar report, its OpenReplay replacement and any accepted difference.
Cut over the tracker and set a go or no-go gate
Before switching, run a go or no-go checklist covering masking sign-off, parity log completion, retention and access settings, consent wording where your rules require it, and a rollback plan that restores the Hotjar snippet. Swap the tracking snippet in the tag manager or templates, page by page if possible, and keep the change log. Output: a signed checklist with the date of each page switch and a rollback record.
Decommission Hotjar and archive what you need
Once OpenReplay has run on all in-scope pages and the checklist is closed, remove the Hotjar snippet, cancel the subscription on your schedule, and document that past Hotjar recordings and heatmaps do not move into OpenReplay. Export any reports or survey responses you must keep under your own retention policy before access ends. Output: a decommissioning record listing removed snippets, exported archives and the retention position you adopted.
What drives cost and duration
This table lists the inputs that move the effort of a Hotjar to OpenReplay migration, why each one matters and how to keep it down. Use it to structure a written quote, since the scope of each row sets the fixed-scope price and timeline you will be asked to approve.
| Driver | Why it moves effort | How to keep it down, and what to ask for in a quote |
|---|---|---|
| Page count and traffic | Each template, funnel step and high-traffic page needs tracker coverage, and traffic volume sets the replay storage and server load you must size for. | Limit recording to the page groups you actually analyze. Ask the quote to state the page inventory it covers and the traffic assumptions used for VM and storage sizing. |
| Masked fields and inputs | OpenReplay masks by CSS selector, redacts inputs at capture time and offers a private mode. Every form, account area and personal data field needs a rule that is checked against real sessions. | Inventory forms first and default to private mode where unsure. Ask for the masking rule count, the test sessions used to verify masking and who signs off. |
| Consent flows and legal review | Consent banners, cookie categories and the wording of your privacy notice must match what the recorder captures. Changes here often need legal sign-off outside the engineering work. | Agree the consent model with counsel before tagging. Ask whether the quote includes consent configuration and whether legal review is your cost or the implementer's. |
| Funnels and heatmaps to rebuild | Hotjar heatmaps and funnels do not carry over, so each one is rebuilt from event definitions and page selectors. Heatmaps need enough sessions before they are useful. | Rank existing Hotjar views by how often they are used and rebuild only those first. Ask for the number of funnels and heatmaps in scope and the acceptance test for each. |
| Hosting choice | Self-hosting on your own cloud, data center or Kubernetes means the implementer configures networking, backups, upgrades and monitoring. A managed OpenReplay Dedicated or Bring-Your-Own-Cloud option shifts some of that work to the vendor. | Compare the self-hosted open-source edition with managed options before scoping. Ask the quote to name the deployment target, who operates upgrades and who holds the cloud account. |
| Storage and retention settings | Retention is self-managed in the open-source edition, so retention periods, storage growth and backup frequency are decisions you own and must document. | Set a written retention period up front. Ask for the storage and backup design, the retention configuration and the procedure for changing it later. |
| Internal review cycle | Each review round by privacy, security and product teams adds a cycle, and late changes to masking or events repeat testing. | Gather one consolidated sign-off list before testing starts. Ask for the number of review rounds included and the change process for work requested after sign-off. |
| Parallel running and cutover | Running Hotjar and OpenReplay together means two snippets, two consent states and two sets of reports to compare during the overlap. | Choose a fixed overlap window and a single cutover date. Ask the quote to state how overlap is handled and who removes the Hotjar snippet at the end. |
What usually goes wrong in a Hotjar to OpenReplay move
Most failed Hotjar to OpenReplay moves are not technical breakdowns. They come from privacy gaps, wrong expectations about history, undersized servers and license assumptions made early and never revisited. The six risks below are the ones to check before the new tracker goes live on production pages.
Unmasked personal data in recordings
Session replay captures what the page shows, so form fields, account numbers, names and health details can end up in recordings if nobody configured masking. OpenReplay sanitizes data at capture time, using CSS selector masking and input redaction, and offers a private mode that masks all text and inputs by default. Before launch, test the private mode on your highest-risk pages, then replay a few sessions and confirm nothing sensitive is visible. Treat masking rules as a release item, not a one-time setup.
Consent and privacy notice not updated
Moving from Hotjar to a self-hosted recorder changes the processor, the storage location and possibly the legal basis your site relies on. The privacy notice, cookie banner and records of processing may still describe the old tool. Ask your privacy team whether the new deployment needs a fresh assessment, and check how your consent platform will block the tracker until consent is given. Document the decision before go-live so the change can be explained to a regulator or auditor.
Expecting historical data to appear
Past Hotjar recordings and heatmaps do not move into OpenReplay, so teams that promise stakeholders continuous trend lines often find a gap on day one. Export whatever you need from Hotjar while your account still allows it, store it under your retention policy, and tell analysts that new heatmaps and funnels start from the first day of collection. Set a clear expectation for how long the overlap period lasts and when old comparisons will be retired.
VM sized too small for real traffic
The OpenReplay README describes a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage as enough to start self-hosting. That is a starting point for a pilot, not a sizing model for your production traffic. Replay storage grows with session volume and retention, so estimate sessions per day and retention days with your own analytics, then load test the server before rollout. Confirm with the vendor what growth path is recommended as traffic increases.
AGPL and ee license split misread
OpenReplay is mostly AGPLv3, some directories are MIT, and everything under the ee/ directory is under a separate commercial license. Teams that assume the whole repository is free often discover this during an audit or when they enable an enterprise feature such as SSO, SCIM or audit trail. Have legal review which directories you deploy, whether you modify and host the software for others, and which features sit behind the Enterprise edition. Record the answer in your open-source inventory.
Survey gap found late
Hotjar's on-site surveys and feedback widgets are not part of OpenReplay's session replay and product analytics scope. Teams often find out during cutover, when marketing asks where feedback responses will come from. Inventory every survey, poll and feedback form that runs on Hotjar before you commit, then decide whether a separate tool such as a self-hosted survey product will cover them, and how responses will connect to session data. Test that flow before removing Hotjar from any page.
How the move differs by team size and starting point
A single website or web app run by a small team usually has one tracker to install, a short list of pages that matter and one person who can make the call. The first VM is the main infrastructure decision. OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting, which fits a trial or a first production site with moderate traffic. Storage is the figure to watch, because recordings accumulate and retention is set by you.
- One tracker, one scope: Install the OpenReplay tracker on the site, then confirm that session recording, heatmaps and events arrive before you touch anything else.
- Small VM, watched disk: Start on the single-VM layout and set an alert on disk use so storage does not fill without warning.
- Mask before you record: Configure capture-time masking and private mode on the first day, since the team has no second reviewer to catch exposed fields later.
- Own the upgrades: Community support is the default on the open-source edition, so assign someone to read release notes and apply updates.
- Keep Hotjar running briefly: Run both tools for a short overlap so you can compare heatmaps before Hotjar access ends.
Check with OpenReplay whether your traffic and retention settings fit a single VM before you commit to that layout.
An estate with several domains, brands or product lines multiplies the work. Each site has its own pages, forms, consent banner and masking needs, and a change in one place can break recordings elsewhere. The decisions move from a single team's judgment to a shared standard, usually owned by a platform or digital team with input from each brand. Hosting also becomes a shared service that several business owners depend on.
- Shared masking standard: Agree on one set of CSS selectors and input rules for forms, payment fields and personal data, then apply it to every site before recording starts.
- Per-site projects: Map each domain to its own project and tracker so heatmaps and funnels stay separated by brand.
- Capacity planning: Size the server for combined traffic and retention, not the busiest single site. Ask OpenReplay and your own engineers to confirm how the deployment scales as sites are added.
- Approval path: Decide who signs off on a new site, a new masking rule and a change to retention, because each one affects every brand.
- Rebuild funnels per brand: Recreate funnels and heatmaps in each project, since Hotjar history does not carry over to any of them.
Confirm with your legal team whether consent banners and privacy notices differ by brand before you deploy a single tracker.
A bank, healthcare provider, public body or other regulated organization usually needs to know exactly where session data sits, who can access it and how it is deleted. Self-hosting OpenReplay keeps session data in the operator's own infrastructure, which is the main reason this path is chosen. The work shifts from configuration to documented controls: hosting location, access, encryption, backups, logging and change management. DeployOpen can plan and implement this deployment in your cloud account or data center, but compliance assessments are run by your independent auditors.
- Account and region choice: Deploy in your own cloud account or data center, and record the region and network path that session data uses.
- Access and identity: Ask whether SSO, SAML and role controls are available in the edition you choose, since the pricing page places them in the self-hosted Enterprise edition.
- Ee license review: Have counsel check the AGPLv3 and ee/ license split before deployment, because the commercially licensed directory has different terms.
- Masking evidence: Keep records of masking rules and private mode settings as controls, so an assessor can see how sensitive fields are handled.
- Retention and deletion: Write down how long recordings are kept and how deletion is performed, and test that deletion works.
Confirm these points with your security, legal and compliance owners and your independent auditor before you treat the design as final.
How OpenReplay's self-hosted deployment fits your environment
OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting, and that is the right baseline for a pilot on the Hotjar migration, not a production sizing. Session replay is storage-heavy and grows with every recorded session, so the 50 GB figure will fill faster than most teams expect. Before you pick the VM, ask your OpenReplay contact or the project documentation to confirm sizing for your monthly session volume, the share of sessions you will record, and the retention period you plan to set. Those three inputs decide disk growth, and they are the numbers your finance and security reviewers will ask for. The README lists deployment targets including AWS, Google Cloud, Azure, DigitalOcean, Scaleway, OVHcloud, Kubernetes with Helm, Docker and Ubuntu. Choose the target that matches where your data is already allowed to live, not the one that is cheapest to try. Because self-hosting keeps session data in your own infrastructure, the recordings never pass through a vendor-hosted analytics backend, which matters for the consent and data transfer questions covered elsewhere on this page. Confirm the region and the account that will own the VM, and make sure backups and snapshots of the storage volume sit inside the same boundary. The README also notes that first-party tracking served from your own domain is not blocked by ad blockers, so the tracker's traffic looks like the rest of your site. Plan the subdomain or path you will use for ingestion and check it with your web team before the tracker goes live. If you need SSO and SAML, provisioning through SCIM, roles and permissions, or an audit trail, those sit in the ee directory under a separate commercial license, so ask for the Enterprise terms in writing before you assume them in the design.
Questions buyers ask before migrating from Hotjar to OpenReplay
Can we move our historical Hotjar recordings and heatmaps into OpenReplay?
No, plan on past Hotjar recordings and heatmaps staying in Hotjar or Contentsquare. OpenReplay records new sessions from the point the tracker is installed, so the history you keep is whatever you export or archive before your Hotjar access ends. Ask Hotjar or Contentsquare what export options your plan includes and what happens to data after your contract ends. Your rebuilt heatmaps and funnels will start from zero, so decide early which reports your stakeholders need to compare against the old baseline.
How much effort does a Hotjar to OpenReplay migration take?
Effort depends on the number of sites and apps, how many masking rules you must rebuild, how many funnels and heatmap pages you track, and whether you run mobile apps alongside the web. The main work items are provisioning the server, installing the tracker, configuring capture-time sanitization by CSS selector and input redaction, enabling private mode where needed, and rebuilding funnels and heatmap views in OpenReplay's product analytics. Ask any implementation partner for a written scope that lists each site, each masking rule and each report, since those items drive the quote.
How long does the migration take and what sets the timeline?
The timeline is set by the number of environments, your change approval process, the masking review and how long you run Hotjar and OpenReplay side by side. The OpenReplay README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting, so server provisioning is rarely the constraint. Privacy and security review of masking, retention and the data location usually takes the longest. Confirm the schedule with your team and any implementation partner in writing before work starts.
What does our team need to provide during the migration?
You need to supply access to the cloud account or infrastructure where OpenReplay will run, a named owner for the tracker deployment on your websites and apps, and a privacy or legal reviewer who signs off on what is masked. Your analytics or product team should list the funnels, heatmap pages and replay filters they use today so they can be rebuilt. Expect your frontend engineers to review the tracker snippet, and your security team to review retention and access. Confirm these roles and their time commitment before scoping.
Can our own engineers migrate to OpenReplay without outside help?
Yes, a capable platform team can install OpenReplay from the deployment documentation and adopt the tracker themselves. The harder parts are validating capture-time masking on every page that holds personal data, setting retention and access rules, backing up the database and object storage, and keeping the stack upgraded. Review the deployment documentation and check whether your team has time to own those controls after go-live. A fixed-scope implementation or a support retainer can cover these tasks if your team lacks capacity.
What do OpenReplay's license terms mean for a self-hosted deployment?
Most of the OpenReplay monorepo is licensed under AGPLv3, some directories are MIT, and everything under the ee/ directory is under a separate commercial license defined in ee/LICENSE. The open-source edition is listed as free to self-host with community support and self-managed retention. Features such as SSO and SAML, SCIM provisioning, roles and permissions, audit trail, a custom SLA and dedicated support sit in the self-hosted Enterprise edition, which is priced on request. Have your legal team confirm which features you need and whether the AGPL obligations fit your internal use.
Does OpenReplay replace Hotjar surveys?
No, OpenReplay's documented feature set covers session replay, DevTools, product analytics with funnels, trends, journeys and heatmaps, cobrowsing and mobile replay, but it does not list on-site surveys. If you rely on Hotjar surveys or feedback widgets, plan a separate tool for that job and confirm the current feature list with OpenReplay before you decide. Keep the survey requirement in your scope so it is not lost during cutover.
How does self-hosting affect data protection and consent obligations?
Self-hosting keeps session data in your own infrastructure, which gives you control over where recordings are stored and who can access them. The OpenReplay README notes that first-party tracking from your own domain is not blocked by ad blockers, which changes your data flow compared with a third-party vendor. Whether you need consent for session recording depends on your jurisdiction and configuration, so confirm the position with your data protection officer or counsel before deployment.
How DeployOpen scopes and runs the migration
DeployOpen plans, implements, hardens, documents and supports self-hosted OpenReplay inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. The work covers the OpenReplay deployment itself, the tracker rollout across your sites, capture-time sanitization and masking rules, private mode settings, and the funnels and heatmap views your product and analytics teams need after cutover. Every engagement starts with the question of where OpenReplay will run, who operates it, and which Hotjar recordings and surveys your stakeholders still need to reference, because those answers set the size of the first VM and the scope of the rebuild.
Most engagements are fixed-scope, with the scope, deliverables and timelines written down and agreed before any work begins. For this migration, a written scope should name the hosting target, the sites and single-page applications that get the tracker, the masking rules to be tested, the funnels and heatmaps to rebuild, the retention settings you choose, and the acceptance checks for each item. It should also state what is out of scope, such as moving past Hotjar recordings, which cannot be exported into OpenReplay. Ask for those items explicitly in any quote so that the price follows from the document rather than from assumptions. Ongoing support, upgrades and continuous testing are available as retainers after the initial migration. This matters because OpenReplay ships new releases, and the ee directory has a separate commercial license that your legal team should review before you rely on enterprise features. Agree in writing before work starts which upgrade and support responsibilities sit with DeployOpen and which stay with your team. To begin, send your scoping questions on hosting, tracker coverage and masking requirements, and we will return a written scope for your review.
