Custom CRM Migration from Salesforce: The 30-Point Checklist (2026)

Salesforce migrations fail the same way every time. The data comes over clean. The automation does not. Three weeks after cutover someone discovers that the renewal-notification Flow was running on a custom object that did not get mapped, and forty renewals slipped past the team because nobody was watching that queue anymore. The CRM is fine. The business process is broken.

I have run enough custom CRM migrations off Salesforce to know that the spreadsheet of objects is the easy part. The hard part is reproducing every Workflow Rule, Process Builder, Flow, and Apex trigger as explicit business logic in the new system — and proving that logic works before the legacy org goes read-only.

This checklist is the one we run end-to-end. Use it as a scope document, a sequencing guide, or a sanity check on whatever your current vendor proposed.

1. Catalog every object. Standard objects (Account, Contact, Lead, Opportunity, Case, Campaign) and every Custom Object. List record counts, recent activity, and last-write timestamps per object.
2. Catalog every field. For each object, dump the full field schema with data type, picklist values, required flag, formula logic, and validation rules. The Metadata API is your friend here.
3. Identify the long tail. Most Salesforce orgs have 30 to 60% of fields with under 5% population. Flag them for deletion-on-migration, not rebuild.
4. Map Record Types. Each Record Type usually represents a distinct business process. The new CRM has to express that distinction explicitly — usually as a separate route or a type discriminator.
5. Catalog every automation. Workflow Rules, Process Builder flows, Flow Builder flows, Apex triggers, scheduled batch jobs, and managed packages. This list is usually 3 to 5x longer than the team thinks.
6. Catalog every integration. Both directions. Outbound (Salesforce-to-other) and inbound (other-to-Salesforce). Include the bidirectional ones that pretend to be one-way.

7. Build a master mapping table. Source object plus field, target table plus column, transform rule, validation rule, default value, and notes. One row per source field. This becomes the contract for every extract-transform-load script.
8. Decide what to consolidate. Salesforce orgs accumulate duplicate fields (`Status__c` vs `Stage__c` vs `Phase__c`). Migration is the chance to fix the data model.
9. Decide what to deprecate. Anything with under 1% population, no automation, no report, and no integration consumer. Document the decision and the count of affected records.
10. Define identifier strategy. Every migrated record gets a new UUID plus a `salesforce_id` foreign reference. The Salesforce ID stays on the record forever. Never throw it away.
11. Pick the primary key for de-dupe. Accounts on domain plus company name. Contacts on email. Opportunities on Salesforce ID (always). Run a dry-pass to surface duplicates before the real migration.
12. Build the validation harness. A script that runs after every load and compares row counts, sum-of-amount, distinct-owner-count, and ten other sanity checks between source and target. Run it after every load forever.

13. Translate each Workflow Rule. Most become Postgres triggers, application-layer event handlers, or scheduled jobs in the new CRM. Document the trigger, the condition, and the action explicitly.
14. Translate each Process Builder process. These are often chained workflow rules. Re-express them as state machines in the new application layer — clearer to maintain.
15. Translate each Flow. Flows can branch and call sub-flows. Map each one to a typed function or service module with explicit inputs, outputs, and side effects.
16. Re-express Apex triggers. Where Apex was a workaround for declarative limits, rewrite as plain application code with proper tests. Where Apex implemented complex business logic, port the algorithm and write coverage tests.
17. Identify managed-package replacements. Conga, DocuSign, Apttus, Pardot. Each becomes either a third-party integration in the new CRM or a custom feature.
18. Build the parity test suite. A set of scenarios — "create a deal, change stage to closed-won, observe X" — that runs against both old and new systems and asserts identical outcomes.

19. Inventory every integration consumer. ERP, marketing automation, support tool, data warehouse, accounting, billing — anything that talks to Salesforce in either direction.
20. Document the contract. What payload, what frequency, what auth, what failure mode. This document is the spec for the rebuild.
21. Rebuild outbound first. The new CRM emits events. Subscribe each downstream consumer to the new event stream. Compare against legacy Salesforce events for two weeks.
22. Rebuild inbound second. Anything writing to Salesforce gets pointed at the new CRM. This is where you find the integration that nobody documented because it was a one-off Zapier zap from 2019.
23. Preserve the audit trail. Every record write from an integration logs source, payload, timestamp, and result. Auditors will ask.

For more on building integrations on a custom stack, see our API development service.

24. Run both systems in parallel. The new CRM is the system of record; Salesforce is read-only mirror. Sync new-to-old for 2 to 4 weeks.
25. Train every user. Recorded sessions plus live workshops. Capture every "where did X go" question — those become release-note items.
26. Migrate attachments and files. Stream from ContentVersion to S3, regenerate references, verify checksums on every file.
27. Rebuild the top 20 reports. Not all 400. Just the ones the team actually opens weekly. Archive the rest to a static-export viewer.
28. Run the cutover checklist. Every integration green for 14 days. Every automation green for 14 days. Sales sign-off in writing.
29. Cut Salesforce to read-only. Not deactivated. Read-only with a 90-day window for retroactive lookups.
30. Plan the Salesforce contract exit. Renewal notice is usually 30 days. Coordinate the cancel date with the read-only window expiry. Do not pay for another year.

Every failed Salesforce migration we have audited (and we have audited a few that other vendors ran) failed in one of three predictable ways.

1. Lost history. Activities, notes, attachments, or email logs that did not come over. Sales loses the last-touched timestamp on an account and the renewal conversation falls apart.
2. Broken automation. The notification, escalation, or assignment rule that was implicit in Salesforce is silently missing in the new system. Deals sit in queues with no owner.
3. Integration drift. An inbound integration keeps writing to Salesforce after cutover because nobody documented it. Data shows up on neither side cleanly.

The checklist above is designed to surface all three before they bite. Real-world examples: see the J5 Sales OS case study and the Wilder Recovery operations platform case study.

Not every Salesforce org is a candidate to leave. We have told prospects to stay on Salesforce more than once. The honest signal that custom is wrong:

• You actively use Salesforce-native analytics (CRM Analytics / Tableau CRM) and the dashboards drive revenue decisions.
• Your sales process is genuinely commodity (lead-to-opp-to-quote-to-close) and matches Sales Cloud out of the box.
• You have under 20 seats and your team's pain is process discipline, not tooling.
• Your AppExchange managed packages do work that would take 6+ months to rebuild.

The honest signal that custom is right: you have built a Frankenstein of Apex, Flows, and managed packages to force Salesforce to behave like the system you actually need. At that point you are paying a license fee for a custom application you already built — just on someone else's runtime. See the full custom CRM development guide for the deeper build-vs-stay framework.

Cutover is the only step the team will remember. The playbook we run, in order, the week of cutover:

• Friday 5 PM: freeze writes to Salesforce. Communicate to the team in three channels.
• Friday 6 PM: run final delta extract. Apply to the new CRM. Run validation harness.
• Saturday 9 AM: flip integration endpoints. Verify outbound and inbound traffic flowing to the new CRM.
• Saturday 12 PM: open the new CRM to a pilot group. They run real sales workflows for 4 hours.
• Saturday 5 PM: open to the full team. Salesforce becomes read-only.
• Monday 8 AM: first business day on the new system. Engineering on standby in shared chat.
• Friday week 1: post-cutover review. Triage the top 10 issues. Patch.
• Day 90: kill the read-only Salesforce instance. Cancel the contract.