How Do I Migrate My Server-side GTM Setup From One Cloud Service To Another?

How to migrate from one cloud service to another without changing the domain name mapped to the server-side tagging endpoint.

The question we’re going to be looking at today is inspired by our course, Server-side Tagging In Google Tag Manager.

How do I seamlessly switch my server-side Google Tag Manager deployment from one cloud service to another?

If you follow the automatic provisioning steps of server-side Google Tag Manager, you’ll end up using Google’s App Engine platform for the deployment.

At some point, you might want to migrate away from App Engine to some other cloud service. There might be many reasons for this, but usually it’s because of the relative inflexibility of App Engine especially when it comes to multi-region setups.

With the migration, you might be concerned about your custom domain mapping. How do you ensure that the data collection and tracking you’ve configured for your server-side endpoint survive the migration seamlessly and with minimal downtime?

Luckily, this should be quite easy to do, as long as you are careful when making the switch.

In this article (and video), I’ll show you how to do the switch within Google Cloud Platform, when moving from App Engine to Cloud Run. However, the instructions should apply to whatever services you’re switching between.

Video walkthrough

If you prefer this walkthrough in video format, you can check out the video below.

Don’t forget to subscribe to the Simmer YouTube channel for more content like this.


How does the migration happen?

“Migration” is perhaps the wrong word to use here. What actually happens is that the domain name you have chosen for your service changes its mapping from one service to another.

Where this change happens depends on the service you’re using and the features they offer. In this article, we’ll tackle two possible ways to do this in the Google Cloud Platform.

Scenario 1 is where you use the domain mapping settings of both App Engine and Cloud Run to switch the pointer from one service to another. This happens internally in Google Cloud Platform and should require no DNS changes.

Scenario 2 is where you update the DNS settings of your domain name to point from one set of records to another. This is what you would use if moving from custom domain mappings within App Engine to a static external IP of a Google Cloud Load Balancer (as in the examples of this article), or if you were planning on switching from Google Cloud to some other service altogether, for example.

Update DNS to static IP

Switch between supported services

If you’ve followed the automatic provisioning steps for your Server container, or if you’ve decided to take the manual setup route for App Engine, your custom domain mapping is done with some combination of the following DNS records:

AAAA    2001:4860:4802:32::15
AAAA    2001:4860:4802:34::15
AAAA    2001:4860:4802:36::15
AAAA    2001:4860:4802:38::15

Suppose you now want to switch from Google App Engine as the backend to some other service that also uses this built-in custom domain mapping mechanism (such as Google Cloud Run). In that case, the migration is as easy as adding the custom domain mapping to the new service.

Just note that Cloud Run’s custom domain mappings are only available for a limited set of cloud regions.

Cloud Run domain mapping settings

When you do this within the same project, Google Cloud Platform automatically disables the old mapping from App Engine and updates the domain to point to Google Cloud Run instead.

You don’t have to do anything else.

If you’re changing the mapping across projects, after updating the mapping to Cloud Run, you might need to go to App Engine’s custom domain settings and remove the old mapping.

The pointer should update in a short while. Make sure you keep the old service and new service running concurrently for a day or two to make sure that all your visitors’ routings are updated to point to the new service.

Update DNS to point from the old service to the new one

The other option, and possibly the more relevant one for you, is when you need to update the DNS records themselves to point from the old service to the new one.

This needs to be done, for example, when moving from Google Cloud Platform to another cloud service like Amazon AWS, when setting up an edge frontend like Cloudflare, or when deploying a load balancer within Google Cloud Platform with a static external IP address.

In this case, you need to locate the new DNS record you need to deploy. If you’re setting up a static external IP address within Google Cloud, you’ll find the address in the IP address settings.

Static external IP

Copy this IP address and create a new A record in your domain’s DNS settings.

Make sure you remove ALL other mappings from this specific domain name. Going forward, the domain name should only point to this IP address.

Again, as a precaution, have your old service and new service running concurrently for a day or two. That way the DNS record has time to propagate and DNS caches have time to expire.


The “migration” discussed in this article is actually just having an existing domain name remapped from one cloud service to another.

Importantly, you don’t need to make any changes to the Server container settings.

Remember to pay attention to the following two things:

  1. Make sure the old service and new service run concurrently for a day or two. This gives Google Cloud the time to update the mapping for all visitors, and the DNS changes have time to propagate. Remember that you can have as many different servers and cloud services pointing to the Server container as you like.
  2. Make sure the only DNS records mapped to the custom domain name are the ones required by the new service. You must not have the old records and new records mapped at the same time, or your cloud platform will not know where to actually route the traffic.

If you have these in place, then simply by updating the custom domain pointers you should be able to configure them to map to the new service without any downtime in your application itself.

2 Responses

  1. Thanks Simo,
    I’ve been waiting for this one, super helpful (and well made :-)).

    quick question – Our DWH sits in Dublin and our current AppEngine setup is on London servers (europe-west2).
    Does it make sense to setup Cloud Run on one of the supportive close ‘domain mappings servers’ (europe-west1 or europe-west4) instead of going on the more complex loud balancer setup?


    1. Hi

      This would benefit from an exhaustive case study of course but my gut feeling is that it’s quite enough to use a Europe data center for that use case – doesn’t have to be London in particular. I don’t think the network egress costs or request latency will dramatically change either way.

Thoughts? Comment Below 👇

Your email address will not be published. Required fields are marked *

More from the Simmer Blog

The event_timestamp field in the Google Analytics 4 export to Google BigQuery is in UTC time by default. Since intraday tables are updated near realtime, it might sometimes look odd that some of your events are in the future (or too far in the past).
How to assign a static IP address to a subset of outgoing requests from a server container. This is useful if a vendor needs to allowlist the IP addresses of incoming requests.
You can attach your own listener to the dataLayer.push method. However, you need to do this in a way that doesn't disrupt Google Tag Manager.
Hide picture