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.

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, A/B testing, and session recording are now priced per user, starting from around €219/year for up to 4 users on self-host). 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 covers most of GA4's standard reporting, and the full plugin suite goes beyond it.

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 in the 50–100 K visits/month range, but the calculation is not pure dollars.

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 300 K visits for most teams.

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.

1. 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.
2. 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.
3. Install the JS tag in parallel with the source tracker. Matomo's tracker is matomo.js plus 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.
4. Run a two-week parallel period and reconcile daily. Cookieless inflation on Matomo's cookieless mode typically runs in the 5–12% range above a banner-gated GA4 source (observed estimate — varies by banner acceptance rate). 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.
5. 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.

Who should look at a different destination

Matomo is the right tool for teams that need GA4 feature parity without GA4. That is a specific profile. If you need less than that profile, Matomo is overbuilt and you will pay in operational overhead for features you do not use.

The decision rule I give to most teams: if your GA4 workflow includes Workspace, custom segments, funnel analysis, or multi-touch attribution more than once a week, Matomo is worth the operational overhead. If your workflow is mainly the Traffic and Acquisition overview reports, Plausible or Fathom will save you that overhead and cost less. The Migration Effort Estimator quantifies the setup delta; the Matomo path typically runs 14–24 engineer-hours, versus 6–10 for Plausible.

FAQ