Apollo Export and Migration Checklist: A Controlled Exit Plan

An Apollo migration succeeds only when the team can prove four things: it preserved the records and relationships it is entitled to move, stopped active outreach safely, imported governed data without corrupting the target, and collected credible evidence for access revocation and deletion. Choosing a replacement vendor is a different job.

This page is distinct from the Apollo review, Apollo comparisons and alternatives, the Apollo data-quality test, and the vendor-neutral CRM migration checklist. It owns Apollo-specific exit inventory, documented export boundaries, active-sequence controls, reconciliation, and cutover. It makes no claim that every Apollo object is exportable.

Official documentation was reviewed on August 8, 2026. We did not execute an Apollo export for this article or receive vendor assistance. Documentation proves a described path, not your entitlement or the completeness of its output. Bind the runbook to the signed contract, plan, workspace, permissions, API access, credit balance, current help pages, vendor-confirmed exit response, and target schema.

Define the Apollo exit boundary

Direct answer. Treat Apollo as several connected systems: prospect/account data, saved records and lists, engagement assets and state, tasks and activities, conversation artifacts, enrichment/provenance, CRM synchronization, mailbox/calendar connections, user permissions, and privacy/suppression state. Each has a different export, stop, import, retention, and deletion path.

Name an executive owner, migration lead, Apollo admin, CRM owner, data steward, sequencing/mailbox owner, security owner, privacy/legal owner, target admin, and business approver. Freeze scope in a signed decision log: source workspace, target, cutoff time, excluded objects, legal holds, active outreach policy, acceptance gates, rollback authority, and destruction schedule.

Define success as reconciliation, not “CSV downloaded.” A flat contact export can preserve values while losing account relationships, list membership, owner, sequence state, task history, consent, or provenance. A target screenshot can look correct while scheduled messages remain active in Apollo. Use the sales workflow checklist to identify operational dependencies outside Apollo.

Inventory entitlements, objects, and export paths

Start with contract and entitlement evidence: order form, plan and add-ons, renewal/notice deadline, termination clause, export assistance, API entitlement, credits, rate limits, retention, data-return/deletion terms, support tier, connected CRM, mailboxes, calendar, storage, and professional services. Export permission is separately configurable; Apollo’s permission documentation includes the ability to export contact/account CSVs.

Apollo documents CSV export for selected saved records, and its list guide documents contact/account list export. These statements do not establish that sequences, templates, tasks, activity history, notes, conversations, files, provenance, audit logs, or every custom field travel in those CSVs.

Disclose full, partial, and unavailable portability

Maintain a portability register with one row per object and relationship. Use only four statuses: full when fields, stable IDs, relationships, history, timestamps, and semantics are usable; partial when material context is missing; reconstruct when an authorized alternate source must rebuild it; and unavailable when no documented/contracted path exists. Attach evidence and an approver.

CSV, API, CRM, and privacy-access exports serve different purposes and may cover different data. Apollo says API endpoints and rate limits vary by plan. Do not assume API access means every UI object has an endpoint. Query the live reference, save the endpoint/field inventory, test pagination and deleted records, and get written clarification for gaps.

Document rate limits per minute/hour/day, pagination size, credit-consuming fields, retry headers, concurrency, export row limits, job expiry, time zone, and encoding. Model completion before the contract cutoff: estimated duration = records ÷ sustainable successful records per hour + retry/reconciliation buffer. Throttling is not an excuse to remove failed pages from counts.

Separate customer-entered data, Apollo-licensed/enriched data, CRM-sourced data, and derived engagement data. Contract rights may differ. Preserve source and usage restrictions; never represent licensed enrichment as your independently collected fact. For field-quality validation rather than portability, use the CRM enrichment guide.

Stop active outreach and freeze deltas

Choose a snapshot time and a delta cutoff. Before the snapshot, stop configuration churn: new custom fields, renamed lists, sequence edits, owner changes, bulk enrichment, merges, and new integrations. Capture configuration and permissions. After the snapshot, log every permitted change in an append-only delta journal.

