Umami vs Google Analytics: what you lose when you leave GA4

If you're comparing Umami vs Google Analytics, check two things: what GA4 does that Umami doesn't, and what happens to your history. If you're still choosing a tool, see Umami vs Plausible, self-hosted and Plausible pricing at your traffic. This guide covers the move itself.

In April 2024, a developer moving to Umami from Mixpanel asked the project for a way to import his old data. Umami's maintainer answered that self-hosted Umami has no import feature, because an import is database specific and a self-hoster already has full access to the database. The developer wrote his own. It took him about 6 hours to map his data to Umami's format. Loading it took a couple more.

What stays in GA4 after you stop using it

GA4's data retention setting keeps event data in a standard property for 2 or 14 months, and longer periods are only for paid GA4 360 properties. The same help page says that the setting does not affect standard aggregated reports and only limits explorations and funnel reports. So the traffic, pages, sources and conversions in your standard reports aren't cut by that clock. Google Ads figures are the exception, because GA4 shows them for a rolling 36 months.

Explorations keep age, gender and interest data for 2 months whatever you set. Large and XL properties are held to 2 months of event-level data.

Why your history can't come with you

Umami Cloud does import data, starting on the Pro plan. Umami's staff run it after you email support, and the sources they list are self-hosted Umami databases and CSV exports. GA4 isn't named, so ask them before you count on it. Self-hosted Umami has nothing like it. Even moving Umami's own Cloud data onto a self-hosted server takes a script you write, the maintainer said in January 2025.

Umami's collection endpoint accepts a timestamp, which looks like a way in. The field was added to import historical access logs. GA4's standard reports and their downloads hold totals, such as sessions per day. Turning one day's session count into that many fake hits would invent the visitors, visits and bounce rate Umami calculates from each session, and the maintainer has said session data is the tricky part of an API import. We don't recommend it, because the charts fill in but the visitor counts for those months aren't real.

GA4's BigQuery event export is the exception. If you linked it months ago, its daily tables hold your raw events, and a developer who knows SQL can write a script that loads them into Umami's database. That only reaches back to the day you linked BigQuery, and it's a project to plan and test before you trust the numbers.

What you give up, and what Umami covers

The first two columns come from Google's and Umami's docs and Umami's GitHub, listed in the sources below and checked by October 15, 2026. Where Umami's docs don't mention a feature, the row says it has none. The Search Console row follows a pull request Umami closed in October 2026. If you run Google Ads, weigh the Ads row most, since Umami has nothing in its place.

Where your GA4 history can go

For most sites the report download is enough. BigQuery suits you if you want tables you can query long after the GA4 property goes quiet, and you're fine with a BigQuery bill for storing and querying them.

Move to Umami step by step

We didn't move a real GA4 property for this guide, since we put no Google account into our tests. Where a step depends on Google's or Umami's docs, it links the page, as checked on October 15, 2026, so you can confirm the details before you change anything.

We did run Umami itself, in our own test on Oct 21, 2026, on a 2 vCPU, 4 GB test machine (arm64), not a DreamHost server. Umami 3.4.0 counted all 30,000 test pageviews we sent to its tracking endpoint. The dashboard summary for those 30,000 rows came back in 0.03 seconds. The database grew about 1 KB per pageview, so a personal site with tens of thousands of pageviews a month adds well under 1 GB a year. These were synthetic events sent in a few minutes, and months of real traffic will look different.

1. List what you use in GA4 and raise its retention

   Write down the reports you open each month, your key events, the UTM campaigns you tag, and whether Google Ads or Search Console is linked. Then open Admin, go to Data Settings > Data Retention, and set event data retention to 14 months if it's on 2. Google applies a longer setting to data it hasn't deleted yet, so your explorations reach further back while you export. The change takes effect after 24 hours, and you need the Editor role to make it.

2. Export the reports you'll want

   Export each GA4 report you rely on as a CSV file or to Google Sheets. Our suggested starter set is Pages and screens, Landing page and Traffic acquisition, each with the date range set to the life of the property, plus the key events from your list. A file holds up to 100,000 rows. If a report has more rows than that, split its date range across several files. Rebuild and export anything you made in Explorations first, since that's the part the retention setting cuts.

3. Copy more history into BigQuery, if you need it

   Run BigQuery's GA4 connector in a BigQuery project with billing turned on. Skip the free BigQuery sandbox. It doesn't run transfers, and it deletes its tables after 60 days. If you'd also like raw events going forward, set up BigQuery export now. A Google developer forum answer confirms it doesn't backfill.

4. Start your Umami server and update it

   A DreamHost VPS with Umami comes with Umami 3.2.0, PostgreSQL 15 and Caddy installed, and it requests a Let's Encrypt certificate at first boot. Connect to your server over SSH and print your admin login:

   bashCopy

   sudo cat /root/.umami_credentials

   Sign in, change the password and add a website. Update to the latest release before you go live. The installed 3.2.0 predates Umami 3.3.0, which added two-factor login, and 3.4.0, which added notes on the chart. Run umami-backup first, then umami-update, which pulls the newest version and warns that a database migration may be one-way.

5. Add the Umami script next to GA4

   Paste Umami's tracking script into your site's <head>, beside the GA4 tag. If your tags live in Google Tag Manager, add Umami with a Custom HTML tag, because Tag Manager strips the script's data attributes.

6. Rebuild your key events as Umami goals

   Umami counts a click as an event only when you tell it to track it. Add a data attribute to each button or link from your list, with an event name of 50 characters or fewer. Then create a goal for each event or page that counts as a conversion. Visits with UTM tags show up in the UTM report with no extra setup.

7. Run both for a month and compare trends

   Leave both tags running for a full calendar month, then compare your top pages, top referrers and which way traffic moved each week. The totals won't agree, and a month is our suggestion. Umami's visitor count uses a salt that resets at the start of every month, so a calendar month gives you one complete visitor count to set beside GA4's.

8. Remove the GA4 tag and keep the property

   Write down the date you switched and add it as a note on the chart, then take the GA4 tag off your site and leave the property where it is. Then set up a regular copy of each umami-backup file to somewhere off the server, since the script saves it to the server's own disk.

Leaving GA4 for Umami FAQs