Analytics Continuity in a Migration: GA4, GTM and Conversion Tracking

How do you keep analytics working after a website migration?

You keep analytics working by moving your existing tracking setup to the new site, not rebuilding it from memory. Same GA4 property, same Google Tag Manager container, same key event names, with triggers updated wherever the new site's URLs or markup changed.

Analytics breaks in migrations for a simple reason: tracking is wired to details that change. A conversion that fires when someone reaches /thank-you stops firing when the page becomes /thanks. A click trigger tied to a button's CSS class stops working when the new build uses different classes. Nothing errors; the numbers just drop.

This checklist stays inside migration scope: what to record before, what to reinstall, and what to verify on launch day. It's one part of the wider plan in our guide to CMS content migration. For building tracking from scratch, see conversion tracking for lead-gen websites.

What does an analytics migration on a new website involve?

An analytics migration involves three jobs: documenting the current tracking, reinstalling it on the new platform, and proving it reports the same things. Most of the risk sits in the first job, because nobody can reinstall what they didn't write down.

Export the GTM container as a backup before you change anything. It's a JSON file you can re-import if an edit goes wrong.

What should you do before the migration?

Before the migration, write down every key event, how it fires and what it's worth, and capture a baseline of normal numbers. The baseline is what you'll compare against when you check launch-day data.

1. List every tag in GTM and every script hard-coded in the old site's templates and custom code settings.
2. For each key event, note the trigger: page URL, click selector, form submission or custom event.
3. Mark triggers that depend on things the new build will change: paths, classes, element IDs or form names.
4. Record a baseline of daily sessions, key events and conversion rate for the last few weeks.
5. Agree on one owner for tracking during launch week, so fixes don't wait on a hand-off.

Where you can, switch fragile triggers to sturdier ones before launch. A custom event pushed to the data layer when a form succeeds survives a redesign better than a click on a class name. This matters most for forms; our guide to migrating website forms covers the rest of that job.

How do you reinstall GA4 and GTM on the new platform?

Install the same GTM container on every page of the new site, then let GTM load GA4, rather than hard-coding GA4 separately. One loader, one source of truth.

• Webflow. Add the GTM snippets in site-wide custom code settings, in the head and body sections.
• Framer. Add the snippets in the site's custom code settings, which apply to every page.
• Next.js. Load GTM in the root layout so every route includes it, and make sure client-side route changes are tracked as page views.
• Any platform. Remove old hard-coded GA4 tags that would double-count alongside GTM.

Then update the triggers you marked earlier. Change URL conditions to the new paths, replace class-based click triggers, and point form triggers at the new forms. Publish the GTM changes in a new version with a clear name, so you can roll back. Google's Analytics Help Center documents GA4 setup if the interface has moved since you last used it.

How do you verify conversion tracking on the new website on launch day?

Verify every key event on the live domain by triggering it yourself and watching it arrive in GA4 and in each ad platform. Don't sign off on tracking from staging alone; domains, consent and cookies behave differently in production.

1. 1

   Preview GTM on the live site

   Use Tag Assistant to connect to the live domain and confirm the container loads on every template.

2. 2

   Walk the conversion paths

   Submit each form, start a signup and book a demo. Watch each tag fire once, not twice and not zero times.

3. 3

   Check GA4 DebugView

   Confirm events arrive with the right names and parameters, and that page views show new paths.

4. 4

   Test consent states

   Accept and decline the banner, and check that tags behave as your consent setup says.

5. 5

   Check ad platform tags

   Use each platform's tag helper or test-event tool to confirm conversions register.

6. 6

   Re-verify Search Console

   Confirm the property is still verified, submit the new sitemap and request indexing for key pages.

If the domain itself changes, also use Search Console's change of address tool. The Search Console Help Center explains when it applies.

What should you check in the first weeks after launch?

In the first weeks, compare daily numbers against your baseline and investigate any sudden step change. A drop on launch day is usually tracking; a gradual slide is more often SEO.

• Page views double overnight. Double tagging; remove the duplicate.
• Key events drop to near zero. A trigger still points to old URLs or selectors.
• Self-referrals appear. A booking, checkout or auth domain needs cross-domain or referral exclusion settings.
• Landing page report shows old paths. Cached pages or redirects; confirm redirects resolve to the new URLs.
• Organic traffic slides. Check redirects and indexing, using our guide to why traffic drops after a website migration.

Landing pages built for campaigns need the same care; see conversion tracking for landing pages. Migration work is scoped on the intro call, and we include redirects and SEO checks in any migration we take on.