Active outreach is the highest-risk state. Inventory sequences and contacts by active, scheduled, paused, finished, bounced, and not-sent status, plus queued emails/tasks, mailbox, owner, and next execution time. Apollo documents that deactivating a sequence stops it for editing and that archiving marks contacts finished and deletes scheduled emails. Because archiving changes state irreversibly, use the approved pause/deactivate/finish method only after export and rehearsal.

1. Freeze new enrollments, workflows, list-to-sequence automation, and manual sends.
2. Synchronize the authoritative suppression/consent store and resolve replies, bounces, out-of-office, and meetings.
3. Export enrollment and queued-work evidence before changing state.
4. Pause/finish contacts or deactivate sequences using the rehearsed method; record actor, time, before/after counts, and exceptions.
5. Confirm connected mailboxes have no Apollo-scheduled messages and target sequences remain disabled.
6. Reconcile active source plus active target sends to zero during the cutover blackout.

Reconcile files, fields, and relationships

Write every raw export to immutable storage. Record filename, source path, query/filter, requested/start/end times, row count, byte count, encoding, delimiter, schema version, extractor version, operator, and a SHA-256 digest. NIST’s Secure Hash Standard explains hashes as message digests that detect change; a matching hash proves file identity, not semantic completeness.

Profile every file before transformation. Preserve original values and create a separate normalized layer. Validate Unicode, multiline notes, delimiters inside text, leading zeros, phone formats, time zones, daylight-saving boundaries, empty versus null, arrays, booleans, picklists, attachments, and formula-like spreadsheet cells. Quarantine malformed rows; never silently drop them.

Map and stage the target import

Build a source-to-target contract for each object, field, enum, relationship, owner, permission, status, and timestamp. Label transformations as direct, normalized, combined, split, defaulted, derived, quarantined, or dropped-with-approval. Preserve Apollo/source IDs in dedicated external-ID fields so replays are idempotent and investigations trace back. Carry the resulting exceptions into the recurring CRM hygiene audit.

Import into a sandbox or staging objects first. Begin with accounts, then contacts, then memberships/relationships, then approved history and assets. Users/owners must map before owned records. Suppression and consent state must be active before any target engagement feature is enabled. Templates and sequences should be recreated as disabled, versioned assets with human copy, timing, stop-rule, sender, and compliance review.

Seed duplicates, same-name contacts, shared domains, subsidiaries, merged companies, former employees, inactive owners, missing emails, multi-select fields, deleted records, conflicting CRM values, opted-out contacts, active customers, and open opportunities. Apollo’s bidirectional-sync guide warns that corrupt data can move in either direction. Disconnect or constrain sync during staging so a target test cannot overwrite the source or production CRM.

Run a controlled delta and rollback window

Run a delta-only dual period, not two active engagement engines. Apollo may remain read-only for validation while the target receives controlled deltas; neither sends until the approved activation. Replay the same batch, fail after a successful target write, deliver changes out of order, revoke a token, exhaust a rate window, change an owner, merge an account, and correct a suppression record. Reconciliation must close after every recovery.

Define rollback before cutover: trigger, decision owner, maximum decision time, target send stop, target records to reverse, source state that can safely resume, delta replay point, mailbox control, CRM sync direction, stakeholder notification, and evidence retention. Rollback should never reactivate suppressed people or duplicate completed touches.

Hard gates include zero unauthorized sends, complete suppression, no unapproved overwrite of CRM-authoritative fields, no unresolved critical object/relationship discrepancy, tested retry/idempotency, verified target permissions, usable export of migrated data, and a rehearsed rollback. A cosmetic template difference is not equal to a lost objection or an active scheduled email.

Collect deletion and revocation evidence

After acceptance and the legal/contractual hold check, revoke API keys, OAuth grants, CRM sync, mailbox/calendar connections, browser extensions, webhooks, SSO assignments, service accounts, and user sessions in an approved order. Preserve revocation timestamps and test that calls fail. Rotate credentials if exposure cannot be ruled out.

