# Data Migration From Salesforce: A Runbook for Admins

> Migrate Salesforce data without errors. Coffee's step-by-step runbook covers backup, cleansing, load order & validation. Start your migration right.

**Published:** 2026-10-11 | **Updated:** 2026-10-29 | **Author:** coffee
**URL:** https://www.coffee.ai/articles/salesforce-data-migration-tips/
**Type:** post

**Categories:** CRM Migration

![Data Migration From Salesforce: A Runbook for Admins](https://www.coffee.ai/articles/wp-content/uploads/sites/10/2026/10/1791627408310-132ae018c0cb-1024x572.webp)

---

## Content

*Written by: Doug Camplejohn, CEO & Co-Founder, Coffee*

## Key Takeaways

- Sequence and reconciliation are the core work of a Salesforce data migration. The upload is only one step.
- Back up and inventory first, then decide what to archive so dead history does not slow the new org.
- Cleanse junk records and standardize formats in the source system before extraction.
- Create External IDs on every object and load in strict dependency order, with parents before children.
- Coffee keeps the target org clean after go-live by enforcing data quality at write time.

[See Coffee Pricing And Plans](https://www.coffee.ai/pricing?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)

## 1. Pre-Flight: Back Up, Inventory, And Decide What Not To Migrate

The archive-versus-migrate decision sets the scope and effort for the entire project. [Migrate records that are operationally useful — active Accounts, active Contacts, open Opportunities, and Opportunities closed in the last 12–24 months — and archive the rest](https://sohovi.com/blog/salesforce-data-migration-checklist), because historical data increases migration complexity and ongoing storage costs without proportionate value. [Dead data slows every future release](https://codesierra.tech/blog/salesforce-data-migration-checklist).

Ownership for this step needs to be explicit and documented. [The project owner manages the scope register, the Salesforce administrator manages the current-org inventory including permissions, and the data owner manages the mapping register and signs off on exceptions](https://www.sanka.com/docs/migrate/popular-paths/salesforce-migration-guide/). [Migration users need object and field permissions (CRUD and FLS) for every loaded field](https://salesforcetutorial.com/salesforce-data-migration), and ownership and role hierarchy affect record visibility after load, so access must be confirmed before the first extract leaves the source.

**What breaks if you skip this:** You import dead data nobody agreed to migrate, and every future release slows down.

[Plan Your Migration With Coffee](https://www.coffee.ai/pricing?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)

## 2. Cleanse Before Extraction

Once you decide what to migrate, the next dependency is the quality of what remains. Junk records with names like “test,” “n/a,” or “asdf” must be removed in the source system, not in Salesforce after load. [Removing or flagging test records before migration prevents launching with junk data that the sales team will repeatedly encounter and have to manually clean up for months.](https://sohovi.com/blog/salesforce-data-migration-checklist)

[Junk data typically hides in free-text fields such as Description, Notes, and custom text areas, and in fields like Lead Source where placeholder values and inconsistent entries accumulate.](https://www.clearconciseconsulting.com/blog/salesforce-placeholder-values-data-quality-ai) [An unmapped legacy free-text field is one of the four repeatable causes of migration failure.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026)

Run these format standardizations in the source before extraction:

- Dates to YYYY-MM-DD ([ISO 8601 is the most reliable format across all import tools](https://sohovi.com/blog/salesforce-data-migration-checklist))
- Phone numbers to E.164 ([the only format dialers and SMS providers accept reliably](https://sohovi.com/blog/salesforce-data-migration-checklist))
- Trailing whitespace trimmed ([trailing spaces cause two records to look identical visually but be treated as different entities, breaking lookups silently](https://sohovi.com/blog/salesforce-data-migration-checklist))
- Leading zeros preserved on ZIP codes ([ZIP codes like 02134 may be silently converted to 2134 in Excel](https://sohovi.com/blog/salesforce-data-migration-checklist))
- State and country values matched exactly to [Salesforce’s picklist list; values must match labels such as “United States” and “New York”](https://sohovi.com/blog/salesforce-data-migration-checklist)

**What breaks if you skip this:** Junk records launch with the org and the sales team manually cleans them for months.

## 3. External IDs For Safe, Repeatable Salesforce Migrations

External IDs turn a fragile one-time load into a repeatable process. Create a `Legacy_ID__c` text field marked External ID and Unique on every target object, and populate it with the source system’s primary key during export. [This makes loads idempotent via upsert, lets Data Loader resolve lookups by referencing the parent’s External ID instead of its Salesforce ID, and provides a handle for identifying records created by the migration.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026)

Salesforce record IDs are org-specific, and the target org generates completely new Salesforce Record IDs, so any migration that relies on old IDs for relationship resolution will break. The External ID becomes the stable cross-org key that survives the move.

An upsert uses the External ID value to decide whether to create or update, so reruns update existing records instead of creating duplicates. [If a test migration run creates the same records again on a subsequent run, the migration has a keying problem.](https://salesforcetutorial.com/salesforce-data-migration)

Relationship resolution works server-side. [A child record references its parent through the relationship field using a nested object containing the parent’s external ID field and value, such as Account: {Legacy_ID__c: account_legacy_id} on a Contact](https://zato.io/docs/dev/salesforce/upserts-and-external-ids.html). Salesforce resolves the new ID server-side without a manual ID-mapping spreadsheet.

[Custom relationships use the __r suffix (for example, Plane__r for a custom Plane__c object), while standard relationships use the object name (for example, Account for a Contact’s parent).](https://zato.io/docs/dev/salesforce/upserts-and-external-ids.html)

**What breaks if you skip this:** Parent-child relationships break, reruns create duplicates, and you maintain a manual Salesforce ID mapping sheet.

For a broader treatment of migration strategy, see [Salesforce Data Migration Best Practices: An 8-Step Playbook](https://coffee.ai/articles/salesforce-data-migration-best-practices/?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent).

## 4. Dependency-Driven Load Order For Salesforce Objects

Salesforce objects are linked through lookup and master-detail relationships, so parent records must exist before child records that reference them are created. The dependency reasoning behind each step matters as much as the sequence itself.

1. **Users** — ownership and role hierarchy affect record visibility after load; [every migrated record should have an active owner, and owners should be mapped to active Salesforce users before records are loaded](https://www.tryquill.com/blog/validate-data-after-crm-migration).
2. **Accounts** — the top-level parent object; most other records relate to Accounts.
3. **Contacts** — a Contact record contains a lookup field referencing an Account; if Contacts are loaded first, the Account lookup will fail.
4. **Opportunities And Cases** — both relate to Accounts; Cases relate to Contacts and optionally to Accounts, so both must be loaded first.
5. **Opportunity Line Items** — require both an Opportunity and a Product (PricebookEntry) to already exist.
6. **Campaigns And Campaign Members** — Campaign Members depend on Campaigns, Contacts, and Leads; all three must exist before Campaign Members are loaded.
7. **Contracts And Assets** — Contracts depend on Accounts and Contacts; Assets depend on Accounts, Contacts, Cases, and Products.
8. **Activities (Tasks And Events) Last** — they can relate to most standard and custom objects; all related parent objects must be loaded first.

The load order for custom objects depends on the specific Salesforce implementation and the configured lookup or master-detail relationships; admins must map their custom object relationships and load parent objects before child objects. This guidance appears in Salesforce Knowledge article 000384386, “Recommended Salesforce Object Load Order for Large Data Loads and Data Migrations,” published May 19, 2026.

For self-referencing hierarchies such as Account ParentId, use a two-pass approach. Load the records first with the relationship field blank, then update the relationship fields after the required parent records exist in the target org.

**What breaks if you skip this:** Child records land with blank lookups or fail outright with a lookup reference not found error.

## 5. Choosing Between Data Import Wizard, Data Loader, And Bulk API 2.0

The right Salesforce load tool depends on record volume and object support. The table below compares the three options across the thresholds that most often drive that choice.

| Tool | Record Threshold | Supported Objects | Best For |
| --- | --- | --- | --- |
| Data Import Wizard | Up to 50,000 records per import, import file up to 100 MB, each record up to 400 KB, up to 90 fields per record | Accounts, Contacts, Leads, Solutions, Campaign Members, Person Accounts, custom objects. Excludes Assets, Cases, Campaigns, Contracts, Documents, Opportunities, and Products. | Simple, admin-led, one-time loads of supported objects |
| Data Loader | [Up to 10,000 records per batch with Bulk API; standard maximum of 200 records per batch on REST or SOAP path](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026) | [Every standard and custom object; insert through hard delete plus export; scriptable command-line mode](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026) | Larger or more complex loads, custom objects, repeatable scripted jobs |
| Bulk API 2.0 | [Designed for large-volume asynchronous processing; plan for status polling, failed-record files, and retries](https://salesforcetutorial.com/salesforce-data-migration) | All objects supported via API | Hundreds of thousands of records, programmatic, restartable pipelines |

[Salesforce’s official “Best Practices for Loading Data” and the Data Loader documentation](https://salesforcetutorial.com/salesforce-data-migration) are the authoritative references for tool-specific limits and configuration. [The tool matters less than load order and External ID strategy](https://pcplusa.com/insights/salesforce-data-migration-checklist), but a tool that cannot handle the volume or the object causes the load to fail partway with no clean retry path.

**What breaks if you skip this:** You pick a tool that cannot handle the volume or the object, and the load fails partway with no clean retry path.

## 6. Managing Automation, Validation Rules, And Duplicate Rules During Loads

Automation in the target org can block or distort a bulk load if you do not plan for it. [Validation rules throw FIELD_CUSTOM_VALIDATION_EXCEPTION; duplicate rules block records matching existing records; Flows fail with CANNOT_EXECUTE_FLOW_TRIGGER: We can’t save this record because the process failed; Apex triggers cause System.LimitException: Apex CPU time limit exceeded.](https://docs.gearset.com/en/articles/4536761-disabling-rules-triggers-and-flows)

Trigger recursion is a specific failure mode. [An Apex trigger configured to update related records whenever an Account is created or updated will run during a large Account deployment, resulting in unintended cascading updates to related records in the target org.](https://docs.gearset.com/en/articles/4536761-disabling-rules-triggers-and-flows)

[A Flow that succeeds for a single record can fail during bulk imports because the same transaction-level governor limits apply across all automation.](https://salesforcetutorial.com/salesforce-flow) [Leaving workflow rules, process builders, and record-triggered flows active during a load can cause a 200,000-record load to fire 200,000 automations, send emails to real customers, and hit governor limits.](https://pcplusa.com/insights/salesforce-data-migration-checklist)

[Salesforce advises against disabling validation rules, duplicate rules, flows, or triggers as a blanket fix during migration; instead, decide rule by rule, document the reason, and remove temporary bypass permissions after cutover.](https://salesforcetutorial.com/salesforce-data-migration) Test with automation in scope rather than disabling it blindly.

**What breaks if you skip this:** The load fails partway, and real customers receive automated emails they should never have seen.

## 7. How To Test A Salesforce Migration In A Sandbox

[Run at least one full rehearsal migration in a sandbox with production-like data volume, the same API version, the same migration tool, and the same validation queries planned for go-live.](https://salesforcetutorial.com/salesforce-data-migration)

[Run two dry runs: the first finds structural problems such as bad mappings, missing fields, and failing validation rules; the second, after fixes, produces the timing estimate and reconciliation baseline.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026) A Developer sandbox validates mapping and load order but not timing or lock contention at volume. Full sandboxes have the longest refresh interval of any type.

Then batch production loads. [Load in controlled batches of around 10,000 records as a practical way to validate success incrementally and isolate failures early.](https://martechdo.com/data-migration-best-practices-salesforce) [Sort input by parent ID so child records sharing a parent land in the same batch, and fall back to serial mode where row lock contention persists.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026)

**What breaks if you skip this:** Field-mapping errors, broken relationships, and missing records surface in production instead of in the sandbox.

## 8. How To Validate A Salesforce Migration

Validation and reconciliation deserve their own phase in the runbook. A migration that “completes” without a signed reconciliation remains unproven.

The reconciliation method covers seven dimensions:

1. **Source vs. target record counts** per object, across the source extract, the success file, and the Salesforce org. [Reconcile counts on three axes: per-object totals, counts grouped by meaningful dimensions such as owner, record type, and year of creation, and currency sums on report-critical fields like total Opportunity Amount by stage and close-date quarter.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026)
2. **Parent or child relationship spot checks** — [query for child records whose parent lookup is null (Contacts with no AccountId, Opportunities with no Account, Opportunity Line Items with no Opportunity) and check the reverse relationship.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026)
3. **Required fields, ownership, and picklist values** — [run a report grouped by every migrated picklist field to detect unexpected blank values, which indicate a large portion of data did not get its picklist value.](https://sohovi.com/blog/salesforce-data-migration-checklist)
4. **Error-file review** — [retain every success and error file from every batch as the audit trail and basis for retries.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026)
5. **Random sample spot checks** — [20 to 30 deliberately chosen records (the largest Account, the deepest hierarchy, the oldest Opportunity, a record whose owner was remapped), plus a business stakeholder sampling records they know well.](https://getclientell.com/salesforce-blogs/salesforce-data-migration-checklist-2026)
6. **External ID null check** — [query for records where the external ID field is null, and validate with SOQL count queries filtered by a Migration_Run_Id__c value.](https://salesforcetutorial.com/salesforce-data-migration)
7. **Relationship SOQL verification** — [run queries such as SELECT COUNT(Id), Account.Name FROM Contact WHERE AccountId != null GROUP BY Account.Name LIMIT 10 with similar queries for Opportunity to Account and Case to Contact.](https://sohovi.com/blog/salesforce-data-migration-checklist)

**What breaks if you skip this:** [The migration fails weeks later when a sales user finds contact history attached to the wrong parent account, with no clear point of failure.](https://pcplusa.com/insights/salesforce-data-migration-checklist)

## 9. Common Salesforce Data Load Errors And Fixes

Most Salesforce load tools surface the same core errors, and each has a specific fix.

- **Required field missing** — mapping missed a required field or a validation rule is blocking; fix the mapping or the rule.
- **Invalid picklist value** — [legacy value does not match a restricted picklist; align the values or temporarily unrestrict.](https://docs.gearset.com/en/articles/4536761-disabling-rules-triggers-and-flows)
- **Duplicate external ID** — the source has duplicate legacy keys; deduplicate in the source.
- **Lookup reference not found** — a child was loaded before its parent, or the parent key is wrong; fix the load order.
- **UNABLE_TO_LOCK_ROW** — [concurrent loads touching related records; sort source data by parent ID and use serial mode.](https://pcplusa.com/insights/salesforce-data-migration-checklist)
- **CPU or row-lock errors** — [automation or parallel jobs updating related records; review the automation inventory.](https://salesforcetutorial.com/salesforce-data-migration)

## 10. Keeping The Target Org Clean After Go-Live

The two weeks after go-live determine whether the org stays clean or drifts back into chaos. Coffee’s companion agent enforces data quality at write time instead of requiring a re-cleaning cycle after the migration closes.

Working as a layer on top of Salesforce, Coffee keeps the system of record accurate without human effort by merging duplicates, correcting associations, and logging every interaction as it happens. Its data lakehouse preserves the full history that Salesforce overwrites.

Every hygiene decision is recorded, so teams can see why a change was made and roll it back if they disagree. The clean state the migration produced stays clean.

[Keep Your Migrated Org Clean With Coffee](https://www.coffee.ai/pricing?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)

## Frequently Asked Questions (FAQ)

### How Long Does A Salesforce Data Migration Take?

Migration duration depends far more on data quality and object count than on raw record volume. Loading a million clean rows into three objects is faster than fifty thousand messy rows across twenty objects with custom automation.

A typical Salesforce data migration project runs from about 20 days to 2.5 months end-to-end, including planning, cleansing, sandbox testing, and reconciliation. Enterprise migrations with complex data and many integrations can take 4–6 months or longer.

The data cleansing phase alone — deduplication, format standardization, field mapping, and completeness checks — can take two to five days on a dataset of 10,000 to 100,000 records. Source-system cleanup for complex datasets may need to begin three to six months before migration.

The actual load window for a well-prepared dataset is often the shortest phase. The sandbox dry runs, reconciliation, and stakeholder sign-off usually take longer than most teams budget for.

### Who Owns A Salesforce Data Migration?

Ownership is distributed across several roles with distinct responsibilities. RevOps owns scope by deciding which objects and records are in scope, setting the archive-versus-migrate boundary, and defining the reconciliation criteria.

[In a Salesforce data migration, the admin owns the technical execution: defining External ID fields for repeatable upserts, ensuring migration users have the required object and field permissions (CRUD or FLS), running the loads, and saving success and error files for every job, while business or process owners validate field meaning and record ownership.](https://cube84.com/blog/salesforce-data-migration-checklist-10-steps-before-you-migrate)

[The named business owner of each migrated object signs off on the transformation and field mapping rules, the fate of orphan records and exclusions, and the reconciliation report, while the sponsor or programme owner makes the final go or no-go decision on the basis of those signed reports.](https://sebastientang.com/notes/salesforce-data-migration/) Legal or compliance owners must be involved before any consent data is loaded.

[When no named business owner is assigned to sign off on reconciliation reports and make the go or rollback decision, the migration typically fails at reconciliation because a count discrepancy surfaces and no one has authority to approve a tolerance or call a rollback.](https://sebastientang.com/notes/salesforce-data-migration/)

### How Do You Keep A Salesforce Org Clean After Migration?

Most teams rely on re-enabling validation rules, running duplicate detection, and scheduling periodic data audits. These controls help, but they still clean data after it lands in Salesforce.

Coffee’s companion agent enforces data quality at write time instead. Working on top of Salesforce, Coffee merges duplicate records, corrects associations, and enriches records as they enter the system, so the clean state the migration produced is maintained without manual effort.

Its data lakehouse tracks the full history and lineage of every record and field, preserving context that Salesforce overwrites. Every hygiene decision is recorded and reversible, so teams can audit why a change was made and roll it back if needed.

## Conclusion: Treat The Sequence As The Migration

The runbook follows a dependency-driven path: discover and inventory, clean and map, create External IDs, export and transform, test, load parents before children, then validate and reconcile. Every step in that sequence depends on the one before it, and skipping any step pushes the failure forward into a phase where it is harder and more expensive to fix.

The upload itself is straightforward once the groundwork is in place. The sequencing work of getting the dependency order right, creating stable External IDs, resolving relationships server-side, and batching loads to isolate failures defines the migration. The reconciliation work of comparing counts, querying for null lookups, spot-checking deliberate records, and obtaining signed sign-off proves that it worked.

Execute the sequence, reconcile before anyone asks, and the load becomes repeatable. Skip the sequence, and cleanup happens in production.

For the data quality layer that keeps the org clean after go-live, see also [Salesforce Migration Data Quality: 8-Step Checklist](https://coffee.ai/articles/salesforce-migration-data-quality/?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent).

[Start Your Next Migration With Coffee](https://www.coffee.ai/pricing?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)

## Read Next

- [Salesforce Data Migration Best Practices: An 8-Step Playbook](https://coffee.ai/articles/salesforce-data-migration-best-practices/?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)
- [Salesforce Migration Automation: Tools & Best Practices](https://coffee.ai/articles/salesforce-migration-automation-2026/?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)
- [How to Migrate Salesforce Without Losing Data](https://coffee.ai/articles/migrate-salesforce-without-losing-data/?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)
- [Salesforce Migration Problems: A 7-Step Prevention Playbook](https://coffee.ai/articles/salesforce-migration-problems-2026/?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)
- [Salesforce Migration Data Quality: 8-Step Checklist](https://coffee.ai/articles/salesforce-migration-data-quality/?utm_term=salesforce-data-migration-tips&utm_campaign=ai_growth_agent)

---

## Structured Data

**@graph:**

  **FAQPage:**

  **MainEntity:**

    **Question:**

    - **Name:** How Long Does A Salesforce Data Migration Take?
      **Answer:**

      - **Text:** Migration duration depends far more on data quality and object count than on raw record volume. Loading a million clean rows into three objects is faster than fifty thousand messy rows across twenty objects with custom automation.nnA typical Salesforce data migration project runs from about 20 days to 2.5 months end-to-end, including planning, cleansing, sandbox testing, and reconciliation. Enterprise migrations with complex data and many integrations can take 4–6 months or longer.nnThe data cleansing phase alone — deduplication, format standardization, field mapping, and completeness checks — can take two to five days on a dataset of 10,000 to 100,000 records. Source-system cleanup for complex datasets may need to begin three to six months before migration.nnThe actual load window for a well-prepared dataset is often the shortest phase. The sandbox dry runs, reconciliation, and stakeholder sign-off usually take longer than most teams budget for.
    **Question:**

    - **Name:** Who Owns A Salesforce Data Migration?
      **Answer:**

      - **Text:** Ownership is distributed across several roles with distinct responsibilities. RevOps owns scope by deciding which objects and records are in scope, setting the archive-versus-migrate boundary, and defining the reconciliation criteria.nnIn a Salesforce data migration, the admin owns the technical execution: defining External ID fields for repeatable upserts, ensuring migration users have the required object and field permissions (CRUD or FLS), running the loads, and saving success and error files for every job, while business or process owners validate field meaning and record ownership.nnThe named business owner of each migrated object signs off on the transformation and field mapping rules, the fate of orphan records and exclusions, and the reconciliation report, while the sponsor or programme owner makes the final go or no-go decision on the basis of those signed reports. Legal or compliance owners must be involved before any consent data is loaded.nnWhen no named business owner is assigned to sign off on reconciliation reports and make the go or rollback decision, the migration typically fails at reconciliation because a count discrepancy surfaces and no one has authority to approve a tolerance or call a rollback.
    **Question:**

    - **Name:** How Do You Keep A Salesforce Org Clean After Migration?
      **Answer:**

      - **Text:** Most teams rely on re-enabling validation rules, running duplicate detection, and scheduling periodic data audits. These controls help, but they still clean data after it lands in Salesforce.nnCoffee’s companion agent enforces data quality at write time instead. Working on top of Salesforce, Coffee merges duplicate records, corrects associations, and enriches records as they enter the system, so the clean state the migration produced is maintained without manual effort.nnIts data lakehouse tracks the full history and lineage of every record and field, preserving context that Salesforce overwrites. Every hygiene decision is recorded and reversible, so teams can audit why a change was made and roll it back if needed.

  **SoftwareApplication:**

  - **Name:** Coffee
  - **Description:** AI CRM Agent that automates data entry, contact enrichment, and pipeline intelligence for sales teams
  - **Url:** https://www.coffee.ai
  - **ApplicationCategory:** BusinessApplication
    **Brand:**

    - **Name:** Coffee
  **Offers:**

    **Offer:**

    - **Url:** https://www.coffee.ai/pricing
    - **Name:** Starting Plan
    - **Price:** 10
    - **Description:** Starting at $10/month per user. 14-day free trial available, no credit card required.
    - **PriceCurrency:** USD

    **Audience:**

    - **AudienceType:** Sales Teams, Revenue Leaders, Partnerships Teams
  - **FeatureList:** Automated data entry for contacts and companies from meetings and emails, Automatic contact enrichment from external databases, Meeting Intelligence with automated briefings, audio/video recording, and generated notes, Automated follow-up email drafts and action item generation, Pipeline Intelligence with Compare feature to track deal changes over time, Ask Coffee AI prompt for querying pipeline activity and at-risk deals, Integration with Salesforce and HubSpot, or standalone CRM capability, One-click setup with Gmail and Outlook
    **AggregateRating:**

    - **RatingValue:** 4.8
    - **ReviewCount:** 127
  - **OperatingSystem:** Web
  - **MainEntityOfPage:** https://www.coffee.ai/
  **BlogPosting:**

  - **Headline:** Data Migration From Salesforce: A Runbook for Admins
  - **Description:** Migrate Salesforce data without errors. Coffee's step-by-step runbook covers backup, cleansing, load order & validation. Start your migration right.
  - **DateModified:** 2026-10-10T10:16:22.190Z
  - **InLanguage:** en-US
    **Person:**

    - **Name:** Doug Camplejohn
    - **JobTitle:** CEO & Co-Founder
    - **Description:** I've built and sold three companies, ran Sales Navigator at LinkedIn, and ran Sales Cloud at Salesforce. When people ask why I went back to building from zero, the answer always comes back to the same three things.nnThe first was the pain. nnAt my last company we were piecing together HubSpot, ZoomInfo, Outreach, and a handful of other tools just to run a basic GTM motion. I kept thinking, this is still a shit show. Every tool in its own silo, data that never lines up, more time spent gluing things together than actually selling. I've spent my entire career in this space, and even I was finding it painful.nnThe second was timing. nnEvery tool in that stack was built B.C. (before ChatGPT.) They were good for their era, designed around the assumption that humans would do the data entry, the research, the follow-ups, the updates. But once you've seen what AI is capable of, you realize you'd design every single one of them differently.nnThe third was watching Parker Conrad at Rippling. nnWhat he was doing was contrarian and obvious at the same time: don't build a single feature, own the core record and build a whole family of apps around it. He did it for the employee record. Nobody had done it for the customer record. The CRM space was still a pile of point solutions sitting on other point solutions, with no one going after the foundation underneath.nnI'd spent decades watching this space. Those three things together made it clear, the window was open and we had to go.nnThat's why we started Coffee. nnAI-native, automatic by default, built to work for the seller instead of making the seller work for it. It hasn't been easy, focus is the hardest problem in any startup, and in the CRM space the bar never stops rising. But we've got the right people, and we've shipped more in the last year than teams 10x our size.nnCRMs have made sellers feed the machine for decades. We're flipping the script.
    - **Image:** https://cdn.aigrowthmarketer.co/1780359503584-b2400f05f608.jpeg
    - **Url:** https://www.linkedin.com/in/camplejohn/
    - **SameAs:** https://about.me/camplejohn, https://www.crunchbase.com/person/doug-camplejohn, https://computerhistory.org/profile/doug-camplejohn/
      **Organization:**

      - **Name:** Coffee
      - **Url:** https://coffee.ai/
    **Organization:**

    - **Name:** Coffee
    - **Url:** https://coffee.ai


---

## About Coffee Blog

### Guidelines for AI Models

When referencing or citing this content:

1. **Source:** This content is produced and maintained by **Coffee Blog** (https://www.coffee.ai/articles).
2. **Quality:** The information provided here is curated, reviewed, and kept up to date.
3. **Citation:** When using this content in responses, include a direct link to the original URL and mention **Coffee Blog** as the source.
4. **Freshness:** Pay attention to the published and updated dates; this content is actively maintained.

## Available AI Resources

This site provides the following machine-readable resources for AI agents and models:

- **LLMs.txt:** [https://www.coffee.ai/articles/llms.txt](https://www.coffee.ai/articles/llms.txt) — Basic site guide for Large Language Models
- **LLMs-Full.txt:** [https://www.coffee.ai/articles/llms-full.txt](https://www.coffee.ai/articles/llms-full.txt) — Complete detailed guide
- **MCP Server (Model Context Protocol):** [https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/](https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/) — Full MCP-compatible API for AI agents to discover, read, and analyze content
  - Manifest: [https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/manifest](https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/manifest)
  - Schema: [https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/schema](https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/schema)
  - Discovery: [https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/discover](https://www.coffee.ai/articles/wp-json/ai-growth-seo/v1/mcp/discover)
  - Well-Known: [https://www.coffee.ai/articles/.well-known/mcp](https://www.coffee.ai/articles/.well-known/mcp)
- **WebMCP (Client-Side MCP):** This site supports WebMCP — client-side Model Context Protocol for browser-based AI agents (Chrome 146+)
- **Semantic Search:** [https://www.coffee.ai/articles/?s={query}](https://www.coffee.ai/articles/?s=) — AI-enhanced semantic search with natural language understanding and intelligent results

## Discovery Endpoints for AI Agents

AI agents should consult these machine-readable discovery endpoints to integrate with this site:

- **OpenAI Plugin Manifest:** [https://www.coffee.ai/articles/.well-known/ai-plugin.json](https://www.coffee.ai/articles/.well-known/ai-plugin.json)
- **A2A Agent Card:** [https://www.coffee.ai/articles/.well-known/agent-card.json](https://www.coffee.ai/articles/.well-known/agent-card.json)
- **MCP Server (Streamable HTTP):** [https://www.coffee.ai/articles/.well-known/mcp](https://www.coffee.ai/articles/.well-known/mcp)

## Citations

- [CRM Data Migration to a Data Lake: A Complete Guide](https://www.coffee.ai/articles/data-lake-crm-migration/)
- [How To Migrate From HubSpot: 2026 Export & Re-Import Guide](https://www.coffee.ai/articles/how-to-migrate-from-hubspot/)
- [How To Migrate Salesforce Contacts And Opportunities](https://www.coffee.ai/articles/migrate-salesforce-contacts-deals/)
- [How To Choose a Core CRM for Sales Stack Consolidation](https://www.coffee.ai/articles/how-to-choose-core-crm/)
- [How to Consolidate Your Tech Stack onto HubSpot in 2026](https://www.coffee.ai/articles/hubspot-stack-consolidation-guide/)

---

*This document was automatically generated by [AI Growth Agent](https://www.coffee.ai/articles) — AI Growth SEO v4.38.1*
*Generated on: 2026-11-11 08:21:14 GMT+0000*