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

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.

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:

A       216.239.32.21
A       216.239.34.21
A       216.239.36.21
A       216.239.38.21
AAAA    2001:4860:4802:32::15
AAAA    2001:4860:4802:34::15
AAAA    2001:4860:4802:36::15
AAAA    2001:4860:4802:38::15
CNAME   ghs.googlehosted.com

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.

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.

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.

Summary

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.