Salesloft Export and Migration Checklist

Define the full Salesloft exit boundary

This page owns the incumbent-platform exit from decision through decommission. It is distinct from the Salesloft cadence migration test, which validates target cadence behavior; Outreach versus Salesloft, which supports selection; and the sales engagement platform guide, which builds a shortlist.

Write a charter naming the source tenant and edition, destination, business units, countries, CRM, identity provider, email/calendar providers, dialer, meeting recorder, warehouse, BI, consent master, archive, contract end, renewal notice, legal holds, freeze, cutover, rollback window, deletion target, and signatories. Define which system may send at each minute of cutover.

This is based on public documentation reviewed August 8, 2026. We did not access a Salesloft tenant, inspect a contract, call its API, or verify a support-assisted export. Exact availability, limits, fields, history, retention, and assistance require written buyer/vendor confirmation.

Inventory every artifact, owner, and dependency

Create one inventory row per object class with business owner, source authority, count, unique key, relationships, sensitivity, retention, export method, destination, acceptance test, and status. Include:

• Identity: users, roles, teams, permissions, SSO assignments, service identities, API clients, tokens, inactive users, and ownership mappings.
• Endpoints: mailboxes, aliases, calendars, phone numbers, dialer/provider IDs, meeting settings, recording state, and send windows.
• Master data: People, Accounts, opportunities, owners, stages, tags, personas, custom fields, CRM IDs, parent-child and person-account links.
• Content and work: cadences and versions, steps, templates, snippets, variables, schedules, task queues, priorities, active memberships, due state, and automation rules.
• History and controls: emails, recipients, replies, bounces, calls, meetings, notes, tasks, activities, outcomes, recordings, audit evidence, suppression/do-not-contact, consent source/time/scope, complaints, and deletion state.

Record upstream and downstream consumers. A CRM may own identity and consent while Salesloft owns cadence execution. A warehouse may preserve reporting history that the target cannot import. The CRM migration checklist applies only if CRM authority itself changes.

Label portability before designing the target

Assign each artifact one evidence-backed label: documented exportable, with an opened official source; buyer verified, proven in the contracted tenant; partial/reconstruct, where semantic loss is documented; contract/support dependent; or unavailable. Store source URL, admin evidence, fields, format, limits, request lead time, and test date.

Salesloft publishes an official Export People help entry, but the public crawler exposed limited details. It cannot support a claim that the entire instance, every People field, or related history is exportable. Similarly, the official cadence-membership API exposes membership, Person, Cadence, call, and state concepts; endpoint presence does not establish bulk portability or destination fidelity.

Do not flatten unavailable relationships into free text and call the result complete. Preserve the source ID, destination ID, parent/child keys, event/recipient keys, owner mappings, and transformation. Keep derived metrics separate from underlying events.

Freeze contract, API, rate, and retention constraints

Review the order form, master agreement, DPA, privacy/security terms, API terms, support plan, export rights, assistance fees, rate/volume limits, renewal and termination notice, post-service access, retention, backup deletion, legal hold, subprocessor treatment, and evidence promised after deletion. The executed documents control.

Salesloft’s published DPA addresses processing duration and deletion or return after termination. It does not prove the field-level export, response time, or deletion evidence in a specific agreement. Get dates and responsibilities in writing before contract expiry.

Build an extraction budget per endpoint/object: page size, calls, rate window, retry/backoff, expected rows, attachments/media, duration, delta watermark, and contingency. Test permissions with a least-privilege identity. Never schedule the only full extract inside the final hours of access.

Stop active sends and capture the final delta

Before freeze, export an active-work register: Person/Account/CRM IDs, Cadence and version, current step, pending state, next due time, sender/mailbox, open task, reply/bounce, meeting, suppression, owner, and disposition. Ban new memberships and content/config changes.

Choose complete-in-source, cancel, or transfer for every active membership. Do not recreate a pending email blindly: wait time, thread, reply, opt-out, bounce, owner change, or local send window may make it unsafe. Confirm the live tenant controls for removing People from cadences, marking do-not-contact, and deleting records. Capture approved evidence before destructive actions, and test whether deletion also removes associated metrics in a non-production sample.

After permitted work settles, stop sending under a named owner and take a final delta from the last immutable watermark. Reconcile baseline plus deltas to the frozen source counts before importing target data.

Preserve immutable exports and checksums

Store raw exports unchanged in approved encrypted storage. Record tenant, requester, method, parameters, time zone, watermark, schema/version, file names, byte sizes, row counts, timestamps, errors, exclusions, support tickets, and cryptographic checksums. Transform only working copies.

NIST defines data integrity as protection against unauthorized or accidental change, destruction, or loss across storage, processing, and transit. Its SP 1800-25 practice guide emphasizes knowing and protecting records, configurations, applications, and customer data. These are general control references, not certification.

