Clay Data Export and Migration Checklist

A Clay migration is not finished when tables become CSV files. Row values are one layer; the operating system also includes sources, column formulas, enrichment providers, waterfalls, run conditions, prompts, schedules, signals, webhooks, CRM mappings, permissions, usage history, and error behavior. A safe exit preserves the values the buyer is entitled to move and enough versioned evidence to reconstruct or deliberately retire the workflow.

Official Clay documentation was reviewed August 8, 2026. Gangly did not execute a Clay workspace export. Product behavior, plans, limits and terms can change, so bind this checklist to the contract, live workspace, permissions, provider terms, support response, and buyer-run sample.

Define the Clay migration boundary

This page owns incumbent export, reconstruction and shutdown. Use the Clay waterfall accuracy test to validate results and credit economics, the CRM migration checklist when CRM authority changes, and the sales-intelligence guide for category selection.

Define whether the outcome is archive-only, workspace consolidation, migration to another automation system, or replacement by CRM-native workflows. Freeze workspace IDs, plan, users, credits, contract/notice dates, target, archive, snapshot, run cutoff, rollback window, deletion date, legal holds and signatories. Name program, Clay, data, CRM, security, privacy, finance, target, validation and rollback owners.

Inventory workspace data, logic, dependencies, and rights

Inventory workspaces, folders, workbooks, users, roles and service identities; tables, views, stable table/row IDs, columns, types, formulas and values; enrichments, providers, waterfall order, acceptance/fallback rules, run conditions and credit costs; sources and provenance; prompts, agents, signals, sequencers, HTTP actions, webhooks, CRM mappings, logs, errors, schedules, templates and shared assets.

For every artifact record owner, ID, parent/child and input/output edges, eligible counts, authority, sensitivity, credential, provider, plan/right, export path, target disposition, retention, acceptance test and evidence. Map table-to-table sends, lookups, webhook callers, provider outputs, formula inputs, downstream CRM fields and schedules as edges. Use the CRM integration guide to label read/write authority.

Credits and third-party data rights are separate from row custody. Inventory remaining balances, recurring spend, provider-specific terms, license restrictions and fields that cannot legally or contractually be transferred. Do not treat purchased credits as universally transferable or exported provider data as unrestricted.

Use the CRM enrichment governance guide to define field provenance, freshness, confidence and overwrite rules before the target begins writing enriched values.

Label value, configuration, lineage, and history portability

Assign documented exportable, buyer verified, support/contract dependent, reconstruct, or unavailable. Store the official URL, plan, permission, format, object/field scope, relationship behavior, limits, date and sample result.

Clay’s CSV lesson says the export mirrors the table, while noting object fields may not display raw values and “run condition not met” fields can export blank. Therefore CSV proves exported displayed values only—not formulas, prompts, provider configuration, waterfall order, provenance, error logs, history or destination semantics.

Clay documents enterprise table API access and plan-dependent change-log retention in table settings. It separately explains that Clay is not a traditional general API, while webhooks/wrappers and an Enterprise people/company API cover specific jobs. Do not infer universal read/write API coverage from one enabled table.

Freeze scheduled work and capture snapshot plus delta

1. Freeze schema, formulas, providers, waterfalls, prompts, run conditions, mappings, credentials, views and permissions.
2. Inventory manual, scheduled, signal, webhook, CRM, API and sequencer writers; record queued/running/failed rows and credit-consuming work.
3. Disable schedules and incoming webhooks in rehearsed order; stop outbound HTTP/CRM actions before accepting new rows.
4. Record UTC snapshot start/end, row watermarks, table versions, credit totals and exceptions. Capture an ordered final delta for approved changes.
5. Preserve credentials and source access until extraction can be repeated and rollback expires; rotate only at the approved cutover point.

Clay’s webhook documentation describes table ingestion and plan-dependent auto-delete behavior. Passthrough rows may no longer be stored, so downstream destination evidence and webhook logs may be necessary. “Current row count” is not necessarily historical input volume.

Export immutable values, manifests, and cost evidence

