Tag Manager to Server-Side: Migration Checklist

Moving from a tag manager to server-side tracking means auditing every tag in the container, replacing the ones that send data to platforms without a BAA, cleaning the data layer that feeds them, and then removing the container's role as the thing that decides what leaves the browser, and Curve is the HIPAA-compliant tracking layer that takes over that decision server-side. A tag manager is a deployment tool, not a privacy control. It does not reduce what a tag can collect. The checklist below is the order that keeps campaigns running while the exposure closes.

What a tag manager is, and what it is not

A tag manager is a container that loads third-party scripts into a page according to rules you configure. It makes deployment fast, it removes the need for a developer to edit templates, and it gives marketing teams version control over their tracking. Those are real benefits and they are the reason tag managers are on nearly every site.

What a tag manager does not do is limit what a loaded tag can see. Once a pixel is in the page, it has access to the page. It can read the URL, the referrer, the title, the data layer, and in many configurations the contents of form fields. The container controls whether a tag fires and when. It does not control what the tag collects once it does.

On a healthcare site that distinction is the whole problem. A URL such as a treatment page path, a page title naming a condition, or a form field carrying an appointment reason is protected health information the moment it reaches a platform that has not signed a BAA. Meta and Google do not sign BAAs for their advertising products, so the exposure is not conditional on anything going wrong.

The server-side container is not automatically the answer

Tag managers now offer server-side containers, and teams often assume moving the container to a server resolves the compliance question. It does not, by itself. A server-side container still receives whatever the browser sends it, and it still forwards to the same destinations. It relocates processing without changing what is disclosed, and running it on your own cloud does not create a business associate relationship with the ad platforms downstream.

Server-side containers become useful when someone explicitly configures what each destination receives and a BAA covers the layer doing the deciding. Without those two things, you have moved the pipe rather than closed the leak.

Step 1: audit the container

Export the container and list every tag, trigger, and variable. For each tag, record five things.

• What it is. Ad pixel, analytics, session recording, chat, A/B testing, call tracking, affiliate, or something nobody recognizes.
• Where it fires. All pages, or specific paths. Path-based triggers on treatment pages are worth flagging immediately, since the trigger condition itself often encodes the condition.
• What it sends. Standard parameters plus any custom fields somebody added.
• Whether the vendor signs a BAA for the product in question, not for the company generally.
• Who owns it, and whether anyone would notice if it stopped.

Expect the list to be longer than the team believes. Containers accumulate. Agency tags outlive agency relationships, campaign tags outlive campaigns, and a tag added for a two-week test six quarters ago is still firing on every page.

Also review paused and unpublished tags. A paused tag is one click from live, and workspace versions that were never published still describe intent that may get republished by someone who does not know why it was paused.

Step 2: sort the tags into three piles

Replace. Ad platform pixels and conversion tags. These are the ones the migration exists for. Their function moves server-side, where a mapped, hashed, neutrally named conversion goes to the platform's conversion API instead of a browser tag reporting the page.

Keep behind a BAA. Tools you genuinely need whose vendors will sign, or whose function can be provided by a covered system. Session recording, heatmaps, and analytics belong here if and only if the vendor is covered.

Remove. Everything else. Tags nobody owns, duplicated analytics implementations, abandoned test tooling, and vendors that will not sign. This pile is usually the largest, and clearing it improves page performance as a side effect.

Step 3: clean the data layer

The data layer is where healthcare sites leak most reliably, because it is populated by developers for functional reasons and read by tags for tracking reasons, and nobody reviews the intersection.

Dump the full data layer on your highest-traffic pages and read every key. Look for appointment types, service names, provider names, insurance details, patient identifiers, form field echoes, and anything with a date attached to a person. Look also at e-commerce style product objects on sites that sell treatments, where the product name is the condition.

Two rules make this tractable. Push only what tracking actually needs, and never push a value into the data layer because it happens to be available. If a downstream tag needs to know a conversion happened, it needs an event name and an identifier, not a description of the service.

Cleaning the data layer is worth doing even if you keep the container for non-marketing purposes, because it reduces what any future tag can pick up by accident.

Step 4: understand what consent mode does and does not fix

Consent tooling controls whether tags fire based on a visitor's choices. It is worth having, and in some jurisdictions it is required. It is not a HIPAA control.

Two reasons. First, HIPAA's rules on disclosure to business associates are not satisfied by user consent in the way marketers often assume, and a general cookie banner is not a HIPAA authorization. Second, consent mode governs whether the tag fires, not what it sends when it does. A consented visitor on a treatment page still produces a disclosure of that page to a platform without a BAA.

Treat consent management as one layer of a privacy program and the server-side field mapping as the layer that actually determines PHI exposure.

Step 5: install server-side and run parallel

Install the server-side tracking script directly in the site template rather than through the container, so your tracking layer does not depend on the container you are in the process of retiring. Leave existing tags running and leave server-side destinations disabled.