Profile every file: counts, nulls, distinct IDs, duplicate keys, min/max timestamps, enum values, orphan keys, invalid encodings, truncated rich text, missing attachments, and source/destination aggregate totals. Sample UI records against raw files before transformation.

Stage a golden set in the destination

Build a stratified golden set spanning active/inactive users, teams, common/custom fields, parent accounts, duplicate People, nulls, long text, Unicode, various cadence versions and states, completed/cancelled tasks, replies, bounces, calls, meetings, notes, CRM associations, suppression, consent, attachments, and old history. Use synthetic cases for anything that might send.

For each case define expected destination values, IDs, relationships, history, owner, approved transformation, forbidden side effects, and evidence. Import identities and parents first, then master data, suppression/consent, content, relationships, history, and finally only approved active work. Keep all target sending disabled.

Inject invalid picklists, missing parents, inactive owners, duplicate CRM IDs, permission loss, rate limits, partial batches, timeouts, retries, and replay. Pass the narrower cadence acceptance test before authorizing any target cadence.

Reconcile counts, fields, edges, and history

Run a full outer join by immutable source ID and mapped destination ID. Classify source-only, destination-only, matched/equal, matched/different, approved transformation, duplicate, orphan, quarantined, and excluded-with-reason. Report:

• Record reconciliation = accepted equal or approved-transformed records ÷ eligible source records.
• Field fidelity = correct required destination values ÷ eligible required values.
• Edge reconciliation = correct required relationships ÷ eligible source relationships.
• History completeness = required events present once with required metadata ÷ eligible source events.
• Duplicate rate = unintended extra destination records ÷ eligible source records.
• Suppression preservation = correctly non-actionable suppressed People ÷ eligible suppressed People.

Break results down by object, date range, team, region, owner status, cadence state, and sensitive class. Keep original and corrected values with reason and approval. The CRM data-quality guide assigns post-migration ownership.

Dual-run, cut over, and prove rollback

Dual-run a limited team with only one system allowed to send. Keep the other shadow-only. Compare memberships, tasks, send/reply/bounce state, meetings, CRM activity, ownership, suppression, and daily deltas. Monitor unintended triggers continuously.

The cutover runbook should specify final source stop, delta extraction, checksum, transformations, import order, reconciliation, endpoint connection, smoke tests, approval, monitoring, and abort authority. Hard gates include zero prohibited sends, complete suppression, accepted critical relationships and history, stable CRM IDs, correct permissions, and visible failures.

Rollback must reconcile destination-created replies, meetings, owner/consent changes, and CRM writes before any source restart. Preserve source licenses/configuration for the approved window; export the target delta; reapply only accepted state; and prevent duplicate work. Rehearse the procedure using the golden set.

Decommission and collect deletion evidence

After observation and sign-off, revoke mailboxes, calendars, dialer/meeting connections, SSO assignments, API clients, tokens, service identities, webhooks, CRM integration, warehouse feeds, support access, and shared exports. Archive approved raw exports, schemas, mappings, checksums, reconciliation, exceptions, incidents, approvals, and required audit evidence.

Execute contractual return/deletion while respecting holds and retention. Track production, backups, subprocessors, recordings, support artifacts, exported copies, responsible owner, completion date, exceptions, and vendor evidence. Cancelling a license is not deletion proof.

Close rollback only when the destination survives the declared window and every material exception has an owner. Record archive access, destruction date, invoice closure, and retest triggers.

Apply the worked example and hard gates

This fictional example is not Salesloft performance. A migration includes 2,000 eligible records, 1,000 required relationships, and 8,000 required historical events. The target accepts 1,980 records, 980 relationships, and 7,800 events. Five unintended duplicates appear. All 150 suppressed People remain non-actionable.

If precommitted gates require 100% critical edges, 99.5% required history, zero duplicates, and 100% suppression, the run fails. Quarantine it, correct mapping/retry behavior, rerun the same seeds, and retain both reports. Do not lower a gate after seeing the outcome without named risk acceptance.

Print the checklist and calculate TCO

Migration TCO = source overlap + destination license/setup + export/support + engineering/mapping + target import + validation/reconciliation + training/change + monitoring + remediation/incident reserve + archive/retention + decommission/deletion. A fictional transition of $25,000 overlap, $35,000 destination setup, $20,000 engineering, $12,000 testing, $8,000 training, $5,000 archive/decommission, and $10,000 contingency totals $115,000. Replace every input with signed quotes and loaded labor.

The acceptance packet should name versions, dates, counts, portability labels, contract dependencies, exclusions, reconciliation, incidents, rollback, deletion status, TCO, and signatories. No undocumented export capability should appear as fact.