Salesforce → Airtable
Move contacts, companies, deals, activities, fields, owners, permissions, automation, reports, files, and integrations from Salesforce into Airtable with an explicit exception ledger and evidence-based cutover.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Salesforce
- Extensive CRM customization, ecosystem, reporting, and enterprise governance support complex businesses
- Structured ownership, status, and workflow views improve operational visibility
- Licensing, implementation, and ongoing administration are expensive and specialized
- Custom fields, automations, history, and reporting are difficult to reproduce exactly
Airtable
- Approachable relational tables combine spreadsheet familiarity with lightweight apps
- Structured ownership, status, and workflow views improve operational visibility
- Scale, automation, and permission needs can become expensive or awkward
- Custom fields, automations, history, and reporting are difficult to reproduce exactly
Airtable: Approachable relational tables combine spreadsheet familiarity with lightweight apps. This removes a major source-side concern: Licensing, implementation, and ongoing administration are expensive and specialized.
What you lose: Extensive CRM customization, ecosystem, reporting, and enterprise governance support complex businesses. What you inherit: Scale, automation, and permission needs can become expensive or awkward.
Know the shape of the move.
This timeline assumes
- Up to one million records, 500 users, and 250 active automations
- Administrators control both systems and every integration that writes CRM data.
- Stable source IDs remain on destination records for reconciliation.
- A sandbox or isolated destination pilot is available before production loading.
- The migration team records evidence for every blocking verification check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Accounts, contacts, leads, opportunities, owners, stages, activities, and selected fields | partial | critical | Core accounts, contacts, leads, opportunities, owners, stages, activities, and selected fields can move, but Salesforce and Airtable use different models, limits, identifiers, and import behavior. | Pilot every feature class, preserve source IDs, and reconcile accepted, transformed, rejected, and excluded items. |
| Apex, Flow, approvals, security model, reports, integrations, audit history, and platform apps | manual | critical | Airtable can support a deliberately reduced operating model but cannot reproduce the full Salesforce platform. | Inventory every active dependency, approve its destination disposition, and test the replacement before source writes stop. |
| Contacts and leads | partial | critical | Core people records can move, but identifiers, lifecycle models, and duplicates require transformation. | Define stable matching rules and load a representative pilot. |
| Companies and accounts | partial | critical | Account models, parent relationships, domains, and person-account behavior differ. | Create accounts before dependent records and verify hierarchy. |
| Deals and opportunities | partial | critical | Pipelines, stages, products, currency, probability, and close semantics need mapping. | Freeze a stage dictionary and reconcile value by pipeline. |
| Custom properties and fields | partial | high | Names, types, option values, validation, and calculated fields differ. | Create a signed field dictionary before loading records. |
| Owners, teams, and permissions | manual | critical | Users and access rules do not transfer as data. | Provision destination users first and map inactive owners explicitly. |
| Associations and hierarchy | partial | critical | Relationships can flatten when stable source IDs are absent or load order is wrong. | Preserve source IDs and load parents before children. |
| Activities and communication history | partial | high | Calls, meetings, notes, tasks, and emails have different export and import coverage. | Define mandatory history and test each activity type separately. |
| Files and attachments | partial | high | Record exports may include metadata without transferring every binary. | Export binaries separately and verify record linkage and permissions. |
| Automation and record state | manual | critical | Workflows, code, triggers, queues, and enrollment state do not execute on the destination. | Rebuild approved automations and freeze source writers during cutover. |
| Reports, dashboards, and attribution | lost | high | Historical reports and calculation models do not become destination-native history. | Export signed baselines and rebuild only approved metrics. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Salesforce contact or lead | Airtable person record | transform | Preserve source ID and approved match key. |
| Company or account | Company or account | transform | Load before related people and deals. |
| Deal or opportunity | Deal or opportunity | transform | Map pipeline, stage, currency, value, and close date. |
| Custom property or field | Destination property or field | transform | Map type, validation, options, and null behavior. |
| Owner | Destination owner | manual | Map inactive and deleted users to approved holding owners. |
| Record association | Destination association | transform | Resolve source IDs after parent load. |
| Activity | Destination activity | transform | Test each supported activity type. |
| File or attachment | Destination file association | transform | Copy the binary and preserve access. |
| Workflow enrollment | Destination automation state | manual | Do not infer in-flight state. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Salesforce data, configuration, and operating evidence before any destination write.
- Export every in-scope Salesforce object, field definition, relationship, activity, file, user, workflow, report, and integration.
- Record counts and value totals by object, owner, pipeline, stage, and currency.
- Capture schemas, permissions, automation definitions, API clients, and sync direction.
- Hash raw exports and transform working copies only.
Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.
Record identity and field map
Preserve stable identity, types, options, and relationships.
- Inventory source values and exceptions.
- Define explicit destination mappings.
- Reject unmapped critical records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Dependency-ordered load files
Load owners and parents before dependent records.
- Normalize encoding, dates, identifiers, and blanks.
- Run a representative pilot.
- Reconcile accepted, rejected, and transformed rows.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
Duplicate or flattened records
Counts increase unexpectedly or relationships lose stable IDs.
- Consequence
- Teams act on conflicting customer records.
- Mitigation
- Pilot matching and dependency-ordered loads.
Stop if: Duplicate rate or orphan relationships exceed tolerance.
Automations write during migration
Source and destination workflows update the same business process.
- Consequence
- Records drift and customers receive incorrect actions.
- Mitigation
- Freeze writers and enable one integration at a time.
Stop if: An unapproved writer changes migrated data.
Permissions expose restricted data
A pilot user can access records or fields outside their role.
- Consequence
- Confidential or regulated data is disclosed.
- Mitigation
- Build and test least-privilege roles before load.
Stop if: Any restricted record is visible to an unauthorized test user.
Do the work in this order.
- Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting- Inventory Salesforce data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Salesforce and Airtable administrator access
Stop / go checkpointExport?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
- Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting- Configure Airtable and transform representative data.
- Run a pilot containing normal records and every critical edge case.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
- Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting- Freeze production writes in Salesforce.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
- Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.
Cut over with a way back.
Cutover
Make Airtable the only production system without losing the final Salesforce delta.
- Freeze production writes and scheduled actions in Salesforce.
- Export, transform, and reconcile the final delta.
- Apply the approved delta to Airtable.
- Switch domains, forms, integrations, sending, or sync ownership as applicable.
- Run every blocking verification check and keep the source intact.
Proof to capture: Airtable owns production, totals reconcile, and every blocking check has durable evidence.
Rollback
Return production ownership to Salesforce without losing destination-era changes.
- Stop new writes and scheduled actions in Airtable.
- Restore the prior Salesforce routing, forms, integrations, sending, or sync ownership.
- Export the Airtable post-cutover delta.
- Review and apply safe destination-era changes to Salesforce.
- Run the same blocking checks against the restored source.
Proof to capture: Salesforce again owns production with current data and no duplicate destination action.
- Unexplained critical count or value variance
- Missing or exposed critical data
- Duplicate production action
- Failed access, routing, delivery, or integration check
- A critical feature has no safe destination replacement
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Object reconciliation | Compare source, staged, accepted, rejected, and destination counts. | Every record is accounted for. | Count ledger. | |
V-02Blocking | Duplicate control | Run approved match rules and inspect samples. | Duplicate and merge rates remain within tolerance. | Identity report. | |
V-03Blocking | Value parity | Compare stratified records across every critical type. | Critical values, options, nulls, dates, and currency match. | Field comparison. | |
V-04Blocking | Association integrity | Query parent, child, and many-to-many samples. | No unexplained orphan or flattened relationship. | Relationship report. | |
V-05Blocking | History coverage | Compare each required activity type. | Approved history is present and correctly owned. | Activity matrix. | |
V-06Blocking | Role and field security | Test representative users. | Least-privilege access matches the signed matrix. | Access evidence. | |
V-07Blocking | Business paths | Run controlled records through every approved branch. | One correct action path with no source duplicate. | Automation log. | |
V-08Blocking | Integration ownership | Inspect writers, API clients, webhooks, and scheduled jobs. | Airtable is the authoritative CRM. | Integration registry. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.
- Create final Salesforce exports and archive verification evidence.
- Revoke temporary credentials, API keys, webhooks, and elevated roles.
- Remove obsolete embeds, forms, jobs, integrations, and DNS records.
- Keep the source intact through the approved retention window.
- Cancel paid plans only after billing, legal, and recovery review.
- Schedule the next Airtable backup, access, and migration-playbook review.
Built to be reviewed.
Tested 2026-07-19. Next scheduled review: 2026-10-19.
- Salesforce: official migration documentationAccessed 2026-07-19
- Airtable: official migration documentationAccessed 2026-07-19