Switching Tracking Vendors: Protecting Your Data

Protect your data when switching tracking vendors by exporting your raw event history and configuration before you give notice, running both systems in parallel through at least one full conversion cycle, and reading the termination and PHI-return clauses of the outgoing BAA before the notice window closes. Curve is HIPAA-compliant ad tracking and analytics for healthcare, and a switch into it is designed to run alongside your existing setup rather than replace it overnight. Most of what teams lose in a vendor change is lost in the first week, before anyone has thought about exit terms.

What "your data" actually means here

Tracking vendors hold five distinct things, and they are not equally portable. Treat them separately, because a vendor who says "you can export your data" is usually talking about only the first one.

• Raw event history. The individual events: page views, form submissions, purchases, custom events, with their timestamps, session identifiers, and parameters. This is the most exportable layer and the one most often exported in a format that is technically complete and practically unusable.
• Attribution and identity data. The mappings that connect a click identifier to a session, a session to a contact, and a contact to a conversion that happened days later. This is the layer with the real value, and it is frequently proprietary in structure.
• Configuration. Event definitions, field mappings per destination, conversion actions, goals, funnels, consent settings, and the naming conventions your reports depend on. Almost never exportable in a form another system can ingest. Plan to rebuild it, and plan to document it while you still have access.
• Forwarded conversion history inside the ad platforms. This one is not the vendor's to give or take. Conversions already delivered to Meta, Google, or Microsoft live in those accounts and stay there.
• Derived reporting. Dashboards, saved reports, cohort views, and anything computed on top of the raw layer. Export the outputs as files, because the computations will not transfer.

Portability is a question you ask before signing

The right time to establish export rights is during procurement of the vendor you are joining, not during the exit from the one you are leaving. Ask for specifics, in writing.

What formats are available, and is there an API or only a manual export? Is there a row limit or a date range limit per export? Does the export include the attribution fields, or only the event fields? How long after termination does access remain, and is there a charge? Is historical data deleted immediately on termination, and can you request a delay?

The last question matters more than it looks. A vendor that deletes on the termination date, combined with a notice period you discovered late, can leave you with days rather than weeks to extract years of history.

Export while you are still a happy customer

The practical rule is to export before you give notice. Access, support responsiveness, and goodwill all decline after a termination email, and none of that is unusual or malicious. It is simply that an account in wind-down gets different attention than an account in renewal.

Take a full raw export, take a configuration screenshot pass covering every settings screen, and export your standing reports as files. Store them somewhere covered by a BAA, because event data from a healthcare site can carry health context even when it looks like a list of URLs.

Historical continuity: what actually breaks

Two systems that both track the same site will not produce identical numbers, and understanding why prevents a month of pointless reconciliation.

Sessionization differs. Systems disagree about when a session ends, whether a campaign change starts a new one, and how to treat a return visit within a timeout window. Attribution models differ. Last click, first click, and position based models applied to the same events give different campaign credit. Lookback windows differ. A 30-day window and a 90-day window will disagree about conversions from older clicks for months after the switch.

Deduplication differs too. Whether a conversion forwarded to both a browser tag and a server endpoint counts once or twice depends on the event identifier scheme, and identifier schemes rarely survive a vendor change.

The consequence is that you should not expect to splice two histories into one continuous chart. What you can do is keep the old system's history as a separate archived series, note the switch date on any chart that spans it, and rebuild your baselines from the new system going forward. Trying to force continuity produces numbers nobody trusts, which is worse than an honest discontinuity.

Run an overlap period

Overlap is the single highest-value decision in a vendor switch. Both systems collect. Only one forwards to the ad platforms.

That last constraint is not optional. Two systems forwarding the same conversions to the same destination produce duplicate conversions, inflated counts, and optimization decisions based on fiction. Collect in parallel, forward from one.

Make the overlap long enough to cover one full conversion cycle. In healthcare that is usually longer than a marketing team expects, because the gap between an ad click and an attended appointment can run several weeks. If your typical click-to-appointment lag is three weeks, a one-week overlap tells you nothing about whether appointments will be attributed correctly.

During overlap, compare on four axes: total event counts by type, conversion counts by campaign, the distribution of traffic across channels, and the click identifier capture rate. Differences in the first three are expected and interpretable. A difference in the fourth is a defect, because a click identifier is either captured or it is not.

Contract exit mechanics

Find the termination clause before you plan anything else, because it sets the calendar.

Note the notice period and whether it is measured from the notice date or the next renewal date. Note whether renewal is automatic and what window the non-renewal notice must land in. A 90-day window on an annual auto-renew means the decision to leave in month twelve has to be made in month nine.

Then read the BAA's termination provisions separately from the commercial terms. HIPAA requires return or destruction of protected health information at the end of the relationship, and a proper agreement says so, with certification. Many include an exception permitting retention where return is infeasible. That exception is reasonable in principle, and a broad version of it means your data stays with a former vendor indefinitely. Ask for written confirmation of destruction, and keep it.

