By Siddharth GangalA Salesloft cadence migration should pass a pre-cutover acceptance test before the old or new system is trusted to send. Inventory every asset and relationship, map fields and statuses, preserve suppression and active-person state, test mailbox/calendar/CRM authority, seed failures, rehearse a bounded dual-run, reconcile source to target, and prove rollback. Only then approve cutover and decommission.
Direct answer. Freeze new cadence changes, export or otherwise capture a versioned source inventory, recreate only approved target objects, migrate a consented test cohort, compare counts and fingerprints, inject edge cases, and require zero unauthorized or duplicate sends. A clean template count does not prove a safe migration.
This is a buyer-controlled migration method, not a Salesloft review, comparison, alternatives list, or claim that Salesloft automatically migrates every object. We reviewed public documentation on August 8, 2026 but did not access a customer tenant or execute a migration. Confirm object-level export, API, support-assisted extraction, import, retention, and deletion for your contracted package, region, connector, and destination.
Define the Salesloft migration boundary
This page owns the acceptance workflow between selection and cutover. The Salesloft review owns broad fit and features. The Gangly versus Salesloft comparison and Outreach versus Salesloft own vendor comparisons. The sales-engagement platform guide owns category selection, while the cadence-building guide owns message and step design. This guide assumes a destination has been selected and asks whether migration is safe.
Write a migration charter with source, destination, business owner, technical owner, data owner, security/privacy approver, CRM authority, communication owner, eligible users and regions, in-scope dates, source-of-truth rules, maintenance window, cutover decision, rollback time objective, evidence retention, and decommission owner. Explicitly list what will not migrate.
Do not infer portability from product-page wording. Salesloft’s current MSA says its services can exchange customer data with third-party services, but third-party services remain separately governed. That is not an object-level guarantee. Obtain a written portability matrix for your actual tenant and decide whether each item will be directly transferred, transformed, rebuilt, archived read-only, retained under contract, or intentionally excluded.
Inventory every asset, rule, owner, and link
Build the inventory before changing either system. Give every item a stable source ID, type, name, version or updated time, owner, scope, dependency, active state, extraction method, target treatment, checksum or normalized fingerprint, reviewer, and exception. Screenshots help with review but cannot replace machine-readable values and relationships.
| Inventory family | Capture | Preservation question |
|---|---|---|
| Cadence assets | Team/personal cadence; steps; order; delays; business days; time zones; channels; variants; templates; snippets; attachments; links | Can the destination express the same logic, and who approves a semantic change? |
| Rules and state | Entry/exit; reply and bounce handling; out-of-office; do-not-contact; stage; tags; ownership; task state; completion; pause | Which source is authoritative at freeze and at cutover? |
| People and accounts | IDs; CRM IDs; contact values; account; owner; assignee; cadence and current step; last/next action; suppression | How are duplicates, shared contacts, subsidiaries, and missing IDs resolved? |
| History | Emails, calls, tasks, dispositions, replies, bounces, meetings, notes, membership events, timestamps, actor, original IDs | Will it be migrated, archived, linked, or excluded—and remain auditable? |
| Authority and integration | Mailbox, sender domain, calendar, dialer, CRM connection, integration user, field mapping, webhook/API, SSO, roles | What can read, write, send, enroll, delete, retry, or override? |
| Analytics and governance | Definitions, filters, dashboards, experiments, retention, consent, audit, legal hold, export, deletion | Can historical and post-cutover metrics be compared without pretending definitions match? |
Fingerprint normalized content rather than comparing names alone: step type + position + delay + template body + subject + variant + exit rule. Resolve links and attachments separately because a copied template may still point to a source-hosted asset, old booking page, wrong unsubscribe path, or retired tracking domain.
Map fields, statuses, people, and history
Map meaning before mapping columns. For every source field and status record data type, allowed values, null behavior, source authority, target field, transformation, validation, conflict rule, write direction, rollback value, and owner. Keep “unmapped” visible; never convert unknown to a plausible default merely to complete an import.
Salesloft’s People import documentation describes mapping CSV headers to Salesloft fields, assigning owners, matching existing records, and optionally adding People to team Cadences using a Cadence ID. It also distinguishes owner from cadence assignee. Test those distinctions on a small import. The page does not establish that templates, personal cadences, membership progress, or full activity history are automatically portable.
Create explicit crosswalks for source person status, cadence state, current step, task state, bounce, reply, unsubscribe, do-not-contact, owner, assignee, account, contact, lead, opportunity, and deleted/deactivated user. If source and target semantics differ, preserve the original value and apply a new normalized value with transformation version and reviewer.
For templates and snippets preserve text, subject, formatting, dynamic-field names, fallback behavior, links, attachments, variants, owner, sharing scope, last update, and approval status. Render with a seeded person before approval. A syntactically successful import can still expose an empty personalization field or use the wrong owner’s calendar.
History needs its own decision. If destination import is unavailable or unsuitable, create a permissioned immutable archive keyed by source person, CRM record, cadence, activity, actor, and timestamp, with a documented lookup path. Never describe archived history as migrated. Test that retention and deletion obligations still reach both live and archive copies.
Protect active people and suppression state
Active people are the highest-risk migration population. Snapshot every person currently enrolled, paused, scheduled, replied, bounced, opted out, marked do not contact, awaiting a task, or recently contacted. Record source membership, current step, next action/time, last contact, reply/bounce state, owner, assignee, CRM state, and suppression reason.
Salesloft’s People actions documentation describes adding People to a cadence or a selected step, removing them from cadences, updating owner and stage, and marking a Person do not contact. Treat these as controlled admin actions, not evidence of an automated cross-system migration. Verify permissions, batch behavior, history effects, and the package actually deployed.
Before the delta freeze, choose one system as the only sender for each cohort. During dual-run, the second system remains send-disabled or receives only synthetic/internal addresses until accepted. Build a global suppression union from source, CRM, mailbox, legal/privacy system, bounce list, and destination. The strictest active restriction wins until an authorized owner resolves a conflict.
Never restart an active person at step one by default. Map to continue, pause for review, complete, or exclude. Require human approval when the exact source step cannot be represented, the prior touch is missing, the next message would repeat content, ownership changed, or an opt-out arrives after the snapshot.
Test mailbox, calendar, and CRM authority
Separate connection from authority. A green OAuth state does not prove correct sender, calendar, CRM record, or permissions. Build an authority matrix for read person/account/opportunity, write fields and activities, enroll, send, call, book, update ownership, delete, export, and administer. Name the account, token owner, scope, allowed object/field, approval, audit location, rotation, revocation, and fallback.
Test mailbox and calendar with internal addresses: send identity, alias, reply threading, bounce, unsubscribe, out-of-office, time zone, business hours, booking link, reschedule, cancellation, calendar ownership, deactivated user, expired token, and revoked consent. Keep sender-domain and mailbox warm-up/reputation decisions outside the migration acceptance score unless the cutover changes them; if it does, make them a separate hard gate.
Test CRM reads and writes in a sandbox: correct lead/contact/account/opportunity association; allowed field direction; concurrent human edit; validation rule; picklist; required field; duplicate; merge; deleted record; renamed field; rate limit; timeout; replay; and partial failure. Use CRM integration best practices for the broader governance pattern.
Default destination writes and sending off. Enable the smallest permission needed for one test, inspect audit and rollback, then expand. A migration is not accepted if the team cannot revoke a token, stop sending, identify the actor, or reverse an unintended write within the declared objective.
Seed migration and integration edge cases
Seed combinations that ordinary happy-path testing misses. NIST’s work on combinatorial testing supports deliberately covering interactions among parameters. Build a compact matrix across identity, ownership, cadence, suppression, integration, and timing rather than testing each dimension only in isolation.
Include: same email with different CRM IDs; same CRM ID with changed email; blank email with phone; unicode name; duplicate account; parent/subsidiary; contact plus lead; two active opportunities; owner deactivated; assignee different from owner; personal versus team cadence; missing template; unsupported step; empty dynamic field; link redirect; attachment unavailable; person mid-step; late reply; bounce after snapshot; opt-out during freeze; meeting booked; concurrent CRM edit; invalid picklist; token revoked; timeout before and after write; replayed event; reordered event; partial import; and clock/time-zone boundary.
For each seed specify initial source state, expected target state, prohibited side effect, observation, evidence, cleanup, and result. Do not repair a failure manually and then mark the automated path passed. Preserve first-run evidence and retest the corrected version.
Run a controlled dual-run and delta freeze
Dual-run should compare behavior without allowing duplicate external contact. Start with a historical replay or synthetic cohort. Then use consenting internal recipients. Only after those pass should a small real cohort move, with one sender of record and destination messages held for approval. A “dual-run” in which both systems independently send to the same prospect is not a safe comparison.
Set a delta freeze time. After it, cadence edits, templates, ownership, memberships, suppressions, CRM mappings, and connection changes require a logged exception. Extract a baseline, migrate, then capture deltas at defined intervals until the source stops changing. Assign every delta an ID, event time, source, target treatment, reviewer, and reconciliation status.
Compare task generation, due time, rendered message, sender, recipient, step progression, reply/bounce/opt-out behavior, CRM activity, owner, and association. Use the same time zone and business-day definitions. Where systems cannot express identical rules, decide the acceptable target behavior before testing; do not call a semantic change a fidelity pass.
Reconcile with explicit formulas and gates
Reconcile records, relationships, content, and behavior separately. Inventory coverage equals inventoried in-scope objects divided by discovered in-scope objects. Mapping completeness equals approved mapped fields/statuses divided by in-scope fields/statuses. Reconciliation rate equals accepted matched target records divided by eligible source records. Preservation rate equals accepted preserved relationships or items divided by in-scope relationships or items.
Unexplained delta equals target count − accepted source count − approved additions + approved exclusions, with the signs documented for your report. Duplicate rate equals unintended duplicate targets divided by eligible source entities. Suppression preservation equals correctly restricted target people divided by restricted source people. Never blend these into one number before examining failures.
Illustrative example, not a Salesloft result: a synthetic source has 120 eligible people. The target has 118 accepted matches, one approved exclusion, one missing person, and two unintended duplicates. Reconciliation is 118 / 120 = 98.3%. The target row count can still appear to be 120 because duplicates mask the missing record. If 15 people are suppressed and all 15 remain restricted, suppression preservation is 15 / 15 = 100%; the missing person still fails its own gate.
| Hard gate | Required buyer decision |
|---|---|
| Sending safety | Zero unauthorized, duplicate, suppressed, wrong-recipient, or wrong-sender external sends. |
| Identity and association | Maximum missing, duplicate, and wrong CRM-object rates; zero critical misassociation if required. |
| Active state | Every active person has an approved continue, pause, complete, or exclude decision. |
| Content and logic | Required fingerprint match or documented approved semantic difference. |
| Authority and recovery | Least privilege, audit, kill switch, retry, rollback, and incident workflow pass. |
| Privacy and retention | Suppression, access, archive, deletion, and contract controls approved by accountable owners. |
Prove rollback before decommissioning
Rollback is a tested procedure, not a backup checkbox. Define the trigger, decision maker, maximum decision time, systems stopped, destination writes reversed, source state restored, deltas replayed, messages prevented, CRM reconciled, users notified, and evidence retained. Rehearse with a bounded cohort and time it.
Before cutover, preserve a source snapshot, destination pre-state, mapping version, connection/permission state, and tested restoration path. If the source cannot safely resume from its snapshot, say so and choose a forward-recovery plan. Do not promise rollback that depends on reconstructing unexported history or on reactivating an expired contract.
Decommission only after the observation window and sign-off. Disable enrollment and sends; revoke mailbox, calendar, CRM, API and SSO access; transfer or archive approved evidence; execute contractual return/deletion; remove secrets and integrations; update runbooks; preserve audit/legal-hold material; reconcile invoices; and assign residual exceptions. Salesloft’s published DPA discusses processing instructions and return or deletion after termination, but the executed agreement and applicable obligations control. The UK ICO’s accuracy guidance also emphasizes reasonable steps around inaccurate personal data and source records; it is jurisdiction-specific guidance, not a universal migration rule. Have qualified owners review this step.
Score the migration and calculate TCO
Keep hard gates outside the weighted score. After gates pass, score inventory and mapping 20, people/membership/suppression 20, content and cadence behavior 15, CRM and identity integrity 15, mailbox/calendar authority 10, history/archive/audit 10, operational recovery 5, and three-year economics 5. Rate one to five using test evidence, multiply by weight, sum, and divide by five for a score out of 100.
Full migration TCO equals source overlap and extension + destination licenses and required packages + vendor/professional services + extraction/API/support + inventory and mapping + rebuild and transformation + double review + sandbox + mailbox/calendar/CRM work + security/privacy/legal/procurement + archive + testing and reconciliation + rep/admin training + lost productive time + correction and incidents + rollback reserve + monitoring + decommission and deletion − systems and labor demonstrably retired.
Approve only the bounded population, assets, integrations, and use cases that passed. Publish the final inventory counts, approved exclusions, mappings, exceptions, acceptance evidence, rollback result, unresolved risk owner, and revalidation trigger. The defensible conclusion is not “the migration worked.” It is: “Version X of this source scope reconciled to version Y of the target under these predeclared gates, with these exclusions and a tested recovery path.”