A 6sense migration is governed by what the customer is licensed and contractually allowed to export and retain—not simply what appears in a list or CRM. Inventory every product, user, credit, derived signal, export path, integration, downstream copy, suppression state, and provenance relationship before ending access.
This page owns 6sense exit/cutover. Use the 6sense review for product fit, the 6sense data-quality test for accuracy/freshness, and account intelligence tools for replacement selection.
Define the 6sense exit boundary and rights
Build a rights register before an artifact register. Record entity, tenant/environments, products and add-ons, order forms, subscription term, renewal/cancellation dates, seat types, administrator roles, geography, contact/company/intent/scoop/enrichment/search/API/export credits, included fields, export destinations, CRM connectors, usage limits, permitted use, retention/use after termination, deletion/return, support, delivery fees, audit rights and subprocessor/security documents.
6sense documents S3 delivery for eligible Data Packs and audit-log customers, enabled through the customer-success path. That bounded delivery option does not establish entitlement to every pack or log. The executed subscription, order, API, data-pack, and privacy terms control.
Name commercial owner, RevOps/data owner, CRM admins, security/privacy/legal reviewers, migration owner, rollback authority, deletion approver and evidence custodian. Define which upstream/downstream system owns contacts, companies, suppression, consent, enrichment fields and activity during each phase.
Inventory every artifact, credit, and authority
Create one row per artifact or relationship. Inventory users, teams, roles, invitations, SSO/SCIM, service/API users, credits and consumption; saved searches, filters, lists, tags, notes, custom fields/views; contacts, companies, locations, hierarchies and firmographic/technographic/contact attributes; intent topics/signals, scoops/news/events, scores or recommendations, provenance/source and timestamps.
Add enrichment settings, field mappings, overwrite/conflict rules, CRM objects and associations, sync states and exclusions; Engage/sequences/templates/tasks/calls/emails/meetings, dispositions, replies and activity history where purchased; exports, files, field sets, destinations and job/status logs; API credentials, applications, requests, bulk jobs, results, errors and usage; webhook/workflow definitions; suppression, do-not-contact, opt-out/consent evidence, retention, deletion, audit and admin history.
Capture 6sense/source ID, CRM ID, stable business key, contact-company-list-user/activity relationships, parent/subsidiary, owner, product/SKU, data classification, provenance, observed/updated/exported times, field schema, format, rights basis, credit cost, checksum, target ID, transformation, validation, rollback and disposition. Follow the CRM migration checklist without assuming a CRM copy contains list logic, intent history, provenance, credits or admin configuration.
Label portability without assuming a complete export
Label each item documented export, support/contract-dependent, reconstructable, or unavailable. A documented export needs current official/tenant evidence, role, SKU, field scope, format, credit/use effect, limits and tested sample. Support-dependent needs written delivery scope, schema, history, relationships, timing and fee. Reconstructable identifies an approved upstream/downstream source and rights. Unavailable requires owner acceptance, retirement or coexistence.
6sense’s Data Packs documentation names structured CSV extracts for web visits, media, pixel performance, segments, predictive, firmographic, technographic, and keyword-intent data, with CRM-ID or MID variants and stated delivery cadences. The FAQ says partner data such as Bombora, TrustRadius, and G2 is not included. These bounded paths do not establish export of models, configuration, raw event history, permissions, or every audit/deletion record.
6sense also documents CSV downloads for the Keywords Performance Report and Website Visits Report. Treat each report as its stated fields and permission boundary, not a tenant backup. Label model weights/training state, orchestration configuration, raw histories, permissions, complete audit history, and deletion evidence support/contract-dependent until authenticated docs and reproduced files prove otherwise.
Request the SKU and export manifest
Request a SKU-by-artifact manifest before access changes. Ask 6sense to identify exports/API paths for every row; required role, permissions, credits and rate limits; available/custom fields; file/API format, pagination and bulk-job lifecycle; stable IDs and relationships; full versus incremental history; provenance and update times; deleted/suppressed record behavior; errors/retries; expiration; delivery encryption; support timing and cost.
Ask which data is customer-provided, licensed 6sense data, third-party, supplemental, derived, inferred or aggregated; what may be retained and used after termination; what must be deleted; and how downstream CRM/data-warehouse copies are treated. Obtain quote/contract language rather than relying on sales statements. Privacy/legal owners decide applicability; this is not legal advice.
Freeze a snapshot and final delta
Take a full snapshot, freeze configuration, then capture the final delta. Record tenant, requester, export/API method, job IDs, filters, field set, product/SKU, credits used, as-of time/timezone, schema version, pages/files/rows/bytes, checksums, encryption and secure location. Keep immutable originals beside the manifest.
Freeze users/roles, lists/searches/tags, custom fields, CRM mappings, overwrite rules, suppression, topics, integrations, API apps, webhooks and Engage assets. Log approved changes. Capture every new/changed/deleted list membership, contact/company field, intent/scoop signal, note/tag, CRM sync result, activity, suppression/consent state, export and API job since the first snapshot.
Reconcile counts, fields, edges, and history
Reconcile counts, fields, edges, history, and provenance separately. Count by object, list, status, owner, source, country, SKU and time period. Field tests cover nulls, enums, multivalue data, Unicode, phones/emails, timestamps, locations, hierarchy, confidence/provenance and overwritten CRM values. Edge tests verify contact-company-location, parent-child, list membership, user ownership, CRM association, intent/scoop-company and activity-person/company.
History tests verify earliest/latest events, ordering, prior values, deletion/suppression changes, source and update time. Reconcile manifest-to-delivery and delivery-to-manifest. List missing, duplicate, orphaned, extra, truncated, stale, rights-restricted and unknown items instead of hiding them in one completion rate. Checksums prove file integrity, not semantic completeness.
Suppression and consent are hard gates. Verify prohibited records remain suppressed through target import and enrichment; a future refresh must not silently restore a prohibited phone/email. Preserve the approved evidence and provenance needed to explain each accepted field.
Stage the target and dual-run safely
Stage a representative corpus before live enrichment or CRM writes. Include contacts/companies across regions and sources; duplicates, merges, stale/conflicting fields, subsidiaries, missing identifiers, shared domains, suppressed contacts, custom mappings, partial API jobs and retry cases. Verify target IDs, relationships, provenance, permissions, list membership, CRM association, no-overwrite rules, audit and deletion.
Dual-run read/decision output first. Only one system may enrich or write each CRM object/field/cohort during a canary. Compare accepted coverage, exactness against labeled records, freshness/provenance, conflicts, suppression, CRM errors, latency, credits/usage and manual review. Data-quality results apply only to the tested corpus and belong in the separate quality canonical.
Cut over and prove rollback
Cut over authority in small, reversible scopes. Capture/reconcile the final delta; stop 6sense schedules, API jobs, workflows and CRM enrichment for the canary scope; enable target read, then approved fields; monitor; expand only after hard gates. Store field-level authority and reject events claimed by both systems.
The kill switch stops target jobs while preserving evidence. Rollback disables target writes, restores approved 6sense/CRM configuration within contractual rights, identifies target-created/overwritten fields, corrects records and replays only proven missing events. Rehearse token expiry, rate limit, timeout after write, duplicate event, owner change and merge. Use the automation migration controls for retries and queues.
Revoke, delete, and retain scoped evidence
Revoke after acceptance and rollback expiry. Disable users/service accounts, SSO/SCIM, OAuth/API credentials, CRM/data-warehouse/SEP connectors, webhooks, browser extensions, scheduled files and support access; rotate secrets; stop billing; update inventory, diagrams, runbooks, owners and incident contacts. Verify late jobs and callbacks cannot resume writes.
Request scoped tenant, downstream, subprocessor, backup, and legal-hold deletion or retention evidence under the executed agreement. Public Data Pack/report documentation does not establish a complete deletion workflow. Deletion is not proof of portability, and cancellation is not proof of erasure.
Apply the worked example and normalize TCO
Synthetic example—not a 6sense result: a manifest expects 80 users/config items, 300 lists/searches, 25,000 contacts, 8,000 companies, 4,000 intent/scoop records, 2,000 tags/notes/custom items, and 600 export/API/engagement artifacts: 39,980. Delivery/reconstruction accepts 39,750, marks 180 reference-only and leaves 50 unresolved. Accounted rate is 39,930/39,980 = 99.9%, but one unresolved suppression source blocks cutover.
Expected relationships total 62,000; 61,880 pass, or 99.8%. Publish the 120 missing edges by type and severity. A missing old list relation may be accepted; one suppressed contact attached to an active sequence is a critical failure.
Normalize annual TCO from equivalent dated quotes: subscription/minimum + seats + record/export/enrichment/intent/API credits + overages + implementation + connectors + CRM cleanup + privacy/security/legal + storage + operations/reconciliation + training + overlap + incidents/rollback + decommission/exit − retired cost. Align regions, fields, refresh frequency, permitted use, support and volume; a lower quote with fewer usable rights is not comparable.
Print the 6sense migration checklist
☐ Record executed products, SKUs, roles, credits, rights, term and use-after-exit
☐ Inventory users, lists, contacts, companies, intent, scoops, fields and provenance
☐ Inventory CRM mappings, engagement, API/export jobs, suppression and history
☐ Capture stable IDs and all relationship edges
☐ Label documented, support-dependent, reconstructable or unavailable
☐ Request schemas, fields, history, limits, credits, delivery, exclusions and cost
☐ Freeze snapshot, checksums, configuration and final delta
☐ Reconcile counts, fields, edges, history and suppression both ways
☐ Stage, dual-run with one writer, and prove rollback
☐ Revoke access and collect scoped deletion/subprocessor evidence
☐ Compare equivalent quotes with normalized TCO
A defensible 6sense exit preserves permitted data with its provenance and relationships, prevents residual enrichment authority, and states crawler and export gaps honestly—without claiming an undocumented complete export.