An ecommerce site has more measurement tags than most other sites, which means an sGTM migration touches more downstream consumers and breaks more reports if done wrong. The right sequence is to move read-only consumers (analytics) before write-side ones (advertising) and leave the cleanup until last.

Inventory first

Before changing anything, list every tag in your client GTM container and group them into three buckets: analytics (GA4, Matomo, internal warehouse), advertising (Meta Pixel, Google Ads, TikTok Pixel), and operational (chat widgets, A/B testing tools, fraud detection). The sequence below addresses each bucket separately.

Phase 1: analytics

Migrate GA4 first. The tag template is mature, the impact on reports is minimal if you handle the dual-firing window correctly, and any errors will show up in dashboards within hours. Run the GA4 client-side and server-side in parallel for one to two weeks. Compare event counts daily. When the difference is below 1 percent, disable the client-side tag.

If you ship to BigQuery, set up the parallel BigQuery export at this stage. It gives you a second source of truth during the next two phases.

Phase 2: advertising

Move Meta Pixel and Google Ads next. These have direct revenue implications and benefit most from server-side hashing. Set up event_id deduplication first, then start sending events from both sides. Watch the Events Manager dedup column for two weeks. When it shows above 80 percent overlap, you are clear to remove the client-side tag.

TikTok and LinkedIn follow the same pattern but are noisier. Expect a longer parallel period.

Phase 3: operational

Chat widgets, A/B test tools, and fraud detection rarely benefit from server-side migration. They need to run in the browser to capture session-level signals. Leave them on the client side. The reason to migrate to sGTM is the data they produce being routed elsewhere, not the tools themselves moving.

Order tag specifics

For ecommerce events specifically, the parameters that need to survive the migration: transaction_id, value, currency, items (array). The items array is where most teams lose data; the server-side template strips items that do not have a item_id, and your client-side might not always set one.

For refunds, send a separate refund event with the negative value. Some teams try to update the original purchase event, which works in some destinations and not others.