Lesson 6 of 9

Common Migration Traps

Most migrations don't fail loudly, they fail in the next report. These are the traps that survive a clean-looking Preview and only show up in the numbers a week later.

Double-counting

Old hard-coded tag left live alongside the GTM one.
Vendor tag fired on both a built-in trigger and All Pages.
Browser pixel + server-side hit with no shared event_id.

Silent data loss

Conversion Linker forgotten, so gclid/attribution drops.
A tag that relied on inline page data nobody re-mapped.
Consent gating set stricter than before, holding tags.

The usual suspects, in order of how often they bite

The missing Conversion Linker. The old gtag snippet handled it implicitly; in GTM it's a separate tag. Skip it and Google/Microsoft conversions under-report for weeks before anyone notices.
Hard-coded IDs hiding in odd places. Conversion snippets baked into transactional emails, a thank-you page, or an A/B-test tool keep firing after you've "removed" the tags from the theme. Grep everything, including templates outside the main codebase.
Consent timing. If Consent Mode now starts denied but the old setup fired unconditionally, your migrated numbers will legitimately drop. That's correct behaviour, not a bug, decide whether the old numbers were ever compliant.
UA muscle memory. Migrating a Universal Analytics setup 1:1 into GA4 doesn't work, the event model is different. Map to GA4 events, don't transliterate.
"While we're in here" scope creep. Improving tracking during the cutover means you can't tell a migration bug from an intended change. Match first, improve in a later version.

Key takeaway

After cutover, the data corrupts quietly: a forgotten Conversion Linker, a hard-coded snippet in an email, or a UA-shaped GA4 build. Match the old behaviour exactly first, then reconcile the numbers before you change anything else.