Migrating to Umami Analytics

Umami is the destination for developers, agencies, and license-conscious teams who want a self-host tracker on an MIT license, deployable on free-tier infrastructure in under an hour. Single-developer founded, MIT-licensed (not AGPL), runs on either MySQL or PostgreSQL, Docker-first packaging, and a Cloud option for teams that want to skip the deploy step. 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. 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 — Adobe, Heap, Amplitude, Snowplow — file an issue on GitHub. The pair page roster is built by request.

Umami's structural choices

Four architectural commitments that shape what Umami is and is not. None are roadmap items.

MIT license, not AGPL. The headline difference from Plausible Community Edition. MIT permits private modifications without a corresponding obligation to publish source. For agencies hosting analytics for paying clients, for startups embedding analytics in a closed-source SaaS product, for any team that wants to fork the dashboard internally without contributing the fork upstream, MIT is the meaningful permission. AGPL forks of Plausible CE are technically legal but operationally fragile; an MIT fork of Umami is straightforward.

MySQL or PostgreSQL — your choice. Umami runs on either, and the schema is Prisma-managed so the migrations work cleanly across both. That is unusual; most analytics tools pin one database (Plausible: ClickHouse + Postgres, Matomo: MariaDB only, GA4: BigQuery proprietary). The flexibility lets you co-locate Umami with whatever database your existing stack already uses. Practically, Postgres is the better choice for teams above 100 K visits/day because Umami's queries hit JSON columns hard and Postgres's JSONB indexing outperforms MySQL's at scale.

Docker-first packaging. The official deployment story is Docker + Docker Compose. Bare-metal Node.js installs are supported but not the primary path; the documentation, the upgrade scripts, and the community examples all assume Docker. For teams comfortable with Docker, this is a feature — pull the image, mount a volume, point at a database, done. For teams without Docker experience, it is a friction point that does not exist on Plausible (which has both a Docker and a non-Docker install path) or Matomo (which is PHP + LAMP-style).

Single-developer founded. Umami was started by Mike Cao (one developer) and remains heavily Mike-led with a small contributor base. That is a meaningful trust signal in both directions: the codebase is opinionated and consistent (one architect's decisions throughout), and the bus factor is low (one critical contributor). The maintenance pace is steady but not enterprise-aggressive; a tracker bug filed Tuesday is unlikely to ship a fix on Wednesday. For most teams that is fine; for teams with strict SLA requirements, Cloud-vendor-backed alternatives (Matomo Cloud, Plausible Cloud, Fathom) are safer.

If those four commitments fit your team's priorities, this is the right destination. If MIT license vs AGPL is not load-bearing for you, Plausible is the closer match in product surface; if you need feature parity with GA4, Matomo is the right destination.

Self-host on free Vercel + Neon vs hosted Umami Cloud

Umami's break-even economics are different from Plausible's or Matomo's because the free-tier self-host story is genuinely free.

Free Vercel + Neon is genuinely viable. Umami runs as a Next.js app, which deploys to Vercel's free tier under a hobby project. Neon provides a serverless Postgres free tier with 0.5 GB storage and 100 hours of compute. For a personal site or a small SaaS landing page, the combined free tier covers ~50 K visits/month with zero spend. Above that volume, you trip Vercel's build-minutes cap or Neon's storage cap and need to upgrade. The "$0 forever" path requires staying small; the "$0 to $20" upgrade path is smooth.

Self-host on a €5 VPS beats free-tier above 50 K visits. A Hetzner CX11 (€5/mo) running Docker Compose with PostgreSQL on the same box handles 500 K visits/month with headroom. The operational overhead is one Docker image upgrade per quarter and one Postgres minor-version bump per year. Below 50 K visits, the free-tier path is cheaper; above 100 K, the €5 VPS is the right choice for cost-conscious teams.

Umami Cloud Starter at $9/mo is the same price as Plausible Cloud Starter and slightly cheaper than Matomo Cloud Essentials. The Cloud SKU is the right answer for teams that do not want to manage infrastructure and are above the free-tier volume threshold. The Cloud feature set matches self-host one-to-one — there is no Cloud-only feature gating, unlike Matomo where heatmaps are paywalled separately.

When self-host wins. Three cases. (1) Volume sits above 50 K visits, ruling out the free tier. (2) You have an existing Postgres or MySQL instance you want to co-locate Umami with. (3) MIT license matters because you are forking the dashboard or embedding Umami in a closed-source product.

When Cloud wins. Everyone else. The €5 VPS plus Docker plus quarterly Postgres upkeep is technically cheaper than $9/mo Cloud, but only by $4/mo and only if you do not value your time at more than $5/hour.

Standard migration playbook to Umami

The five steps generalize across source trackers; pair pages cover source-specific traps.

1. Provision the destination. Decide free-tier vs €5 VPS vs Cloud. For free-tier, deploy to Vercel from the official GitHub template and connect a Neon Postgres database; the wizard takes 15 minutes. For self-host, run docker compose up -d from the official compose file with environment variables pointing at your database. For Cloud, sign up and create a property. Set the property timezone correctly the first time.
2. Run the SQL importer for historical data (if needed). Umami's historical importer is less polished than Plausible's or Matomo's; it is a custom SQL script that reads from your source export (GA4 BigQuery CSV, UA archive, Plausible API export) and writes into Umami's event table. Expect to spend an hour debugging the script for any non-trivial source. The community has importer scripts on GitHub for the common sources.
3. Install the JS tag in parallel with the source tracker. One line: <script defer src="https://your-umami-host/script.js" data-website-id="YOUR-WEBSITE-ID"></script>. The website ID is generated when you create the property. The defer is non-negotiable. Custom event API: umami.track('Event Name', { property: value }).
4. Run a two-week parallel period and reconcile daily. Cookieless inflation on Umami runs 5-12% above bannered GA4 sources, same as Plausible and Fathom. Use the methodology tolerance bands: pageviews ±2% green, sessions methodology-dependent (Umami uses a 30-minute idle window), goals only after event-mapping is verified.
5. Cut over. Remove the source tracker, archive its property. Umami self-host has no per-event billing, so there is no surprise overage; Cloud bills monthly with no annual prepay discount (yet — single-developer pricing simplicity). Plan a single deploy, Wednesday morning.

Engineering hours: 8-14 from a GA4 source on Cloud, plus 2-4 hours for free-tier deploy or 6-8 hours for self-host provisioning. Calendar time: two weeks of parallel run regardless of starting point. The methodology page documents the tolerance bands.

FAQ