How to migrate from Google Analytics 4 without losing your history

The technical part of leaving Google Analytics takes about twenty minutes. What stops people is the twelve months of history sitting in a property they would have to abandon, and the fear that the new numbers will be unexplainable.

Both are solvable, in this order.

Step 1: export the history first

Do this before anything else. Once a GA4 property is deleted the data is gone, and the export takes ten minutes.

In GA4, open Reports → Engagement → Pages and screens, set the date range to the full period you want to keep, and export as CSV. Repeat for the reports whose dimensions you care about:

• Pages and screens — pageviews per path per day
• Traffic acquisition — sessions by source and medium
• Demographic details — users by country
• Tech details — users by device category and browser

The critical detail: include Date as a dimension. A CSV of totals without dates is a single number, not a history, and cannot be merged into a daily chart. In the report's customisation panel, add Date as the primary dimension and your dimension of interest as the secondary.

For larger properties, the GA4 Data API or the free BigQuery export produce the same data without the interface's row limits.

Step 2: install the new tracker alongside the old one

Do not remove the GA4 tag yet. Run both for a week or two. This is the only way to build an intuition for the difference between the two sets of numbers, and it costs nothing.

A cookieless tracker is normally a single script tag with no configuration:

<script defer src="https://your-domain.example/gp.js" data-site="your-site-key"></script>

If your site is a single-page application — React, Next.js, Vue, Astro, Svelte — check that the tracker hooks history.pushState rather than integrating with a specific router. Hooking the browser primitive means client-side navigation is counted with nothing to configure, whatever framework sits on top. Hash-based routing usually needs one extra attribute.

Step 3: expect the numbers to differ, and know why

They will not match, and a tool that claimed they did would be lying. The differences have specific causes, covered in detail separately, but in summary:

• Unique visitors: lower. A returning visitor counts once per day rather than being linked across weeks.
• Total pageviews: often higher. No consent banner means no unmeasured visitors, and ad blockers block a self-hosted first-party script far less reliably than they block Google's.
• Bot traffic: lower. Edge-level bot filtering typically removes traffic GA4 was counting as human. That is a correction, not a loss, and it is worth understanding what is being removed.
• Sessions: broadly comparable, since both group activity into visits with an inactivity timeout.

Write the parallel-running figures down. When someone asks in three months why the dashboard shows fewer users, the answer is a documented ratio rather than a shrug.

Step 4: import the history

Import the CSVs you exported in step 1. A good importer will:

• merge imported days into the same tables as live measurements, so a year-over-year chart spans the switch rather than starting from zero;
• skip days that already have data rather than overwriting them, and tell you how many before it writes anything;
• accept the dimension breakdowns separately, so page-level history and country-level history can be imported from different reports.

Check the joins after importing. The most common problem is a date format mismatch — GA4 exports dates as YYYYMMDD in some reports and YYYY-MM-DD in others, and an importer that silently accepts both without normalising produces two parallel histories that never meet.

Step 5: rebuild the things that were configured, not measured

Pageviews arrive automatically. Everything you configured in GA4 has to be recreated, and this is the step that gets forgotten:

Conversions. Every GA4 conversion event needs an equivalent. Note the events you fire from your own code — a signup, a checkout, a form submission — and wire them to goals in the new tool. If they carry revenue, pass the amount so it can be totalled. Getting the goal definitions right the first time matters more than it looks.

Filters and exclusions. Internal traffic exclusions, staging hostnames, and paths you never wanted counted.

Scheduled reports. Whoever received a weekly GA4 email should receive the equivalent, or they will assume analytics stopped working.

Dashboards and saved segments that colleagues rely on. If a marketing lead opens the same three saved views every Monday, recreate them before switching rather than after.

Step 6: turn off the old tag

After the parallel period, remove the GA4 tag — and remove it properly. A tag left loading through Google Tag Manager while the property is unused is the worst of both worlds: the visitor still gets the cookie, so you still need the banner, and nobody is reading the data.

Then, if consent was the reason for the move, remove the banner. Update the privacy page to describe what is actually measured now. That page should be a factual technical description you could hand to a regulator, not a template.

A migration checklist

1. Export GA4 history as CSV, with Date included, before touching anything.
2. Install the new tracker alongside GA4.
3. Run both for one to two weeks, and record the ratios.
4. Import the historical CSVs; verify the join at the boundary.
5. Recreate conversions, filters, scheduled reports and saved views.
6. Remove the GA4 tag, the container entry, and the consent banner.
7. Rewrite the privacy page to describe the new behaviour.

The whole thing is an afternoon. The only irreversible step is step one, which is why it comes first.