Sales Automation Platform Migration Checklist

A sales automation platform migration moves more than workflow definitions. It moves identities, authority, credentials, triggers, rules, state, schedules, queues, retries, evidence, CRM associations, and suppression truth. Inventory and classify those artifacts, prove target behavior with golden events, and permit only one system to create each side effect during cutover.

This checklist owns full automation/orchestration exit and cutover. Use a sales workflow audit to decide what should exist, the CRM migration checklist for bulk record transfer, and the cold-email checklist for mailbox, domain, and sender-specific controls.

Define the automation migration boundary

Write the ownership boundary before exporting anything. Name source and target tenants, environments, regions, editions, contract dates, data controller/processors, system of record, business owners, technical owners, approvers, security/privacy reviewers, incident owner, cutover commander, rollback authority, and deletion approver.

Draw the path: source event → trigger → conditions → enrichment/lookups → actions → queues/retries → channel or CRM side effect → logs/alerts → human approval/exception. Mark every system that can send, enroll, create tasks, change fields, assign owners, update stages, invoke webhooks, or suppress future action. The migration is complete only when each authority has exactly one approved home.

Record exclusions: historical analytics that remain reference-only, retired automations, unsupported regions, manual processes, and adjacent systems not changing. Do not use migration as silent permission to expand data collection or action scope.

Inventory every artifact, owner, and dependency

Create one row per artifact—not one row per named workflow. Inventory users, service accounts, roles, teams, connections, OAuth grants, API keys and other credentials; triggers, rules, branches, conditions, actions and subflows; sequences, templates, snippets and assets; custom fields, enumerations, mappings and transforms; webhooks, endpoints, schemas and signatures; schedules, time zones, calendars, queues, concurrency, rate limits, retries, timeouts and dead-letter paths; logs, alerts, dashboards, exceptions, approvals and audit records.

Add source ID, stable business key, version, status, owner, purpose, upstream/downstream dependencies, input/output schema, read/write authority, secret reference—not secret value—data classification, suppression/consent dependency, retention, last execution, volume, failure route, target ID, migration method, test case, rollback and disposition.

Include CRM record IDs and association logic, campaign/list membership, active sequence state, pending schedules, queued work, retry state and delayed events. A workflow definition without runtime state can still resend, skip, or mutate the wrong record after restart. Use the CRM integration controls to document object, field, direction, permission, conflict, audit, and rollback authority.

Label portability and rebuild risk

Label every item exported, reconstructable, reference-only, or non-portable. “Exported” means the vendor-supported artifact can be retrieved with semantics intact. “Reconstructable” means the team can rebuild it from documented logic and tests. “Reference-only” preserves evidence or history but will not execute. “Non-portable” needs a retirement, coexistence, or substitute decision.

Official examples show why labels must be specific. HubSpot’s Workflows API documents workflow fetch/create/delete operations and scope requirements, while also carrying beta caveats. Salesforce documents retrieving flow metadata with Metadata API. Neither source proves universal cross-platform portability of credentials, runtime history, proprietary actions, approvals, or execution semantics.

For each reconstructable item, write a target logic specification independent of either UI: event schema, predicate truth table, ordering, action contract, authority, idempotency key, retry/timeout limits, exception path and acceptance tests. Screenshots help review but are not executable specifications.

Freeze snapshots, deltas, and authority

Take a full snapshot, announce a change freeze, then capture a final delta. Export definitions, mappings, memberships, pending state, IDs, logs, approvals, permissions and configuration with timestamps, counts, hashes where practical, source version and export method. Store encrypted evidence with access and retention controls.

During rebuild, the source remains production authority and the target remains disabled, read-only, draft-only, or connected to sinks that cannot create real side effects. Record every post-snapshot change in a delta register: who changed what, why, approval, source version, target mapping and retest. Freeze new logic before cutover; emergency changes follow the same record and approval process.

NIST’s configuration change control provides the durable pattern: authorize, document, implement, test, review and dispose of changes. It is a governance reference, not proof that a vendor migration is safe.

Replay golden events and inject failures

Replay a frozen golden-event corpus in shadow mode. Include ordinary records plus missing fields, nulls, stale values, conflicting sources, duplicates, merged/deleted records, owner change, inactive user, revoked consent, suppression, wrong timezone, boundary timestamp, out-of-order and duplicate events, delayed webhook, malformed payload, permission loss, expired token, rate limit, timeout before/after action, dependency outage and partial batch.