Also confirm what happens to subprocessors. Your former vendor's obligations flow down to its subcontractors, and destruction confirmation should cover them too.

What you will lose regardless

Be honest with stakeholders about this list before the switch rather than after.

You lose the ability to rerun old analyses on new definitions, because the definitions changed. You lose granular history if the export is aggregated or capped. You lose configuration nuance, since the reason a particular field was excluded three years ago is usually undocumented and lives in someone's memory. You lose comparability across the switch date for any metric that depends on sessionization or attribution modeling.

You do not lose conversions already delivered to your ad accounts, campaign learning inside those platforms, or your own CRM and EHR records, which are the systems of record for anything that matters clinically or commercially. Framing the loss accurately makes the decision easier, because the irreplaceable systems are not the ones you are changing.

How Curve handles a switch

Curve is HIPAA-compliant ad tracking, marketing attribution, and analytics for healthcare, and the migration path is built around parallel collection rather than a hard cutover.

The tracking script installs alongside whatever you are running today, so Curve begins collecting immediately while your existing system keeps forwarding to the ad platforms. Destinations stay off until you enable them, which is what prevents the duplicate-forwarding failure. When you do enable them, per-destination field mapping controls exactly what leaves, with nothing forwarded to a given platform unless it is explicitly mapped, and identifiers SHA-256 hashed to each platform's conversion API requirements.

Two capabilities address the continuity gap specifically. Offline conversion uploads let you push historical conversions from a CRM or EHR into the ad platforms with click identifier matching, subject to each platform's own time limits, which is how outcomes recorded during the transition still reach the campaigns that produced them. Bridge tokens preserve attribution when a patient clicks out to a separate booking or intake tool such as IntakeQ, Calendly, or Jane App, which is where healthcare funnels most often break during a vendor change.

A signed BAA is included on every Curve plan, so the parallel period is covered from the first event rather than from contract execution on a higher tier. Curve's team handles the configuration rebuild, which is the part of a switch that consumes the most internal time. For the mechanics of the routing layer, see our guide to lead routing from ad click to CRM without PHI and the technical overview of conversion API architecture.

A switching sequence that works

1. Read the outgoing contract and BAA first. Notice period, renewal window, data retention on termination, PHI destruction obligations.
2. Export everything while the account is in good standing. Raw events, reports as files, and a full configuration capture.
3. Document the configuration in plain language. Every event, every field mapping, every conversion definition, and the reason behind any exclusion.
4. Install the new system in parallel with destinations disabled.
5. Compare through one full conversion cycle, not one calendar week.
6. Switch forwarding once, in a single change, then update campaign conversion actions together.
7. Give notice only after the new system is verified in production.
8. Request written confirmation of PHI destruction, covering subprocessors, and file it.

Frequently asked questions

Will we lose conversion history in our ad accounts?

No. Conversions already delivered to Meta, Google, Microsoft, or any other platform are stored in those accounts and are unaffected by changing the vendor that delivered them. What changes is the source of new conversions, which is why the conversion action switch should happen deliberately and all at once.

How long should the overlap period be?

Long enough to observe one complete conversion cycle for your slowest funnel. For practices where appointments are booked weeks out, that means several weeks. A short overlap validates event firing but tells you nothing about delayed attribution, which is exactly where switches go wrong.

Can both systems forward conversions during the overlap?

They should not. Duplicate conversions distort campaign optimization and are difficult to unwind after the fact. Collect with both, forward with one, and switch forwarding in a single change once the comparison is clean.

What if our current vendor will not provide a full export?

Check the contract and the BAA, since access and return obligations are often stated there even when the product has no self-serve export. If neither helps, extract what you can through the reporting interface, capture configuration thoroughly, and treat the gap as a lesson for the incoming contract, where export terms should be explicit.

Does the outgoing vendor have to delete our data?

Under a BAA, protected health information should be returned or destroyed at termination, usually with certification, unless the agreement contains an infeasibility exception. Read that clause specifically, request written confirmation, and confirm the obligation flows down to subprocessors.

Should we tell the ad platforms we are switching?

There is nothing to notify. What matters operationally is that the conversion actions your campaigns optimize toward point at the new source, that deduplication identifiers are consistent, and that you do not leave an old conversion action active and half-fed alongside the new one.

Where to start

Start with two documents: your current vendor's termination and BAA clauses, and a written inventory of every event, field mapping, and conversion definition you are running today. The first sets your calendar. The second is what you will rebuild, and it is far easier to write while you still have access than to reconstruct afterward.

Then install the new system in parallel with forwarding off and let it collect while you compare. Curve is built for that pattern, with a signed BAA on every plan, per-destination field mapping that forwards nothing unless mapped, and hands-on configuration during onboarding. Run our free compliance scanner to document what your site sends today before anything changes, or visit curvecompliance.com.

Reviewed August 2026. This is general information, not legal advice. Have qualified counsel review termination and data-return provisions before giving notice.