What should a team validate first when ua→ga4 migration: lessons from 1,000+ migrations appears?

Reproduce the problem in the live implementation, isolate whether it is scoped to one report or flow, and compare it against at least one secondary source before changing the setup.

How do I know whether the fix actually worked?

You need before-and-after evidence in the browser and in the downstream report. A clean-looking dashboard without validation is not enough.

When should this become a full GA4 audit instead of a quick fix?

If the issue touches attribution, consent, revenue, campaign quality, or data trust for more than one workflow, it is usually safer to audit the surrounding implementation than patch only the visible symptom.

UA→GA4 Migration: Lessons from 1,000+ Migrations (2026)

What's the right way to migrate from UA to GA4?

The UA→GA4 migration that produces clean post-migration data follows eight patterns: (1) preserve UA historical data via export to BigQuery before sunset (Universal Analytics access ended 1 July 2024 with read-only access removed July 2024 — historical data is gone if not exported), (2) map UA goals to GA4 key events one-to-one, not "dump every interaction as a key event", (3) re-think the data model — GA4 events replace UA hits, not 1:1 mapping, (4) audit custom dimensions before migration (UA had 200; GA4 has 50 event-scoped + 25 user-scoped + 10 item-scoped on standard tier), (5) use BigQuery as the historical bridge for year-over-year reporting that spans the migration cutover, (6) run dual-tracking for at least 60 days before fully decommissioning UA dependencies, (7) communicate metric-name changes proactively (sessions ≠ sessions, bounce rate is gone, pageviews → views, etc.), and (8) audit the migration result after 30 days because 60% of "completed" migrations have undiscovered gaps. Most properties migrated in 2023-2024; most are still discovering gaps in 2026.

Why this still matters in 2026

UA officially sunset 1 July 2023; properties had until 1 July 2024 to access historical data. By 2026 the migration deadline is far in the past. So why a migration post?

Three reasons:

60% of completed migrations have undiscovered gaps. The migration finished mechanically but the data quality wasn't validated. Audits in 2026 still uncover unmigrated goals, mismatched conversion definitions, and reports that quietly stopped working.
Some organisations only just started. Smaller companies, internal tools, regional brands — properties that weren't on the priority list two years ago are migrating now.
Re-migration is real. Properties that did a "minimum viable migration" in 2023-2024 are now redoing it properly. The lessons apply both ways.

The eight migration patterns

Pattern 1 — Historical data preservation

Universal Analytics is gone. UA properties became read-only on 1 July 2023 and were fully decommissioned 1 July 2024. Historical UA data that wasn't exported by then is permanently inaccessible.

If you missed the export window, your only options are:

