Server-side GTM verhuizen naar een andere cloudprovider: zo doe je het zonder downtime
Wie zijn server-side Google Tag Manager-setup wil verplaatsen van Google App Engine naar een andere cloudservice, hoeft de server-container zelf niet aan te raken. De migratie draait volledig om het opnieuw koppelen van de custom domeinnaam aan de nieuwe service, via interne Google Cloud-instellingen of via een DNS-wijziging. Zolang de oude en nieuwe omgeving een dag of twee gelijktijdig draaien, is downtime in de dataverzameling te voorkomen.
Wat er feitelijk verandert bij een 'migratie'
De term migratie is hier enigszins misleidend. De server-container in Google Tag Manager blijft volledig ongewijzigd. Wat verandert, is uitsluitend de koppeling van je custom domeinnaam: die wordt doorverwezen van de ene cloudservice naar de andere. Alle tags, triggers, variabelen en clients in de server-container blijven intact. Herconfiguratie van GA4-server-tags, Meta CAPI-clients of andere instellingen is nergens voor nodig.
Twee scenario's: intern omzetten of DNS aanpassen
Het eerste scenario geldt wanneer je binnen Google Cloud Platform blijft en overschakelt van App Engine naar Cloud Run. Voeg de custom domain mapping toe aan Cloud Run binnen hetzelfde project, en Google Cloud schakelt de App Engine-koppeling automatisch uit. Een DNS-wijziging is dan niet nodig. Let wel: Cloud Run ondersteunt custom domain mappings alleen in een beperkt aantal regio's. Werk je project-overstijgend, verwijder dan achteraf handmatig de oude mapping in App Engine. Het tweede scenario speelt bij een overstap naar een andere cloudprovider zoals Amazon AWS, bij het inschakelen van een edge-service als Cloudflare, of bij het koppelen van een load balancer met een statisch extern IP-adres binnen Google Cloud. In dat geval zoek je het nieuwe IP-adres op, maak je een nieuw A-record aan in de DNS-instellingen van je domein en verwijder je alle andere bestaande records voor dat domein. Meerdere conflicterende records tegelijk laten staan, zorgt ervoor dat het cloudplatform niet weet waar het verkeer naartoe moet.
Wat te controleren als GTM- of GA4-beheerder
Laat de oude en nieuwe service minstens één à twee dagen gelijktijdig draaien. Dit geeft Google Cloud de tijd om de routering voor alle bezoekers bij te werken en zorgt ervoor dat DNS-caches kunnen verlopen. Controleer in je GA4-realtime-rapport of server-side hits nog steeds binnenkomen via het verwachte domein. Verifieer in de server-container preview-modus dat requests op de nieuwe service aankomen. Zorg dat na de overstap uitsluitend de DNS-records van de nieuwe service zijn ingesteld voor het custom domein. Staan er nog oude A- of AAAA-records naast de nieuwe, verwijder die dan direct.
Geen wijzigingen in de server-container nodig
Dit is het praktische voordeel van deze aanpak: de server-container-URL in je web-container, de GA4-meetprotocol-endpoint, de Meta CAPI-doorstuurconfiguratie en eventuele consent-instellingen hoeven allemaal niet te worden aangepast. Zolang het custom domein bereikbaar blijft en naar de juiste service wijst, merkt de dataverzameling niets van de onderliggende infrastructuurwijziging.