Moving an existing server container to Measurebase without losing a day of data

A server container is a configuration, not a server. Google stores it; whoever hosts it just runs it. That is why a move costs no tags, no triggers and no variables: Measurebase hosts the container you already have, and the only moving parts are a DNS record and, if you change the hostname, one URL in your web container. Done in the right order, the old host and the new one answer the same container side by side and no hit is lost.

Before you start: three facts about your setup

• The hostname your site sends to. The value of server_container_url in your Google tag, for example sgtm.yoursite.com. Check whether every tag uses the same one.
• The DNS record behind it. Usually a CNAME to your current provider or an A record to their address, with its TTL.
• Where the container is. Admin → Container Settings in the server container: the config string under Manually provision tagging server is what any host runs.

Step 1 · Add the domain in Measurebase with the same container

Domains → New domain. Enter your main domain, then either connect Google Tag Manager and pick the existing server container, or paste its config string. Measurebase provisions a tagging server from that exact container; the tags, clients and transformations come with it because they are the container.

The tagging subdomain is the one decision. Keeping your current hostname means zero changes in Tag Manager and in any hard-coded references: enter the same label (for example sgtm) and the cutover is a DNS change only. Choosing a new name is worth it when the current one is on ad-block lists, as sst and sgtm are; then plan for the one URL change in step 3. You can also do both: move first under the old name, rename later.

Step 2 · Switch DNS without a gap

1. Lower the TTL of the existing record to 300 seconds a day before, so the switch propagates in minutes.
2. On the domain's Settings page in Measurebase, copy the A record (Type, Name, Value). Replace the old CNAME or A record with it at your DNS provider.
3. Click Verify DNS now. The certificate is issued on the first request after the record resolves; the status goes from Pending to Active.

During propagation some visitors still reach the old host and some the new one. Both run the same container with the same tags, and both set cookies on your registrable domain, so nothing diverges. Keep the old host running until well after the old TTL has passed.

Step 3 · Only if the hostname changed: update the web container

Change server_container_url in the Google tag and in any event settings variable that carries it, and in the server container go to Admin → Container Settings → Server container URLs and put the new address first (Preview mode uses the first one). Publish the web container. From that version on, hits go to the new host; visitors with the old version cached for a few minutes still reach the old one, which is why it stays up a little longer.

What carries over by itself

• Cookies. _ga, FPID, _gcl_aw and the rest are set on your registrable domain, not on the host, so a visitor who came through the old host is the same visitor on the new one. Sessions continue; new-versus-returning is unaffected.
• Click IDs and consent. They live in the browser and in your web container; the server host plays no part.
• Container versions. Measurebase runs the published version, like any host. Preview, workspaces and publishing stay in Tag Manager.

Step 4 · Verify

• The domain's request logs show the first hits within seconds of the switch, with status 200 and the client that claimed them.
• GA4 Realtime keeps moving; a purchase test lands in DebugView once.
• Server container Preview mode connects through the new host.
• The first tracking audit runs that night and tells you if any tag still sends elsewhere, including Google hits that bypass the server container.

Step 5 · Retire the old host, then improve

After a week without traffic on the old host, cancel it. Then take the steps that were not possible before: switch the loader to the Enhanced script so the container and every request come from your own domain in a form blockers do not recognise, switch on the power-ups you want, and, for Safari, consider Same-Origin Tracking.

Pitfalls we see

• A CDN or proxy in front of the old hostname. If the subdomain was proxied through a CDN, the record you replace is the CDN's; make sure the new A record points straight at Measurebase.
• Two hostnames in one container. Some setups send GA4 to one host and Ads to another. Check every tag's server URL, not only the Google tag.
• Shopify. The Measurebase app sets the tagging host per storefront; update the domain there rather than in the theme.
• The quota. Your plan counts requests at the tagging server; a container that used to run on a different plan may need a different tier. The request logs show the volume within a day.

Frequently asked questions

Do I have to recreate the container in Measurebase?

No. You never recreate anything; you point Measurebase at the container you have.

Can I run the old host and Measurebase in parallel for a while?

Yes, that is what the DNS switch does by nature. Both run the same published version, so reports see one setup.