Verify during this period that every conversion event fires server-side, that click identifiers are captured on entry, that UTM parameters survive internal navigation and redirects, and that off-site steps such as third-party schedulers carry attribution across the handoff. Verify also that nothing is forwarding yet, because duplicate conversions from two systems reporting the same event are the most common self-inflicted error in this migration.

Step 6: cut over, then empty the container

Enable server-side destinations with explicit field mappings, switch campaign conversion actions to the new conversion source in one change, then remove the replaced tags from the container and publish.

Publish is a distinct step. A container edited but not published changes nothing, and a container published without review can ship someone else's in-progress workspace changes alongside yours. Review the version diff before publishing, and keep the version note specific enough that the change is identifiable a year from now.

If the container ends up holding nothing but a consent banner and a couple of covered tools, that is a good outcome. If it ends up empty, remove the container script too.

How Curve replaces the container's role

Curve is HIPAA-compliant ad tracking, marketing attribution, and analytics for healthcare, and it takes over the specific job the container was doing badly: deciding what leaves.

The Curve tracking script installs in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than directly to the ad platforms. From there, per-destination field mapping controls exactly which fields forward to which platform, and the default is that nothing forwards until it is explicitly mapped. Identifiers are SHA-256 hashed to each platform's conversion API requirements. Neutral event aliases mean the ad platform interface shows a conversion name, not a service line. PHI-pattern detection monitors payloads for PHI-shaped values such as long numeric sequences and date patterns, which is how you learn that a form change upstream started pushing something new into the stream.

Bridge tokens carry attribution across a click-out to a separate booking or intake tool, replacing the cross-domain linker configuration that container migrations usually break. Destinations include Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft and Bing UET, LinkedIn CAPI, GA4, Amazon Ads, Premion, and VWO. A signed BAA is included on every plan, which is the part no container configuration can provide.

For platform-specific implementation detail, see our guides to Meta Conversions API implementation architecture and Google Ads Enhanced Conversions setup without PHI leakage.

Post-migration verification

1. Rescan the live site for third-party scripts. Removal from a container is not proof of absence, since plugins, themes, and embedded widgets load their own scripts.
2. Check every conversion action in each ad platform for non-zero, plausible volume against your pre-migration baseline.
3. Check delivery outcomes, not just collection. A recorded conversion that never forwarded looks correct in your own dashboard and does nothing for campaigns.
4. Re-dump the data layer after the container change to confirm nothing was reintroduced.
5. Lock container access. Restrict publish rights and require review, because the fastest way to undo this work is one agency contractor adding a pixel.
6. Schedule a quarterly re-audit. Containers refill. Treat the audit as recurring maintenance.

Frequently asked questions

Does moving to a server-side container make us HIPAA compliant?

No. A server-side container relocates where tags execute. It does not by itself limit what is disclosed to the ad platforms downstream, and running it on your own infrastructure does not create a business associate relationship with them. Compliance comes from explicit per-destination field control plus a BAA with the layer doing the deciding.

Can we keep the tag manager for non-marketing tags?

Yes. Consent banners, accessibility widgets, and covered analytics tools can stay in a container. The point of the migration is to remove the tags that send data to platforms without a BAA, not to eliminate containers as a deployment method.

Should the server-side tracking script be deployed through the container?

Prefer a direct template installation. Deploying your tracking layer through the container you are retiring creates a dependency on the thing you are trying to simplify, and it means a container publish error can take tracking down.

What about tags our agency owns?

Inventory them the same way and hold them to the same standard. Agency access to your site and ad accounts frequently involves handling data on your behalf, which makes the agency a business associate that needs its own BAA. Container publish rights are a good place to enforce that.

How do we handle cross-domain tracking after the migration?

Container-based cross-domain linkers are one of the things most likely to break. A server-side layer handles the handoff with a token that carries attribution to the destination tool, which is more reliable than linker parameters and does not depend on the third-party site cooperating with your container.

How long does this take?

The audit is usually the longest part, and it is measured in days rather than weeks for most sites. The technical work is small. The schedule is driven by the parallel period, which should cover a full conversion cycle for your slowest funnel before you switch forwarding.

Where to start

Export your container and read every tag, including the paused ones. Then dump the data layer on your busiest pages and read every key. Those two artifacts will tell you exactly how much exposure exists and how much of the container is dead weight, and they take an afternoon.

Run our free compliance scanner to see the scripts actually loading on your live pages, which frequently differs from what the container says. Then read whether the Meta Pixel or Conversions API is HIPAA safe for the reasoning behind the replacement, or visit curvecompliance.com. Curve handles the server-side setup, maps each destination explicitly, and includes a signed BAA on every plan.

Reviewed August 2026. This is general information, not legal advice. Have qualified counsel review your tracking configuration and vendor agreements.