Written by: Doug Camplejohn, CEO & Co-Founder, Coffee | Last updated: August 11, 2026
Key Takeaways
- Resolve data quality issues in the source system before loading any records so you avoid months of post-go-live cleanup.
- Use pre-migration audits, tight scoping, and sandbox dry runs to catch duplicates, broken relationships, and automation conflicts early.
- Rely on External IDs, disabled automations, and strict parent-child load order to keep relationships intact and owners valid.
- Define rollback triggers, enforce a cutover freeze, and assign named governance owners to protect data quality after go-live.
- Keep Salesforce data clean after migration with Coffee, which automatically captures activities and closes manual entry gaps.
Core Prerequisites Before You Start the 12 Steps
Put these four foundations in place before Step 1 begins.
- Sandbox access: A Full or Partial Copy Sandbox is required for dry runs because migration should never be performed directly into Production on the first attempt. You need 2–3 dry runs in a sandbox to surface validation rule errors, unexpected trigger behavior, and picklist mismatches before any production load.
- Data inventory: Capture a complete object-by-object record count from the source system, including attachments and historical activities.
- Stakeholder sign-off: Treat data migration as a business project with technical execution, and keep governance decisions with the business owner instead of the migration developer.
- Rollback budget: Reserve time and tools for rollback, including parallel-run environments, point-in-time recovery, and automated verification scripts.
Planning & Data Cleansing Steps 1–3
- Scope the migration. Define which records are commercially relevant and exclude the rest. This scoping decision prevents the 3–6 months of post-go-live deduplication and archiving that teams face when they migrate everything. Start with a full source export and produce an approved record scope document signed by a business owner.
- Run a pre-migration data audit. Profile every in-scope field for duplicates, null required fields, invalid picklist values, formatting inconsistencies, and broken foreign keys. Referential integrity checks during this audit highlight child rows whose parent keys are missing from the parent extract, which prevents orphaned records after load. Capture the findings in an issue log with row-level flags.
- Fix data quality issues in the source system. Merge duplicates, fill required fields, correct picklist values, and repair broken relationships before any extract. Programs that skip data preparation run about 30 percent longer and 30 to 50 percent over budget. Produce a clean source extract with a documented transformation log.
Common Mistakes in the Planning Phase
- Migrating everything instead of scoping to commercially relevant records.
- Skipping the pre-migration audit and discovering issues only after the production load.
- Completing field mapping without formal sign-off from business owners.
Org Preparation Steps 4–6
- Create External ID fields on every object. External IDs provide the most reliable way to maintain parent-child relationships during a Salesforce migration because they match related records without relying on Salesforce-generated IDs. Create a custom field such as
Legacy_ID__con Accounts, Contacts, Opportunities, and all custom objects. Mark each field as unique and External ID, then verify these fields in sandbox. - Disable automations. If you disable workflow rules, validation rules, and Process Builder flows too late, they fire on incomplete records and cause rejections or hidden data changes. Disable all Flows, Process Builders, workflow rules, triggers, and email deliverability before the first load wave. As you disable each item, document it and name the person who will approve reactivation. The output is an automation-disable checklist with a named approver for every item.
- Enable Create Audit Fields permission. Without the Set Audit Fields upon Record Creation permission, Salesforce stamps the current date as CreatedDate on every migrated record and you cannot correct it later. Turn this permission on in the target org before any data loads and confirm it in both sandbox and production.
Common Mistakes in Org Preparation
- Skipping External IDs and relying on Salesforce-generated record IDs as join keys.
- Leaving automations enabled during load, which causes mass email accidents or validation failures.
- Forgetting to enable audit fields and permanently losing original CreatedDate values.
Execution & Validation Steps 7–9
- Run a pilot test migration in sandbox. Load a representative sample of records. Review success and error logs, refine field mappings, and confirm which automations must remain disabled. Capture a sandbox error log with clear resolution notes.
- Follow strict parent-child load order. A child record cannot reference a parent record that does not exist yet, so parents must load first to avoid failures and empty relationship fields. Use the sequence in the table below.
| Object | Load Order | Example Record Count (50–200 person org) | Notes |
|---|---|---|---|
| Users / Roles / Teams | 1 | 50–200 | All record owners must exist before any object load |
| Accounts | 2 | 1,000–10,000 | Self-referencing ParentId hierarchies require a two-pass load |
| Contacts | 3 | 2,000–20,000 | Requires AccountId via External ID |
| Products / Price Books | 4 | 100–2,000 | Must exist before Opportunity Line Items |
| Opportunities | 5 | 500–5,000 | Requires AccountId and OwnerId |
| Opportunity Line Items | 6 | 1,000–15,000 | Requires Opportunity and Price Book Entry |
| Cases / Custom Objects | 7 | Varies | Load in their own dependency order |
| Activities (Tasks & Events) | 8 | 5,000–50,000 | Require valid WhoId and WhatId, so load after all core records |
| Notes / Files / Attachments | 9 | Varies | Load last because they can exhaust API limits if attempted too early |
After you load records in the correct sequence, confirm that the migration meets your quality bar across structure, content, and behavior.
- Run a sandbox validation matrix. Execute each scenario in the table below before you approve production cutover.
| Test Scenario | Sandbox Type | Pass Criteria | Owner |
|---|---|---|---|
| Record count reconciliation per object | Partial Copy | Source count = target count ± 0% | Data Lead |
| Parent-child relationship integrity | Partial Copy | Zero orphaned child records | Data Lead |
| Required field population | Partial Copy | 0% null rate on required fields | Salesforce Admin |
| Picklist value conformity | Partial Copy | Zero restricted picklist mismatches | Salesforce Admin |
| Automation behavior post-re-enable | Full Copy | No unintended emails or workflow loops | Salesforce Admin |
| UAT — core workflows by department | Full Copy | Power users sign off on daily-workflow scenarios | Business Validator |
| Integration end-to-end test | Full Copy | All connected systems write and read correctly | Application Lead |
Get started with Coffee, the agent layer that keeps your Salesforce data clean after go-live.
Cutover & Rollback Steps 10–11
- Execute the cutover freeze. Suspend all write activity to the legacy system at the defined cutover start time, including automated integrations, batch jobs, and manual user entry, and enforce the freeze technically rather than through communication alone. Schedule the freeze during a low-activity window, typically a Friday night or weekend. During the freeze, provide read-only access to the legacy system so users can reference data without creating new records. Once the freeze is in effect, execute the final extract, run transformation, load in object-hierarchy waves, and reconcile record counts after each wave. If any discrepancy exceeds the predefined tolerance threshold, place a hold on go-live authorization until you resolve it. Capture a signed go/no-go checklist from the cutover lead, application lead, data lead, business validator, and support lead.
- Activate the rollback plan. Even after a successful go-live decision, you need a clear rollback path in case critical issues appear during the first few days. The practical rollback window usually covers the first few days after cutover as net-new data accumulates. Trigger rollback automatically if any of these numeric criteria are met:
- More than 15% of users report critical data missing within the first 36 hours
- Data corruption in more than 1% of records or record count discrepancies exceeding 5%
- A single regulated workflow, such as billing, payroll, or compliance, is broken
The source system should remain available in at least read-only mode for a post-cutover shadow period so you can support rollback readiness and detect issues quickly.
Post-Migration Governance Step 12
- Assign permanent data governance ownership. Post-migration failures often occur when the project team assumes operations will inherit governance while operations assumes governance ended with the project, which leaves data quality unmonitored after hypercare. Assign named owners for each data domain. Set up automated monitoring dashboards from Day 1 to track duplicate rates, null values in mandatory fields, and orphan records. Have business users perform UAT with a sign-off sheet to verify key accounts and pipelines, then monitor data quality closely for the first 7–14 days.
Once governance ownership and monitoring are in place, you still need a way to close the manual entry gaps that slowly erode data quality. Coffee’s Companion App for Salesforce becomes the agent layer that prevents “bad data in” from returning. Instead of relying on sales reps to log calls, update fields, and create contacts, the Coffee Agent automatically captures interactions from emails and calendars, enriches records with job titles and company data, and writes structured activity logs back to Salesforce. Effective quality programs combine metrics such as completeness, conformity, and uniqueness with quality-by-default controls that block or flag bad records early. The Coffee Agent enforces that standard continuously without extra human effort.
Get started with Coffee and deploy the agent that keeps your Salesforce org clean automatically.
Timelines by Team Size and CRM Maturity
That timeline varies significantly based on your source system. Teams migrating from spreadsheets face a different challenge than those migrating from a legacy CRM. Spreadsheet migrations require heavier data-structuring work in Steps 1–3 because records lack consistent field schemas, owner assignments, and relationship keys. Legacy CRM migrations introduce more automation complexity in Steps 4–6 because existing integrations, triggers, and connected tools must all be inventoried and paused.
For larger or riskier migrations with many years of legacy data, a phased cutover or parallel-run period often works better than a single big-bang switch. Start with a pilot group, then expand. Smaller teams with cleaner source data can compress the calendar but still need sandbox dry runs and a cutover freeze, even under schedule pressure.
Frequently Asked Questions
How long does a Salesforce migration take for a 50–200 person company?
As discussed in the Variations section, the timeline for a 50–200 person B2B SaaS company usually ranges from 4–16 weeks based on scope and integrations. This window covers pre-migration audit and data cleanup, field mapping, duplicate resolution, test migration and validation, and production migration with post-migration checks. As noted in Step 3, skipping data preparation consistently adds 30–50% to the budget, which makes upfront cleanup the more cost-effective choice.
Who owns data-quality decisions during a Salesforce migration?
Data-quality decisions belong to named business owners, not the migration developer or Salesforce admin. The business owner defines which records are in scope, approves field mappings, signs off on duplicate resolution rules, and validates that migrated data reflects operational reality. The technical team then implements those decisions. When ownership is unclear, governance gaps appear: records that should have been archived get migrated, field mappings get approved without context, and post-go-live rework becomes the default. Every migration project needs a named cutover lead, a named data lead, and a named business validator with explicit sign-off authority at each checkpoint.
How do you scale data governance after go-live?
Post-migration governance scales through three structures: named domain owners, automated monitoring, and a defined escalation path for quality violations. Each domain such as accounts, contacts, opportunities, and activities needs an accountable owner who reviews metrics and approves exceptions. Automated dashboards should track duplicate rates, null values in required fields, orphaned child records, and referential integrity on a regular cadence. Alerts must route to a named owner and create a tracked incident, not just a notification. The governance playbook built during the migration should pass to the operating team with standards, known issues, and resolution procedures. Coffee’s Companion App for Salesforce supports this by automating the “data in” side, which reduces post-migration data drift caused by manual entry gaps.
What is the correct parent-child load order for a Salesforce migration?
The correct sequence appears in the Step 8 table, and the key rule is simple: parents always load before children. Start with Users, Roles, and Teams so every record has a valid owner, then follow the dependency chain through Accounts, Contacts, Products, Opportunities, and Line Items. Activities and attachments load last because they reference all other objects. Deviating from this order causes hard load failures or empty relationship fields that are difficult and expensive to repair.
What are the rollback triggers for a Salesforce migration cutover?
Rollback criteria must be numeric and agreed upon before cutover begins, not debated during an incident. As defined in Step 11, rollback triggers include user-reported data loss above 15%, corruption above 1%, record count discrepancies above 5%, or any broken regulated workflow. The practical rollback window usually covers the first few days after cutover. After roughly 72 hours, fixing the target in place often costs less than reversing the migration. Keep the legacy system available in at least read-only mode for a period after cutover to support rollback readiness and issue detection.
Conclusion: Follow the Sequence, Protect Your Data
A clean Salesforce migration depends on a strict sequence. Scope and audit before any extract, fix quality issues in the source, configure External IDs and disable automations before any load, follow parent-child load order without exception, validate in sandbox before touching production, freeze the legacy system during cutover, and keep numeric rollback triggers active throughout the window. Each of the 12 steps in this checklist has a defined input, checkpoint, and output. Skipping any one of them shifts cost from prevention to remediation.
The migration cutover does not mark the finish line. High-performing organizations treat migration as the starting point for continuous monitoring that protects data integrity in the new system. Coffee’s Companion App for Salesforce acts as the permanent agent layer that enforces that standard, preventing the manual entry gaps described in Step 12 from causing data drift to recur.
Get started with Coffee and put an agent to work on your Salesforce data quality from day one.
