UPDATE: a six-step framework to server-side GTM migrations

If you’re ready to make the leap to a server-side Google Tag Manager (GTM) container, we developed the UPDATE framework to help you maximise your chances of a successful switch.

At this point, we are all familiar with Google Tag Manager (GTM), as well as its quirks, workarounds, and nuances. It’s like a warm blanket, an old friend, a cup of cocoa… However, here at Measurelab, our heads have indeed been turned by the emergence of GTM’s newer, more badass sibling: server-side GTM (sGTM). So much so that we think most companies will want to switch sooner rather than later to take advantage of some of the things server-side GTM migration enables (HTTP cookies, anyone?) 

Having said that, taking this particular leap can be more daunting than switching between other technologies on the analytics stack. There are a plethora of new terms to consider, including getting your head around how it all works, the prospect of provisioning and maintaining server instances in the Google Cloud Platform (GCP), and much more that make this a project worthy of a thorough plan of action.

Enter the UPDATE framework…

Server-side GTM migration

Using our experience undertaking server-side migrations for our clients, we’ve put together a framework that will help guide you through the process and make sure you have considered every angle and outcome to be successful.

UPDATE stands for Understand, Plan, Declutter, Action, Transfer, and Evaluate. It’s not designed to be a step-by-step guide on setting up a new container, rather, it’s a structure that ensures you approach the process systematically and don’t skip crucial steps.

Download the framework in PDF format here, which includes a summary of the key tasks, our top tips, and potential pitfalls. Check out the image within the blog and have a read through the summary of each stage below.


There are several benefits to migrating to sGTM but, as already mentioned, there is also a layer of added complexity and cost. It’s important that you understand both the pros and cons and come to a decision as a business on if it is the right time to make a move.

Considerations such as, “do we have the budget?”, “do we have the internal resource for maintenance?”, and “Do we understand this technology?” should be front of mind. Once you have worked through these and confirmed you’re happy with the proposition of a switch, it’s time to plan.


Now, it may be tempting to approach this project on the fly and deal with problems as they arise, assuming you’ll eventually get the job done, but there is much more to be considered here to ensure you do not damage your data or your wallet…

For example, what approach will you take to send the information to the server? Will out-of-the-box clients serve our needs? How many server instances do our site’s traffic levels warrant? What metrics will we use to scale? As you can see, a thought-out plan of action will save a world of pain down the line, so take a breath and start plotting.


Your GTM container is a mess. There, I said it. Maybe that is unfair: your GTM container is probably a mess. After years of third-party tags, abandoned tracking initiatives, and long-since-forgotten experiments, most are. If you don’t have a robust GTM maintenance policy, an sGTM migration is a perfect opportunity to audit your current GTM setup.

Why waste time migrating this superfluous infrastructure when you don’t need to? Work through your container(s), decide what is and is not active, and promote it to the cutting room floor!


So, you have an understanding of the why, confidence in your ability to maintain everything moving forward, and a plan of action both in terms of what needs to happen and what can be left to die on the vine – it’s time to spring into action and start work.

You can spin up your server, set up all the necessary clients, tags, triggers, and variables, and thoroughly test that everything is working as it should. If you’ve done your planning correctly, you should know your approach to all aspects of setup and be able to move things through tasks quickly and easily.

You also need to be very diligent in your testing, ensuring data looks as you expect, that there are no issues with your server instances and that your tags are firing with the correct parameters, etc. The next step is to transfer to live, so feel free to linger on Action until you’re sure all is well.


Ok, when you’re happy that everything looks as expected, you’re ready to go live. This step involves swapping URLs in code snippets, ensuring sub-domains are pointing at your server, transferring the management of cookies to HTTPs, and migrating client containers to load from the server.

All of this should have been in your plan so there are no nasty surprises. By the end of this step, you will be using a shiny new sGTM container.


When you’re live, it’s time to explore the benefits afforded by sGTM. How has your page speed improved? Has the switch to HTTP cookies positively affected your traffic data?

You can also begin to think about some solutions now available to you – perhaps switching to Cloud Run for the server to allow for scale to 0 and potential cost savings. Maybe think about utilising firestore tables to augment the data before it heads off to third parties? How about sending data from the server to pub/sub to kick off a whole host of potential actions on GCP?

There is a lot to think about, right? And that is before we get to the possibilities afforded to you post-switch. If this is all still a little daunting, or you want some help planning, Measurelab can help get your migration journey started – just get in touch for a chat.

Written by

Matthew is the Engineering Lead at Measurelab and loves solving complex problems with code, cloud technology and data. Outside of analytics, he enjoys playing computer games, woodworking and spending time with his young family.

Subscribe to our newsletter: