Summary of the process
Build a measurement baseline before changing the site.
- Inventory the current setup: record tags, events, conversions, consent behavior, audiences, links, and deployment sources.
- Prepare staging: deploy the new site without publishing uncontrolled GTM, CMP, or checkout changes.
- Test expected actions: compare each staging action with browser requests, Tag Assistant, and GA4 DebugView.
- Protect attribution: test cross-domain journeys, payment returns, 301 redirects, and UTM parameters.
- Remove duplicates: keep one approved source for each Google tag and conversion event.
- Run a monitored launch: assign owners, acceptance checks, and rollback triggers before DNS changes.
Set a change freeze: Do not publish unrelated GTM, WordPress, Shopify, CDN, or consent-banner changes 24 to 48 hours before migration. A clean baseline makes the source of a failure visible.
Build the measurement inventory first
Record every measurement dependency before changing hosting, CMS, DNS, templates, or checkout.
Capture GA4 property settings
Open Google Analytics 4 Admin and select the correct GA4 property. Then open its web data stream. Copy the Measurement ID into a migration document. It usually begins with G-.
Record enhanced measurement settings and internal traffic filters. Also record data retention, linked Google Ads accounts, audiences, key events, and any BigQuery export.
A missing setting can break reporting after launch.
Export GTM and map tag sources
List each tag, trigger, variable, consent setting, custom template, and data layer key. A data layer is a browser-side data list. It passes product ID, order value, and logged-in state to GTM.
A new CMS may rename a key. For example, it may change transaction_id to order_id. The tag may fire but send incomplete ecommerce data.
Search old site code for GTM-, gtag(, googletagmanager.com, and the Measurement ID. Check WordPress plugins and Shopify customer events. Check theme files, checkout apps, Cloudflare Zaraz, and server-side Google Tag Manager containers.
This takes longer when a former agency placed scripts in several locations.
Create an event evidence sheet
Make a spreadsheet with one row for each action. Include page_view, generate_lead, sign_up, login, view_item, add_to_cart, begin_checkout, purchase, file_download, and form_submit. Include every business-specific event too.
Add the event name and trigger condition. Add required parameters, destination, owner, and a sample URL.
| User action | Expected event | Required data | Owner |
|---|
| Product page opens | view_item | item_id, item_name, price | Analytics |
| Cart button clicked | add_to_cart | items, value, currency | Development |
| Order completed | purchase | transaction_id, value, currency | Commerce |
Treat enhanced measurement, key events, and advertising integrations as separate release checks. During a GA4 migration checklist, compare old and new web stream settings. Check scrolls, outbound clicks, site search, file downloads, video engagement, and form interactions.
Disable or adjust enhanced measurement when GTM sends an equivalent custom event. Otherwise, GA4 can report duplicate events with different names or parameters.
For conversion tracking migration, confirm the intended event remains a key event in GA4. Confirm linked Google Ads conversions receive the correct value, currency, and transaction ID.
Keeping the same GA4 measurement ID does not preserve these reporting and bidding dependencies.
Test the new stack in staging
Deploy the new tracking setup in staging and prove each expected event before launch.
Use a controlled test browser
Test three consent states if your site uses a CMP. A CMP is a consent management platform or cookie banner. First reject analytics cookies. Then accept them. Then test any partial choice offered by the banner.
Record whether the Google tag is blocked. Also record whether it runs with denied consent. Check whether it updates consent state after the visitor chooses.
Consent behavior can differ between staging and production.
Verify requests and DebugView
Open Admin > DebugView in GA4 while Tag Assistant enables debug mode. Check event order, names, parameters, and user properties. Confirm each event arrives once.
DebugView usually shows test hits within seconds or minutes. Standard reports can take several hours to 24 hours.
An expected-event matrix catches failures that Realtime misses. Mark a row Pass only when Tag Assistant, the network request, and DebugView agree. They must show one event and all required fields.
Migration verification flow
Inventory
→
Staging action
→
Tag Assistant
→
Network request
→
DebugView
→
Launch approval
A failed check stops the release. The owner must fix it, or the team must accept a documented exception.
Compare staging with production
Compare the staging setup with production to identify any environment-specific differences before launch.
Preserve attribution across domains
Configure domain journeys so one visitor remains one session through checkout, login, and redirects.
Add approved cross-domain paths
In Google tag settings, add every domain visitors cross during a normal conversion. Include the store, checkout, account portal, booking engine, and branded payment domain. Do not add unrelated partner domains only because they link to your site.
The most common error here is testing only the first checkout page. Test the payment-provider return path too. That redirect often creates the unwanted referral.
A visitor should remain in one session throughout the conversion path.
Control referrals and redirects
Test every 301 redirect in the redirect mapping file with a UTM-tagged URL. Check HTTP to HTTPS redirects and www changes. Check old-to-new domain redirects, language folders, and trailing-slash rules.
A redirect that drops the query string silently removes campaign attribution.
Confirm conversion identity
Complete one controlled transaction or lead flow in staging. Complete it again in production after launch. Confirm purchase has one transaction_id, value, currency, and item list.
A transaction ID is the order's unique receipt number. It helps identify duplicate ecommerce events.
Remove duplicates and test consent
Choose one deployment source for each GA4 event and verify consent states after the new design loads.
Search page source and GTM preview for the Measurement ID and GTM container ID. Check CMS plugins, theme headers, and footer injection fields. Check checkout apps, Cloudflare, and server-side tagging settings.
Disable duplicate sources instead of hiding events with filters.
One event needs one approved sending source.
Test consent mode behavior
Google Consent Mode sends consent choices to Google tags. It uses values such as analytics_storage, ad_storage, ad_user_data, and ad_personalization.
The required setup depends on your legal basis and regions served. It also depends on how you use advertising. It does not replace a valid privacy program.
Compare deployment approaches
| Approach | Typical setup time | Duplicate-event risk | Best use during migration |
|---|
| CMS GA4 plugin | 10 to 30 minutes | High if GTM also loads GA4 | Simple sites with no custom events |
| Google Tag Manager | 30 to 90 minutes | Low with one container owner | Most custom event and consent setups |
| Server-side GTM | 4 to 12 hours | Medium without event rules | Teams needing first-party endpoint control |
A clean tag architecture makes launch diagnosis much easier. The remaining task is making the release reversible.
Run a monitored cutover and rollback
Launch only after named owners agree on measurable pass conditions and rollback triggers.
Use launch acceptance checks
After deployment, purge the Content Delivery Network cache. Then load the production site in incognito mode. Test core pages, consent states, a UTM landing URL, and the highest-value conversion.
Compare one live conversion path against the event evidence sheet.
Use these acceptance conditions: confirm one page_view per standard page load, one purchase per transaction_id, and that all required purchase parameters are present. Confirm UTMs survive redirects. Confirm payment providers receive no referral credit.
For a lead site, replace purchase with the qualified form or booking event.
Keep rollback ready
Keep the prior GTM container version and CMS backup available. Keep the redirect file, DNS records, and previous hosting access available. Set a rollback decision owner before release.
A rollback without authorization can become a debate. Paid traffic may keep entering broken funnels during that debate.
Monitor after release
Review DebugView during the change window. Then review standard GA4 reports after data processing finishes. Compare event counts and conversion patterns across similar traffic periods.
Do not compare totals minute by minute. Paid-media volume, weekday patterns, and promotions can change normal totals.
Avoid the migration errors that ruin data
Stop release shortcuts that create silent measurement damage.
Replace weak testing habits
Do not test only desktop. Mobile browsers, Safari privacy behavior, embedded checkout frames, and delayed cookie banners can behave differently. Test one desktop browser and one mobile browser when both support the conversion flow.
Do not pass a conversion only because its event name appears. Confirm the exact parameters used by your reports and advertising. A purchase without transaction_id is not a valid ecommerce purchase.
Event names alone cannot prove correct conversion data.
Keep old redirects in place
⚠️ Do not remove old redirects after the first successful test. Old campaign links and bookmarks may send visitors for months.
What people ask
Should i keep the same GA4 measurement ID?
Keep the same Measurement ID when the business and GA4 property remain the same. Also validate tags, events, consent settings, referral rules, and conversions. The ID alone does not preserve those elements.
How do i know if GA4 stopped tracking?
Use Tag Assistant, browser network requests, and DebugView to confirm GA4 requests and events. Realtime is a quick clue. It cannot prove required parameters or prevent duplicate event reporting.
Can i move GA4 to a new domain?
Yes, GA4 can continue on a new domain when the same property remains appropriate. Add redirects that preserve UTM parameters. Configure cross-domain tracking and test the full conversion route.
Why does GA4 duplicate events after migration?
GA4 events usually duplicate because two tag sources send the same action. Check GTM, gtag.js, CMS plugins, theme code, checkout apps, and server-side tagging. Check these before trying report filters.
How do i set up GA4 cross-domain tracking?
Add each controlled domain in one user journey to Google tag cross-domain settings. Test an incognito journey with a UTM-tagged URL. Confirm the linker parameter remains when the visitor crosses domains.
Do i need server-side GTM for a host migration?
No, server-side GTM is not required for a normal hosting migration. It can suit teams needing first-party collection endpoints. It adds 4 to 12 hours of setup and needs clear deduplication rules.
Can i transfer GA4 historical data to another property?
GA4 historical data cannot fully move into another property as native history. Keep the original property for past reports. Export needed data through reports or BigQuery before creating the replacement setup.
What should i test after DNS changes?
Test redirects, consent states, one page_view, core events, UTMs, cross-domain checkout, and one real conversion path. DNS propagation can vary. Repeat checks from more than one network during the first 24 hours.
The essential points:- Document the working GA4, GTM, data layer, consent, and conversion setup before infrastructure changes begin.
- Approve staging only when Tag Assistant, browser requests, and DebugView show the same expected event behavior.
- Protect attribution by testing UTMs, redirects, cross-domain paths, and payment-provider returns.
- Use one deployment source per event. Keep a rollback-ready version of every changed layer.
Related sources
These articles can help you explore the topic in more depth:
