Google Tag Manager Migration Guide: Moving Your Tags Without Losing Data
Summarize with AI
Everything below is the detail of doing that without doubling your conversions, losing a week of data, or discovering in October that the ecommerce tracking stopped in August.
If you have not yet decided whether GTM is right for your setup, start with what Google Tag Manager is and when you can skip it. This guide assumes the decision is made.
Step 1: Inventory everything, including what you forgot
You cannot migrate what you cannot find, and the tags that cause problems are always the ones nobody remembered.
Look in all of these places:
- Your theme header and footer files
- Any custom fields your CMS provides for header scripts
- Plugins that inject their own tracking (SEO plugins, ecommerce plugins, chat widgets, cookie banners)
- Platform-native integrations, such as a Shopify or Squarespace field where somebody pasted a pixel years ago
- Landing page builders running on subdomains
- Any tag manager already installed that you did not know about
Then view source on a few key pages and search for the common signatures: gtag, googletagmanager, fbq, analytics.js, _linkedin, hotjar, clarity.
Record each one in a sheet with five columns: what it is, where it lives, what it fires on, who owns it, does it stay.
That last column is the valuable one.
Step 2: Delete before you migrate
A migration is the cheapest moment you will ever have to remove dead tracking, and most teams waste it by faithfully recreating everything.
If a tag belongs to a tool nobody has logged into in a year, do not migrate it. If nobody in the room can say what a script does, it goes on the delete list, not the migrate list. If two tags do the same job because two agencies each installed one, keep one.
We have opened containers with forty tags where fewer than fifteen were doing anything. Every one of those was migrated by somebody being careful.
Be careful about what survives, not about preserving everything.
Step 3: Build the container, do not publish it
Create the container, install both snippets on every page, and recreate your surviving tags inside it. Do not publish.
Two things to get right while you build:
Naming. Adopt a convention on the first tag, not the twentieth. Something like Platform - Type - Detail:
GA4 - Config
GA4 - Event - Form Submit - Contact
GA4 - Event - Click - Phone Number
Meta - Pixel - Base
Meta - Event - Lead
Google Ads - Conversion - Quote Request
The same for triggers and variables. This is the difference between a container somebody can maintain in two years and one they will rebuild from scratch.
The data layer. If you are migrating ecommerce or any tracking that carries values, the data layer is the real work. GTM can only pass along what your site publishes. Get a developer to implement the data layer before you build the tags that depend on it, or you will build tags against fields that do not exist yet.
Step 4: Wire consent before you publish, not after
This is the step most migration guides still do not include, because most of them predate it.
If you have any traffic from the EEA or the UK and you run Google Ads or GA4, consent mode v2 is required, and it needs four signals: ad_storage, analytics_storage, ad_user_data and ad_personalization. A consent management platform that only sets the first two is an incomplete integration, and the gap shows up as degraded conversion modeling, weaker Smart Bidding signal and shrinking remarketing audiences (Google Ads Help).
Connect the CMP in GTM and confirm all four signals fire before any tag goes live. Ordering matters: consent has to initialize ahead of the tags that respect it, which in GTM means the consent initialization trigger, not the standard All Pages trigger.
Doing this during migration is a small extra step. Doing it after, once tags are live, means auditing every tag again.
Step 5: Run in parallel, and make the comparison real
Publish the container while the hardcoded tags are still on the site. The point is to compare, so the two must not write to the same place.
For GA4, point the GTM version at a second, clean property. Now you have your existing property fed by hardcoded tags and a new property fed by GTM, measuring the same traffic over the same days.
Let it run for a full week. Weekends behave differently from Tuesdays and a two-day comparison will lie to you.
Then compare, and expect small differences. A 1% to 3% gap between the two properties is normal, caused by load-order timing. A 15% gap means a trigger is wrong. A gap that only appears on certain page types means a snippet is missing from a template. The reports to compare them in are the ones covered in what GA4 reports show you.
For pixels that cannot be pointed somewhere else, such as a Meta pixel that only has one destination, do not run both. That is how you double your conversions. Migrate those in step 6 instead, in the same change that removes the hardcoded version.
Step 6: Remove the old code in one change
Once the numbers reconcile, strip the hardcoded tags out of the site. All of them, in one deploy, on a day when someone is available to watch.
Then verify immediately:
- Load the site with GTM Preview mode open and confirm each tag fires once, not twice
- Check GA4 Realtime for traffic arriving
- Submit a real form and confirm the conversion registers
- Complete a real transaction if you have ecommerce, and check the value is correct, not just that the event fired
- Confirm the same on mobile, and on any page template that uses a different layout
The single-fire check is the one people skip and the one that costs money. A duplicated conversion tag inflates your reported results, which then feeds your ad platform's bidding, which then spends your budget against a number that is not real.
What breaks, and how to catch it
| What breaks | How it shows up | How to catch it before it costs you |
|---|---|---|
| Tag fires twice | Conversions and sessions roughly double overnight | Preview mode on every key template; compare week-over-week totals the morning after |
| Snippet missing on a template | Traffic looks fine, one section of the site reports nothing | Crawl the site and check for the container ID on every URL type |
| Ecommerce values missing | Transactions count, revenue reads zero or wrong | Complete a real purchase and check the value field, not just the event |
| Consent blocks everything | Traffic drops sharply in EEA and UK, looks like a ranking loss | Test with consent granted and denied, separately |
| Trigger too broad | Events fire on pages they should not | Check the event count against a sanity number, such as form submissions against actual inbox leads |
| Referral exclusions lost | Payment gateway traffic appears as a referral source, attribution scrambles | Re-check the referral exclusion list in the new GA4 property |
That last row catches people every time. Referral exclusions live in GA4 settings, not in GTM, so a new property starts without them and your Stripe or PayPal return traffic starts breaking sessions.
While you are in there, confirm your campaign links are still tagged the way they were. Our UTM parameters and campaign tagging guide has the convention, and a migration is a common moment for it to quietly drift.
Have a rollback plan
Before the step 6 deploy, make sure of two things: you have the removed code saved somewhere you can find it in five minutes, and you know how to unpublish the GTM container version.
GTM keeps every published version and lets you revert to any of them in two clicks. That is your fastest fix if something goes wrong at 6pm on a Friday.
The rollback almost never gets used. It takes ten minutes to prepare and it is the difference between a bad hour and a bad week.
Two rules that keep migrations boring
Do not migrate during a redesign. If the site is changing at the same time as the tracking, you will not be able to tell which one broke the numbers. Do one, confirm it is stable, then do the other.
Do not migrate in your busiest month. The whole point of parallel running is that you can compare against a normal week. December for a retailer, or the start of season for a service business, is not a normal week.
Common questions
How long does a GTM migration take?
For a straightforward site with analytics and a few pixels, about a day of build plus a week of parallel running. With ecommerce and a data layer to implement, budget two to four weeks, most of it developer time on the data layer rather than GTM itself.
Will I lose historical data?
No. Migration changes how data is collected going forward. Everything already in your GA4 property stays there. If you use a second property for parallel testing, decide in advance whether that becomes your permanent property, because the new one starts empty.
Can I run hardcoded tags and GTM at the same time?
Yes, and you should, for anything that can write to a separate destination. Never for a tag with only one destination, such as an ad platform conversion pixel, because that doubles your reported conversions.
Do I need a developer?
For basic analytics and pixels, no. For ecommerce tracking, enhanced conversions, or anything reading values off the page, yes. The data layer is code and it has to be built into the site.
Should I migrate to GTM and GA4 at the same time?
If you are somehow still on a legacy analytics setup, do the platform move first and get it stable, then move the delivery mechanism. Two variables at once means you cannot diagnose either.
The part worth being slow about
The failure mode of a tag migration is not dramatic. Nothing goes down. The site works, the dashboards populate, and everybody moves on.
Then two months later somebody notices that lead volume in the report does not match the inbox, or that ad spend has been optimizing against conversions that fired twice. By then you have sixty days of decisions built on top of it.
That is why the parallel week stays in the plan. It is the only part of this process that catches a quiet failure while it is still cheap. Once it is done, confirm the whole picture still holds in how to track website traffic.
Tag migrations are routine work for us and we run them with the parallel period built in, usually inside a wider marketing automation engagement.
Rather not do this yourself?
Send us your current setup and we will scope the migration, including whether your data layer needs building first.
Written by J Raydel Sanchez, Founder and CEO of tamer, a digital marketing agency in Hialeah, Florida.