For each case, declare expected trigger/no-trigger, branch, lookup result, action, target, fields, owner, schedule, audit entry, alert and final state. Compare source and target traces without allowing the target to send or mutate production. Review both false actions and missed actions; a workflow that produces the same count through different wrong records has not matched.

AWS explains why retry tests matter: idempotency tokens can make repeated mutations avoid duplicate side effects, while its retry guidance recommends bounded backoff and jitter. Do not label a target idempotent until retries after ambiguous failures reproduce one intended action.

Reconcile counts, logic, edges, and events

Reconcile artifacts, graph edges, logic, state, and observed events. Artifact reconciliation compares expected versus accepted users, roles, connections, workflows, templates, fields, mappings, webhooks, schedules, queues, alerts and approvals. Edge reconciliation verifies every upstream trigger and downstream action. Logic reconciliation evaluates truth-table cases, order, time zones, null handling and transforms.

Event reconciliation uses stable source event, business record, target execution and side-effect IDs. Calculate accepted matches / expected, but publish missing, duplicate, extra, misrouted, late, failed and unknown separately. Reconcile in both directions: each eligible source event should have its expected target decision, and each target action should trace to one eligible source event.

Set hard gates for suppression, prohibited recipient action, unauthorized fields, wrong record/owner, duplicate send/task/write, missing approval, invisible failure, unrecoverable state and audit gaps. A high aggregate rate cannot compensate for one critical side effect.

Canary and dual-run without double action

Dual-run decisions, not side effects. In shadow mode both systems may evaluate the same event, but only the source acts. In canary, assign mutually exclusive authority by deterministic record cohort, region, workflow, channel or time window. Store the authority decision outside ambiguous UI labels and reject an event if both systems claim it.

Start with internal/synthetic records, then a low-risk canary. Observe queues, schedules, exceptions and delayed retries across at least the normal operational boundary relevant to the workflow. Reconcile continuously. Do not “race” systems and deduplicate afterward; sends, stage changes and external webhooks may be irreversible even when duplicate CRM rows can be deleted.

Cut over with a kill switch and rollback

Cutover is an authority change with a tested reverse path. Stop new source enrollment, drain or quarantine queued work, capture the final delta, reconcile, disable source triggers/actions, enable the target’s approved scope, run probes, and watch declared health/incident measures. Name a go/no-go approver and time-boxed rollback window.

The kill switch must stop new target actions without deleting evidence. Rollback restores the source version, connections and authority; disables target triggers and queues; identifies target-created side effects; corrects CRM state; and replays only proven missing events. Rehearse it before the production window. Use the automation change-control record for approvals and incident exceptions.

Decommission, revoke, delete, and retain evidence

Decommission only after acceptance and rollback expiry. Disable schedules, triggers, webhooks, integrations, agents and service users; revoke OAuth grants, tokens, API keys and secrets at both ends; remove network access; stop billing; export final logs and audit; resolve queues/exceptions; obtain deletion or retention evidence; and update inventory, runbooks, diagrams, owners and incident contacts.

Retain only approved records for the required period. Verify backups, replicas, sandboxes, exports, support copies and subprocessors under the applicable contract and policy. Deletion confirmation is evidence of a request/process, not a universal claim that every underlying copy disappeared instantly. Test that callbacks and late webhooks from the retired platform cannot regain authority.

Apply the worked example and calculate TCO

Synthetic example—not a vendor result: an inventory contains 120 workflows, 24 templates, 18 mappings, 10 webhooks and 28 users: 200 artifacts. The target accepts 192, five are reference-only and three remain unresolved, so accepted reconciliation is 192/200 = 96%. Because unresolved suppression logic is a hard-gate failure, cutover does not proceed despite the aggregate rate.

A 300-event golden corpus expects 180 actions and 120 no-actions. The target produces 179 correct actions, one missed action, 119 correct no-actions and one prohibited action. Overall agreement is 298/300 = 99.3%, yet the prohibited action rejects the release. Report class results and critical errors, not only one percentage.

Migration TCO = target licenses and usage + implementation/rebuild + export/API costs + connectors + overlap + security/legal/privacy + testing and review + admin/user training + monitoring/reconciliation + incident/rollback reserve + data retention + decommission and exit − source costs demonstrably retired. Model low/base/high volumes, contract overlap, non-portable rebuilds, premium API/support, and delayed exit.

Print the migration checklist

A migration is complete when the target’s bounded behavior is proven, the old platform has no residual authority, evidence is retained appropriately, and the team can explain every missing, duplicate, transformed or retired artifact.