Pre-migration screenshots and PDFs
Aggregate data manually exported to spreadsheets
BigQuery export (if UA was linked, which most weren't)

The 2026 migration playbook for any new GA4 setup: enable BigQuery export day one. Even if you don't need it now, the lesson from UA's sunset is that "we'll migrate the data later" became "the data is gone."

Pattern 2 — Goal to key event mapping

UA had Goals (a small number of strategic conversions) and Events (lots of interaction tracking). GA4 has Events for everything, and you mark some as Key Events.

The migration mistake: marking every UA event as a GA4 key event. Result: Smart Bidding sees 50 "conversions" per session, optimises for the wrong things, performance degrades.

The right pattern: map UA Goals to GA4 Key Events one-to-one. Keep the strategic-conversion bar high. UA Events become regular GA4 Events (not Key Events) unless they were genuine strategic conversions in UA too.

Pattern 3 — The data model shift

UA's hit-based model: every interaction is a Hit (Pageview, Event, Transaction, Social, Timing). Each hit had a fixed structure.

GA4's event-based model: everything is an Event with parameters. Pageview is event_name='page_view'. Transaction is event_name='purchase'. Custom interaction is whatever you name it.

The migration mistake: trying to recreate UA's structure 1:1 in GA4. Forcing pageview-event-transaction distinctions where GA4 wants flexibility.

The right pattern: re-design the data model around GA4's event semantics. What strategic events matter to your business? What parameters do you need on each? Build that schema fresh, don't port UA's structure.

Pattern 4 — Custom dimensions audit

UA had 200 custom dimensions per property. GA4 has 50 event-scoped + 25 user-scoped + 10 item-scoped on standard tier (double on 360).

Want to see whether attribution loss is already distorting your channel data?

Audit attribution

If your UA had 80+ custom dimensions in active use, you can't fit them all in GA4. Pre-migration discipline: audit which dimensions are actually used in reports (most properties have 30-50% of UA custom dimensions registered but never queried in reports). Drop unused ones from the migration.

Pattern 5 — BigQuery as historical bridge

For year-over-year reporting that spans the UA→GA4 cutover, GA4 alone can't help you. The 2025 to 2024 comparison requires both UA historical data and GA4 current data, joined.

The pattern: pre-migration, export UA data to BigQuery (UA historical export was free during sunset). Post-migration, GA4 BigQuery export runs continuously. In your reporting layer (Looker Studio), join the two tables on date and produce continuous time-series.

The catch: UA and GA4 don't have identical schemas or metrics. Comparison reports need normalisation logic. Sessions in UA ≠ sessions in GA4. Pageviews in UA ≈ views in GA4 but with different counting rules.

Pattern 6 — Dual-tracking validation period

The migration shouldn't be "deploy GA4 and turn off UA same day." The pattern that works:

Deploy GA4 in parallel with UA (both running).
Run dual for 60-90 days.
Compare daily metrics: sessions, users, conversions, revenue.
Investigate any persistent variance >5% between the two.
Validate goal/key event firing matches.
Decommission UA only after GA4 numbers are trustworthy.

Most "minimum viable migrations" skipped this step. They deployed GA4, declared victory, decommissioned UA, and discovered weeks later that critical conversions weren't firing in GA4 — at which point UA's historical context for diagnosis was gone.

Pattern 7 — Metric name communication

UA terms that don't exist in GA4 or have changed semantics:

Bounce rate is gone. GA4 has Engagement rate (the inverse, but with different definition).
Pageviews → views.
Sessions still exists but counts differently (30-min inactivity vs UA's 30-min + new day rules).
Average session duration is replaced by Average engagement time.
Time on page is replaced by engagement time per event.
Goals → Key events.
Hits → Events.

Stakeholder reporting needs translation. "Why did our bounce rate change?" — there's no bounce rate. "Sessions are down 20%" — no, the counting changed. Communicate proactively before the rebrand.

Pattern 8 — Post-migration audit

30 days after migration completion, run a structured audit:

Event-level: every UA event has a corresponding GA4 event with similar volume (within 10%)?
Goal-level: every UA goal maps to a GA4 key event with similar volume?
Dimension-level: custom dimensions populated correctly with non-empty values?
Channel-level: channel attribution matches UA's pattern (within natural drift from algorithm changes)?
Revenue reconciliation: GA4 revenue matches finance system within 5%?
Report inventory: every UA report has a GA4 equivalent OR has been formally retired?

Items failing any check require a follow-up engagement. This audit takes 4-8 hours; it catches the gaps the original migration missed.

What 2026 audits keep finding

The four most common 2026-discovered migration gaps:

Gap 1 — Refunds not tracked in GA4. UA didn't have native refund tracking either, so it didn't migrate. Properties have been running 2 years with gross-of-refunds revenue in GA4. See *Refund Tracking in GA4*.

Gap 2 — Custom channel groups not rebuilt. UA had channel groupings configured one way; GA4 defaulted to standard channels. Customisations that classified specific affiliates or partner traffic correctly in UA are missing in GA4. AI traffic in particular is misclassified.

Gap 3 — Cross-domain tracking misconfigured. UA's cross-domain setup didn't translate cleanly to GA4. Multi-domain properties have session attribution issues that were fine in UA.

Gap 4 — Filter views not replicated. UA had View-level filters (exclude internal traffic, exclude specific URL patterns). GA4 has fewer equivalent constructs. Filters that were applied at the UA View level may be missing in GA4.