Migrating to Matomo Analytics
Matomo is the destination for teams that need full feature parity with GA4 — heatmaps, multi-touch attribution, funnels with branching, custom segments, A/B testing — and are willing to accept either a self-host operational burden or a higher Cloud price tag in exchange. It is the only mainstream destination that does not remove features by design. This page is the cross-source map: where you are coming from determines which migration guide to follow, which auto-event mapper to use, and which reconciliation gotchas to expect. The destination is the same; the path is not. Read the source map first, then click into the matching pair page for the install.
From which source — pick your starting line
Five common origin points and their dedicated pair pages.
Coming from GA4
The flagship path. Matomo's GA Importer plugin handles BigQuery export ingestion, and auto-event mapping covers around 95 of 120 typical GA4 events — better than any other destination because Matomo's event model is closest to GA4's. Cookie-banner removal is optional via the cookieless mode flag.
GA4 → Matomo →Coming from Universal Analytics
UA was sunset 2024-07-01. Historical-data import route, not a live cutover. Pull your UA export from BigQuery, shape with the GA Importer plugin, and load. The live tracker step is a fresh install.
UA → Matomo (stub) →Coming from Mixpanel
A natural translation. Both tools are event-first, both have funnels, both treat user identity as a first-class field. Mixpanel distinct_id maps to Matomo userId; properties translate cleanly. The lossy bit is Mixpanel cohort definitions.
Coming from Adobe Analytics
The enterprise migration. eVars and props translate to Matomo custom dimensions; tag deployment moves from Adobe Launch to Matomo Tag Manager. The hard parts are Workspace report rebuilds and the Adobe ID-to-userId join.
Adobe → Matomo (stub) →Coming from Piwik PRO
The closest sibling — Piwik PRO and Matomo share an ancestor. Database schemas are similar, the JS tracker API is mostly compatible, and a config export hand-translates with under a day of effort. Usually a budget-driven move.
Piwik PRO → Matomo (stub) →If your source is none of those — Heap, Amplitude, Snowplow, Pendo — file an issue on GitHub. The pair page roster is built by request.
Matomo's structural choices
Four architectural commitments that shape what Matomo is and is not. None are roadmap items; they are how the product was built.
GPL, not AGPL. Matomo ships under GPLv3, which means you can self-host without the AGPL "must-publish-modifications-if-you-serve-users" obligation. For teams that want to fork the dashboard or write internal plugins without contributing them upstream, this is a meaningful difference from Plausible Community Edition (AGPL). Practically, it means a startup can host a forked Matomo for paying customers without exposing its fork. The license choice is deliberate; InnoCraft (the maintainer) wants enterprise self-host adoption.
MariaDB as the data store. Matomo runs on MySQL or MariaDB, not on a column-store. That is unusual for an analytics tool — Plausible runs ClickHouse, GA4 runs BigQuery, Umami runs MySQL or PostgreSQL. The trade-off is operational simplicity (every team already runs MySQL somewhere) against query performance at scale (Matomo gets slow above 5 M pageviews/month without aggressive archive cron tuning). The choice is biased toward teams that already operate MySQL and want one fewer database in their stack.
Plugin system as a first-class architecture. Heatmaps, A/B testing, session recording, advanced funnels, custom dimensions — all of these are plugins, not core features. Some are free (custom dimensions, basic funnels), some are paid (heatmaps €99/year, A/B testing €299/year, session recording €299/year). The plugin separation lets you turn off what you do not use and keeps the core small. It also means a feature comparison against GA4 depends on which plugins are activated; a vanilla install has roughly 60% of GA4's surface, and the full plugin suite has roughly 110%.
Feature parity over simplicity. Matomo will never be a "one screen, six tiles" dashboard. The product target is teams replacing GA4 without losing capabilities, not teams escaping GA4's complexity. If your weekly workflow on GA4 is "open the homepage report and look at pageviews" — Matomo is overbuilt for you, and Plausible or Fathom is the right destination. If your workflow is "open Workspace, build a custom segment, drill down to a multi-touch attribution path" — Matomo is the only mainstream open-source option that supports the workflow.
If those four commitments read as the right trade-offs to you, this is the right destination page. If even one feels like a deal-breaker, Plausible or Fathom are saner targets.
Self-hosted vs Matomo Cloud
The break-even point for self-host vs Cloud sits around 50 K visits/month, but the calculation is not pure dollars.
| Dimension | Matomo Cloud | Matomo Self-host |
|---|---|---|
| Cost at 50 K visits | €23/mo | €15/mo VPS, plugins extra |
| Cost at 500 K visits | €83/mo | €40/mo VPS + €99/yr heatmaps |
| EU residency | Frankfurt + Auckland | your choice of provider |
| Operational overhead | none | MariaDB + PHP + archive cron |
| Plugin compatibility | Cloud catalog only | full marketplace |
| Suitable above 5 M pageviews | yes (custom pricing) | needs DBA + archive tuning |
When self-host makes sense. Three cases. (1) You have a strict no-third-party-cloud policy. (2) You operate above 1 M visits/month where Cloud's price scales above the cost of running MariaDB on a €40 VPS. (3) You need a paid plugin from the marketplace that is not in the Cloud catalog (the Cloud SKU includes fewer plugins than the self-host marketplace). Self-host is also the right answer if you want to fork the dashboard or write a custom plugin.
When Cloud makes sense. Everyone else. The operational cost of running Matomo — the archive cron tuning, the MariaDB schema migrations during version bumps, the on-call when the box runs out of disk — is not visible in the €15/mo VPS line item. Add four hours per quarter for upgrades, four more for the inevitable cron bug, and Cloud comes out cheaper in total-cost terms below 1 M visits.
Migration between the two. Bidirectional and well-documented. Matomo Cloud → self-host is a database export plus a config import; self-host → Cloud is the reverse. There is no lock-in either way. Most teams that pick Cloud at start-up move to self-host at scale; the reverse path (self-host → Cloud) is rarer but supported.
Standard migration playbook to Matomo
The five steps generalize across source trackers; each pair page covers source-specific traps.
- Provision the destination. Decide Cloud vs self-host (see break-even above). For self-host, provision a VPS with MariaDB 10.6+ and PHP 8.2+; the install is a download-and-extract plus a web-based wizard. For Cloud, sign up and create a property. Either way, set the property timezone correctly the first time — changing it later means data migration.
- Install the GA Importer plugin (if coming from GA4 or UA). This is the canonical historical-data path. The plugin reads from a BigQuery export and writes into Matomo's MariaDB schema. It runs as a one-off batch job, not a continuous stream; reimport once the export is finalized.
- Install the JS tag in parallel with the source tracker. Matomo's tracker is
matomo.jsplus a small inline<script>that calls_paq.push(['trackPageView']). The dual-tag period is hands-off; do not touch the source tag, do not change consent banners, do not modify the tracker wrapper. - Run a two-week parallel period and reconcile daily. Cookieless inflation on Matomo's cookieless mode runs 5-12% above a banner-gated GA4 source. With the default cookie mode the gap is closer to ±2%. Use the methodology tolerance bands; pageviews ±2% green, sessions methodology-dependent, goals only after event-mapping is verified.
- Cut over. Remove the source tracker, archive its property, and tune the Matomo archive cron for your traffic pattern. The cron is the operational gotcha — by default it runs every hour, which is wrong for either low-traffic (pointless work) or high-traffic (queue backup) sites. Set the cron interval to match your dashboard refresh expectations, then forget about it for a year.
Engineering hours: 14-24 from a GA4 source on Cloud, plus an extra 6-10 hours for self-host provisioning. Calendar time: two weeks of parallel run regardless of starting point. The methodology page documents the tolerance bands; same numbers, every destination.