Switching Visitor ID Vendors: The Data Migration Checklist

Switching visitor-identification vendors safely means exporting and archiving historical matched-account data before you cancel the old vendor, mapping old vendor fields to new vendor fields in the CRM instead of assuming they mean the same thing, running both tags in parallel for a QA window before cutting over, and only then removing the old script and pausing the old CRM workflow. Skipping the parallel-run step risks a silent coverage gap — a week or more where neither vendor is reliably feeding sales, and nobody notices until a pipeline review asks where the account signals went.

Even a same-vendor rebrand illustrates why this needs a checklist rather than assumption. When Dealfront became Leadfeeder again on March 24, 2026, the company's own FAQ confirmed pricing and data stayed the same, but customers still had to update login URLs, allowlist a new email domain, and learn that some features had been renamed. If a brand-only change requires a documented transition, a genuine switch between two different vendors' scripts, data models, and CRM fields needs a real checklist.

What is on the vendor migration checklist?

Step	What to do	Why it matters
1. Export and archive historical data	Before cancelling, export matched-account history from the old vendor's dashboard (or API, if available) and store it somewhere outside the vendor's platform.	Once a subscription ends, historical match data is often no longer accessible; you may want it later for trend comparisons.
2. Map old fields to new fields	List every CRM field the old vendor populated (company name, domain, page/event, source label) and confirm where the new vendor writes the equivalent field. Do not assume the field names or formats match.	Two vendors rarely use identical field names or the same evidence-level labels; a silent mismatch can leave old data orphaned or new data overwriting the wrong property.
3. Create clearly source-labeled properties	Use new, explicitly labeled CRM properties for the new vendor's data (e.g., source: new-vendor-name) rather than overwriting the old vendor's fields in place.	HubSpot's properties documentation supports building source-labeled custom fields; keeping old and new data distinguishable prevents a report from silently mixing two vendors' definitions of "match."
4. Install the new tag alongside the old one	Add the new vendor's script (via GTM, Webflow custom code, or HubSpot tracking placement, depending on your setup) without removing the old one yet.	Running both at once is the only way to confirm the new vendor actually covers your traffic before you lose the old vendor's coverage.
5. QA the new tag	Run the post-launch QA test script on the new install: confirm it fires once, respects consent, and reaches its own dashboard.	A new tag that silently fails to fire is worse than no migration at all if the old tag is removed at the same time.
6. Run a parallel-run comparison window	For one to two weeks, compare matched-account volume and a sample of matched companies between the old and new vendor on the same traffic.	This is the step most teams skip, and the one that catches a real coverage gap or a systematically different match rate before commitment.
7. Update or rebuild downstream workflows	Point CRM workflows, Slack-style alerts, and routing rules at the new vendor's fields; do not leave a workflow silently reading a field the old vendor no longer writes to.	A workflow reading a stale field will look like it is working while quietly processing nothing.
8. Remove the old script and cancel	Once the parallel-run window confirms the new vendor is reliable, remove the old vendor's script and cancel the subscription.	Removing the old script first, before confirming the new one works, is how coverage gaps happen.
9. Note the cutover date	Record the exact date coverage switched vendors somewhere your team will find it later (a CRM note, a wiki page, or the data model doc).	Anyone reviewing historical match-rate trends later needs to know a vendor switch, not a real trend, may explain a data-shape change on that date.

Why is the parallel-run window the step to protect?

Every other step in this checklist is reversible or low-risk on its own. The parallel-run window is the only step that actually proves the new vendor works on your traffic before you give up the old one. Skip it, and a genuine problem with the new install — a missed consent state, a page-scope mistake, or simply a vendor that identifies less of your specific traffic mix than the old one did — will not surface until someone notices sales alerts have gone quiet.

Use the same install verification you would use for a brand-new tag. If the new vendor's script goes through Google Tag Manager, GTM's Preview and Tag Assistant can confirm firing behavior before you touch the old tag at all. If it goes directly onto Webflow or HubSpot, use the platform install checklist.

What should you do with old CRM data after the switch?

Do not delete or overwrite the old vendor's historical fields once the new vendor is live. Keep them as a labeled historical record (source: old-vendor-name, retired 2026-09-16) so:

• past match-rate or pipeline reports still make sense when someone looks back at them;
• nobody mistakes stale old-vendor data for current new-vendor data;
• the data model guide still applies once you decide which fields to keep going forward.

What does a vendor switch look like in practice? (hypothetical)

Hypothetical example — names, numbers and dates are illustrative. A company decides to replace an aging visitor-identification vendor after repeated unexplained match-rate drops. Following the checklist, the team first exports two years of matched-account history from the old vendor's dashboard into a spreadsheet. They map the old vendor's company_match and domain fields to new HubSpot properties they create specifically for the new vendor, prefixed with the new vendor's name. They install the new vendor's script through the same GTM container the old tag already used, and run both tags for twelve days. During that window, they compare a sample of 30 matched accounts per day between the two vendors and find the new vendor identifies a comparable set of accounts with fewer domain-quality issues. Confident in the result, they update the Slack alert workflow to read from the new vendor's fields, remove the old vendor's GTM tag, cancel the old subscription, and log the cutover date in their internal data-model document.

FAQ

Do I need to keep the old vendor's historical data forever?

No, but export and archive it before cancelling, even if you are not sure you will need it. Once a subscription ends, that historical data is often unavailable, and deciding later that you wanted it is too late.

How long should the parallel-run window be?

Long enough to see a representative sample of your normal weekly traffic pattern — most teams use one to two weeks. A shorter window risks missing a day-of-week or traffic-source pattern that only shows up over a full cycle.

Can I just point the old vendor's CRM fields at the new vendor's data?

Avoid it. Two vendors rarely define "match" or format company/domain fields identically, and overwriting the old fields in place makes it impossible to tell later which vendor produced a given historical record. Use new, clearly labeled fields instead.

What if the new vendor's match rate looks lower during the parallel-run window?

Do not assume the new vendor is worse before checking causes in the same order as any other match-rate drop — see the match-rate diagnostic checklist. A lower number during a short comparison window can also reflect a temporary install or consent-configuration issue with the new tag rather than the vendor itself.

Should I tell sales when a vendor switch is happening?

Yes, briefly. Let the team know alerts may look different (field names, formatting, or volume) during the parallel-run window so nobody assumes the old vendor is simply broken.

Claim ledger

Claim	Source-backed boundary	Last checked
HubSpot's import tool maps uploaded columns to CRM properties, which is the relevant mechanism for bringing an old vendor's exported data into HubSpot.	Official HubSpot import-tool documentation.	2026-09-16
A same-vendor rebrand (Dealfront to Leadfeeder, effective March 24, 2026) still required customers to update login URLs, allowlist a new email domain, and learn renamed features, even with pricing and data unchanged.	Official Leadfeeder rebrand FAQ.	2026-09-16
GTM Preview and Tag Assistant support confirming a new tag fires correctly before an old one is removed.	Official GTM preview/debug documentation.	2026-09-16
HubSpot properties support creating clearly source-labeled custom fields to keep old-vendor and new-vendor data distinguishable.	Official HubSpot properties documentation.	2026-09-16