Plausible vs Umami

Yes, but with caveats. Umami supports CSV import for historical data, which means you export from GA4 (or use a tool like the open-source ga4-to-csv exporter), reshape the columns to match Umami's expected schema, and import. The depth you get back is limited: pageviews and basic events come across cleanly, but GA4's session and engagement metrics are calculated differently and will not survive the import as-is. Custom dimensions and audiences do not transfer at all. For a clean cutover most teams accept the loss and treat the GA4 export as an archive rather than a continuous history. If continuity matters more than tool choice, Plausible's official GA4 importer covers the same ground with slightly less friction.

Both are the upgraded tier and both are priced at $19 per month at 100k events. Plausible Business adds funnels, ecommerce revenue tracking, custom property breakdowns, team accounts with permissions, and the GSC integration. Umami Cloud Plus adds funnels, retention analysis, journey reports, and longer data retention. The features overlap on funnels but Plausible's plan leans toward marketing analytics with revenue and search data, while Umami's leans toward product analytics with user journeys and cohorts. If you mostly care about marketing channels and conversion, Plausible Business. If you mostly care about product behaviour and retention, Umami Cloud Plus.

For a single-team self-hoster running the analytics for your own sites, almost nothing. Both licenses let you install, modify, and run the software internally without obligation. The AGPL only kicks in when you offer the modified software to third parties as a network service. So if you fork Plausible, customise it, and run it for your own portfolio, you are fine. If you fork Plausible, customise it, and resell access to other customers, AGPL requires you to publish your modifications. MIT places no such obligation on Umami in any scenario. Practically: solo operators can ignore the difference, agencies offering white-labelled analytics to clients should think twice about the Plausible path.

The MIT license guarantees the open-source version cannot be retroactively closed. Whatever code is published today remains free under MIT in perpetuity, and any community fork inherits that freedom. The maintainer, Mike Cao, has been consistent for years that the self-hosted product will stay free, with monetisation coming through Umami Cloud rather than license fees. The realistic risk is not that the license changes, but that future development could focus on Cloud-exclusive features and the self-hosted edition lags behind. That is what happened to several other open-core analytics tools. So far Umami's commit history shows the open-source edition keeps pace, but it is worth watching.

A $5/month VPS with 1GB of RAM and one shared CPU core is enough to run Umami comfortably for a portfolio of a dozen low-to-medium-traffic sites. The Docker image plus a Postgres container fits in well under 512MB of RAM at idle. Disk usage is modest: a few hundred megabytes for the application, plus the database which grows roughly proportional to event volume. Plan on 1GB of database storage per million events as a rough rule. Hetzner CX11, DigitalOcean's basic droplet, Vultr's $2.50 tier, all work. The thing that will bite you is not CPU or RAM, it is forgetting to schedule database backups. Set up a daily pg_dump to S3 or B2 before you put real traffic through it.

Both tools export to CSV and both can import CSV, so technically you can move data between them. In practice the export schemas do not line up cleanly. Plausible exports aggregated data by default, which is fine for archive but lossy if you want raw events. Umami exports raw events but in a structure that needs reshaping before Plausible will accept it. The pragmatic playbook is: export your old tool's data as CSV and keep it as a static archive for compliance or curiosity, install the new tool with a clean slate, and run both in parallel for a week to validate the script is firing and numbers look sensible. Trying to merge histories across tools tends to create more confusion than insight.