How to update Google Tag Manager for a new site

How to safely migrate GTM when updating your site

At HammaJack we’ve been recently building a few of our client's new websites. This has led to a common problem with tracking and that is making sure you don’t lose any data when the new site replaces the old site.

This can be tricky and requires planning and a few tricks. In this article, HammaJack data lead, Jacob Moran, explains a few tricks on how to migrate a Google Tag Manager container to a new website for instance.

New website, new GTM container?

Building a new site is always interesting, and what usually happens (frequently far too late), is someone will ask what is going to happen to the tracking.

While it can be tempting to install a brand new GTM container on your new website you need to resist this urge and instead update your existing one.

But how do you do that? Well, the answer is slightly different depending on whether you have staging environments or not (if you don’t know what staging environments are, there’s a good chance you don’t have them).

Below I have outlined the approach we would use for both simple (with only one environment) and more complex websites.


To start with, for either kind of website workspaces are your best friend. For those who aren’t aware Google Tag Manager has a feature called workspaces where you can effectively have different container setups configured at once for local testing and previewing requirements. Every container has one container called the  “Default Workspace” but it can support up to 3 on the free tier at any one time. Workspaces are designed to be short-lived, so short-lived in fact that when you publish one it merges with the “Default Workspace” and ceases to exist. You can read more about them here.

So how would you use a workspace on a new site build?

Step 1 - Create a workspace

The first step is to go into your workspace area and create one called “New Site” or similar and give it a description.

GTM Workspaces.png
Workspace Description GTM.png

Step 2 - Check that its set

Once this is done you’ll see that your ‘Current Workspace’ is your new workspace.

New Site GTM.png

If it isn’t - set it so that it is.

Step 3 - Make your changes

Now, you can go through and make the needed changes to your GTM configuration safe in the knowledge that the site won’t be changed. The BIG CAVEAT to this is that this will only stay this way if you do not Publish/Submit your changes to production, as this will send your new tracking live - so don’t do that.

So how do you test the change on the site?

Step 4 - Testing your changes

This is where the GTM preview function comes into play.

All you need to do is preview your workspace changes and you can see how your changes will affect the on-site tracking.

GTM Preview Mode.png

If someone else wants to test your changes they can either;

  1. Login to GTM and preview the workspace themselves

  2. You can share the preview with them through the “Share Preview” feature/link in GTM

Is that it?

If you have a simple website, which most people do this is all you have to do. I mean, when the go-live date comes you have to publish the workspace and pat yourself on the back, but that’s it.

If, however, you have an environment-based website please read on.

Versions & Environments

This article isn’t going to go into the ins and outs of versions and environments. If you’re interested in that you can read our previous writings on it.

Suffice to say, if you have a multiple-environment website you should be using both features.

So how should you use them?


With environments, you should set at least two instances;

  1. Production

  2. Test

However, you can make others, but be aware they take some upkeep.

Once you've made these you can simply update your configs for those environments to point to the right GTM environment and then publish different versions to them.


Once you’ve set up environments you can publish your workspaces to each environment as a new version and you can watch passively what data comes through that version over a period of time. It also makes testing easier as you can test your GTM code against the rest of your codebase.

The real benefits of versions over workspaces are the easily identifiable change history and the basic process of publishing versions to different environments when you are ready.

Publishing the GTM Container.png

Most Important Point

There is a lot of other tracking considerations to be made when you send a new site, such as how to handle it in Google Analytics and Facebook etc., but that’s a story for another day. For now, remember, workspaces, versions and environments are your friends.