Export dedicated views with explicit columns; preserve raw CSV/API JSON, screenshots/configuration records, provider manifests, formulas, prompts, conditions, schedules, mappings, errors and run logs where documented and entitled. Manifest workspace/table/view, filters, requester, UTC start/end, filename, rows, columns, schema, bytes, errors, exclusions and SHA-256. A NIST-defined digest proves file identity, not value meaning.

Clay’s credit-usage documentation describes CSV exports across workspace, integration, signal and API views. Preserve these as cost evidence; they do not prove credits are refundable or transferable. Retain immutable raw evidence and transform working copies only.

Profile duplicate/missing row IDs, blank object outputs, truncated lists, formula errors, “condition not met,” provider errors, stale results, missing provenance, orphan table edges and inconsistent CRM IDs. Store stable table, row, provider and source identifiers in a crosswalk.

Reconcile counts, fields, formulas, dependencies, and provenance

• Row reconciliation = accepted target/archive rows ÷ eligible source rows.
• Field fidelity = correct tested values/types ÷ eligible tested values.
• Formula parity = target/reconstructed formula outputs matching frozen expected outputs ÷ eligible cases.
• Dependency reconciliation = accepted provider, table, webhook, CRM and schedule edges ÷ eligible source edges.
• Provenance coverage = accepted values with required source/provider/run/time evidence ÷ eligible governed values.
• History coverage = accepted required runs/changes/errors ÷ eligible documented history.

Report denominators/exclusions by workspace, table, source, provider, workflow, owner, schedule and error state. Full-reconcile IDs, suppression, critical CRM writes, provider provenance and active schedules. Use a frozen stratified sample for high-volume values. A correct value without required source/date/confidence may still fail governance.

Reconstruct and stage the target safely

Build the target disabled. Create users/roles and credentials first, then schemas, source-ID crosswalks, formulas, provider calls, waterfalls, run conditions, prompts, mappings, webhooks and schedules. Use secrets management; never copy credentials into the migration artifact.

Seed clean and difficult cases: duplicates, missing identifiers, list/object fields, provider disagreement, waterfall fallback, exhausted credit/test quota, condition false, API timeout, rate limit, revoked token, merged CRM record, inactive owner and webhook replay. The same input must not create duplicate rows, provider charges or CRM writes on retry.

Shadow, cut over, and prove rollback

Shadow a bounded input corpus while only one platform writes production CRM or sends downstream actions. Compare row creation, formula outputs, provider selection, cost, provenance, timing, errors, retries and destination values. This is a reconstruction test, not a claim that the target is superior.

Write cutover order: source stop, final delta, manifest close, target import, reconciliation, credential switch, canary, activation and monitoring. Rollback disables target schedules/webhooks/writes, preserves target-only deltas, restores only approved source connections, prevents replay and double credits, and reconciles CRM state. Hard-stop on unauthorized data use, missing suppression, destructive overwrite, unbounded credit spend, invisible errors, lost provenance or untested rollback.

Decommission, revoke, and request deletion evidence

After acceptance/hold review, revoke Clay/API/provider credentials, webhooks, CRM OAuth, sequencers, schedules, SSO, service users, shared links, browser extensions and support access. Prove calls fail and no scheduled run continues.

Submit a contract-governed return/deletion request covering row data, prompts, logs, derived outputs, credentials, exports, backups, subprocessors, support artifacts and retention exceptions. Collect ticket, scope, completion date and exceptions. Do not equate workspace cancellation with deletion, and do not claim universal deletion timing without current official confirmation.

Apply the worked example and calculate TCO

This fictional example is not a Clay result. Of 10,000 eligible rows, 9,900 reconcile; 19,200 of 20,000 tested fields match; 475 of 500 formula cases match; 940 of 1,000 dependency edges reconcile; and 8,700 of 9,000 governed values retain required provenance.

TCO = source overlap + target licenses + export/support + engineering/reconstruction + provider/API credits + data validation + privacy/security/legal + training + shadow monitoring + remediation + rollback + archive + decommission/deletion. Missing critical CRM or suppression edges fails regardless of average.

Print the Clay migration checklist

Gangly does not make Clay formulas, history or credits portable and is not the presumed target. If evaluated downstream, keep CRM authority, provider provenance, human review, suppression, idempotency and cost limits explicit.