Submit account/customer-data return and deletion requests under the contract and applicable law, listing raw and derived objects, integrations, subprocessors, backups, logs, support copies, and retention exceptions. Apollo’s Privacy Center also documents individual access/removal requests and retention of a suppression record to help prevent a removed profile from reappearing. Do not delete suppression evidence needed to continue honoring an objection.

Collect vendor confirmation, ticket IDs, dates, scope, exceptions, expected backup expiry, legal-hold basis, and final closure evidence. “Account closed” is not equivalent to “all governed customer artifacts deleted.” Test what remains visible through revoked users, shared links, CRM, mailboxes, exports, and target systems.

Reproduce the worked migration example

Hypothetical example—not an Apollo result. A snapshot reports 10,000 eligible contacts. The export contains 9,940 rows: 9,920 unique contact IDs, 20 duplicated IDs, 40 documented privacy exclusions, and 20 failed rows. The first reconciliation closes numerically because 10,000 = 9,940 + 40 + 20, but uniqueness fails.

After removing duplicate pagination rows without discarding underlying records, the immutable raw export stays unchanged and the normalized layer has 9,920 unique contacts. Suppose the source manifest expects 9,100 contact-account edges, 2,400 list-membership edges, and 750 owner edges. The export contains 9,080 valid account edges plus 20 quarantined ambiguous edges; 2,395 valid list edges plus five missing; and 748 valid owner edges plus two inactive-owner mappings.

• account relationship recall = 9,080 ÷ 9,100 ≈ 99.78%, with 20 quarantined edges still unresolved.
• list relationship recall = 2,395 ÷ 2,400 ≈ 99.79%, with five missing edges.
• owner mapping coverage = 748 ÷ 750 ≈ 99.73%, with two explicit remapping decisions required.

These figures illustrate the formulas only. Whether they pass depends on gates set before export. If either inactive owner controls scheduled activity or one missing list is the suppression list, cutover fails regardless of the percentages.

Calculate exit TCO and print the checklist

Exit TCO = contract overlap + vendor export help + engineering/API work + credits/overages + data mapping and cleanup + sequence/template reconstruction + privacy/security/legal + target implementation + QA/reconciliation + training + dual-run operations + rollback reserve + archival and deletion evidence.

Model low, expected, and high cases for API throughput, missing portability, manual reconstruction, malformed records, support delay, and overlap months. Include the cost of maintaining engagement history in a queryable archive when it cannot be imported semantically. Do not count sunk subscription fees as savings, and do not assume unused credits are refundable.

Printable Apollo export and migration checklist

• □ Bind the plan, contract, renewal date, permissions, API limits, credits, export help, retention, and deletion terms.
• □ Inventory contacts, accounts, lists, sequences, templates, tasks, activities, notes, conversations, custom fields, enrichment/provenance, suppression, consent, and engagement history.
• □ Mark every object/relationship full, partial, reconstruct, or unavailable with official/vendor evidence.
• □ Define stable IDs, source authority, target mapping, transform, owner, and approved loss.
• □ Freeze schema/configuration; snapshot; start the append-only delta journal.
• □ Stop enrollment/sends safely; preserve status; sync suppression; prove both systems inactive at cutover.
• □ Manifest and hash raw exports; reconcile counts, IDs, fields, nulls, enums, edges, failures, and deltas.
• □ Import sandbox accounts, contacts, relationships, governance state, history, then disabled engagement assets.
• □ Inject replay, timeout, out-of-order, rate-limit, revoked-token, merge, owner, and suppression failures.
• □ Rehearse rollback; obtain business/data/privacy/security approval before activating the target.
• □ Revoke every access path; collect scoped deletion, exception, backup-expiry, and closure evidence.
• □ Archive manifests, hashes, transforms, reconciliations, approvals, exceptions, TCO, and final decision.

The safe result may include a deliberately partial migration and a governed archive. Transparency about unavailable portability is better than silently flattening operational history into a CSV that looks complete.