Leaving Salesforce for a Custom CRM: How to Exit Clean

Salesforce is the most powerful CRM on the market and one of the most aggressively lock-in-maximising software products in the enterprise space. The average mid-market team pays $75 to $150 per user per month, requires a dedicated admin, and runs a configuration where 30 to 40 percent of objects are either unused or were built for a project that ended two years ago.

A custom CRM migration from Salesforce is genuinely complex. But it is done successfully every year by teams that plan it correctly.

Paying $50,000 or more per year for Salesforce and spending as much on admin overhead as the licence itself? Schedule a 30-minute call and we will scope the extraction before you cancel the subscription. talk to us

Key Takeaways

• After cancellation, Salesforce gives 30 days of data access. Export everything, including all custom objects and the full activity history, before the subscription ends.
• Salesforce's custom object model is the primary migration complexity. A mature org with 20-plus custom objects requires a separate field mapping exercise per object and a load sequence that preserves every relationship.
• Apex code, Flow, and Process Builder automations are Salesforce-specific and cannot be exported or imported. Every automation must be documented as business logic and rebuilt from scratch.
• The SFDX CLI and REST API are the most reliable extraction tools for large Salesforce migrations. The native Data Loader handles bulk exports but requires batching at scale.
• Salesforce's account-contact-opportunity hierarchy maps cleanly to a custom CRM schema. This is a structural advantage over migrating from HubSpot's contact-centric model.
• Disable all Salesforce automation before running a test migration in the sandbox. Failure fires every workflow and validation rule on every imported record, producing cascading errors.

AI App Development

Your Business. Powered by AI

We build AI-driven apps that don't just solve problems—they transform how people experience your product.

Let's talk

Why do teams leave Salesforce and what does that mean for the migration?

Teams leave Salesforce for four reasons: pricing at scale, configuration complexity for smaller teams, AI readiness, and accumulated technical debt. The reason for leaving defines the success criteria for the new CRM and must be documented before scoping the migration destination.

Understanding why the team is leaving shapes every destination CRM decision that follows.

• Pricing at scale: Sales Cloud Enterprise is approximately $165 per user per month. At 50 reps, the annual licence cost alone is $99,000 before implementation, admin, and integration costs.
• Complexity for smaller teams: Salesforce is built for organisations with dedicated admins. Teams under 50 reps frequently find that configuration overhead (validation rules, permission sets, page layouts) consumes more time than it saves.
• AI readiness argument:Salesforce Einstein and Agentforce require significant setup and mature data foundations. Teams migrating for AI often find a clean custom CRM with a modern AI stack delivers equivalent value faster.
• Define success criteria before scoping the destination. If leaving for cost, the destination must have lower total cost of ownership. If leaving for simplicity, the destination must have leaner admin overhead.

Document these criteria before writing a single migration specification. A destination CRM that solves the wrong problem costs as much as the Salesforce licence it replaces.

What can be extracted from Salesforce and what cannot?

Standard objects (Account, Contact, Lead, Opportunity, Case, Task, Event) and all custom objects export cleanly via SOQL or Data Loader. Activity body content, attachments, and email history require the REST API. Apex code, Flow automations, Validation Rules, Permission Sets, and Report definitions cannot be exported in any portable format.

The 30-day data access window after cancellation is the highest-stakes detail in any Salesforce migration. Everything must be extracted before the clock expires.

• Clean export via Data Loader or SOQL: all standard objects, all custom objects per object via SOQL query, all custom fields on standard and custom objects, all relationship fields, and all picklist values.
• REST API required for complex objects: activity history with full body content, attachments and files via ContentVersion, email history logged via Einstein Activity Capture, and junction objects for many-to-many associations.
• Not exportable in any portable format: Apex classes (must be rewritten as business logic), Flow and Process Builder automations (Salesforce-specific format), Validation Rules (Salesforce formula syntax), and Report and Dashboard definitions.

Every object in the High complexity or N/A portability row requires a separate workstream that must be scoped and staffed before the migration begins.

What makes Salesforce migrations harder than most: the custom object problem

A typical five-year-old Salesforce org has 15 to 40 custom objects. A significant portion are orphaned: created for a project that ended, used once for a campaign, or built by an admin who left. Migrating all of them adds weeks of mapping work and populates the new CRM with objects the team does not use.

The custom object audit is the most underscoped phase in most Salesforce migrations. It is also the phase that most reliably determines whether the migration finishes on time.

• Run a SOQL record count on every custom object before scoping. Any object with zero records or no record modified in the last 12 months is a candidate for archive, not migration.
• Apex triggers and validation rules encode undocumented business logic. Teams consistently discover that active triggers encode business decisions nobody on the current team made and nobody fully understands.
• Salesforce's polymorphic activity model adds structural complexity. Tasks and Events can relate to any object. Each must be re-linked to the correct destination object type during migration using cross-reference tables.

At LOW/CODE Agency, the custom object audit is a required deliverable before any migration is scoped. The object count and record counts determine the migration timeline more reliably than any other input.

What is the correct pre-migration process for a Salesforce to custom CRM migration?

Six tasks must be completed before the first SOQL query runs: full data audit, custom object triage, Apex and automation documentation, field mapping document, lead conversion decision, and external ID strategy. Skipping any one produces a class of failure that no migration script can recover from after records have been imported.

• Step 1: Full data audit. Count records per object, identify objects with no recent activity, and measure field completion rates. An object with 30 percent field completion is a data quality problem that must be addressed before migration.
• Step 2: Custom object triage. For each custom object, decide: migrate, archive, or delete. Get business owner sign-off before any deletion.
• Step 3: Apex and automation documentation. Pull every active Apex trigger, Flow, Process Builder, and Workflow Rule. Document each as plain-language business logic a developer can implement in the destination.
• Step 4: Field mapping document. Map every field on every migrating object: source API name, source type, destination field name, destination type, and transformation rule including picklist value mapping.
• Step 5: Lead conversion decision. Salesforce stores Leads and Contacts as separate objects. Decide whether to convert all Leads to Contacts before migration or archive unworked Leads.
• Step 6: External ID strategy. Add an external ID field to each destination object storing the Salesforce record ID. This cross-reference re-links relationships during migration and traces post-migration questions back to the source record.

How should the migration script structure a Salesforce to custom CRM extract?

Use SFDX CLI with SOQL queries for full control over field selection, Python with the simple_salesforce library for custom transformation logic, and the Salesforce REST API for attachments and files. Extract parent objects first, then child objects, then junction objects, then activities.

The extraction sequence is not a preference. It is the technical requirement that makes relationship re-linking possible.

• Tool selection:SFDX CLI for developer-led migrations needing SOQL query control. Data Loader for bulk exports of standard and custom objects. Python with the simple_salesforce library for migrations requiring custom transformation logic in the extraction layer.
• Extraction sequence: (1) Accounts, (2) Contacts, (3) Opportunities with Account and Contact links, (4) custom objects with parent references, (5) Tasks and Events with polymorphic object references, (6) Files and attachments via ContentVersion.
• Handling polymorphic activity links: Tasks and Events have a WhatId (Account, Opportunity, Case, or custom object) and a WhoId (Contact or Lead). The script must resolve each to the corresponding destination object ID using external ID cross-reference tables.
• Batch size management: use batches of 2,000 to 10,000 records per API call. Include retry logic for HTTP 503 governor limit errors and a progress log so the extraction can resume from the last completed batch if interrupted.

What is the correct load sequence for a Salesforce to custom CRM migration?

Load objects in this order: Users, Accounts, Contacts, converted Leads, Deals (Opportunities), custom objects in parent-before-child order, Tasks and Events, then Files and attachments. The external ID field on every destination record is the mechanism that links relationships across each subsequent load step.

• External ID linking mechanism: every Account created in the destination stores the Salesforce Account ID in the legacy external ID field. When Contacts are loaded, the script looks up the Account ID cross-reference to find the destination Account ID and sets the Account link. This mechanism propagates through every subsequent object.
• Custom objects in parent-before-child order: if a custom object has a parent relationship to Opportunity, it loads after Opportunities. If it has no parent dependency, it loads after Contacts. The rule applies to every object whether standard or custom.

Loading files and attachments last ensures every parent record exists before a binary file is linked to it. Binary file migration is the slowest phase because each file requires a separate API call, not a bulk query.

What must be rebuilt from scratch after migrating from Salesforce?

Six categories of Salesforce configuration cannot be exported or imported: Apex code, Flows and Process Builder, Validation Rules, Reports and Dashboards, integration connections, and Permission Sets and Profiles. These represent the majority of rebuild work in a Salesforce migration and must run as a parallel engineering workstream, not a post-migration task.

• Apex code: every Apex class, trigger, and test class encodes business logic that must be rewritten in the destination's language and framework. Budget this as a separate engineering workstream running in parallel with the data migration.
• Flows and Process Builder: every Salesforce Flow and Process Builder must be documented as plain-language business logic and rebuilt in the destination's automation framework from scratch.
• Validation rules: Salesforce validation rules use Salesforce formula syntax. Each rule must be documented in plain English and reimplemented in the destination's field validation framework before cutover.
• Reports and dashboards: every Salesforce report must be rebuilt in the destination's reporting engine. Export the report definitions as documentation first, then build destination equivalents during the parallel running period.
• Integration connections: every Salesforce AppExchange integration, API connection, and webhook must be reconnected to the destination CRM. Each integration is a separate sub-project.
• Permission sets and profiles: Salesforce's role hierarchy, sharing rules, and permission sets must be reimplemented as the destination CRM's role-based access control model before any user logs in.

Start the rebuild workstream the week the migration specification is signed. Teams that wait until the data is loaded discover they have clean data in a system that is not yet configured to use it.

Conclusion

A Salesforce migration is a data extraction project, a logic documentation project, and a destination configuration project happening simultaneously. The data migration script covers the first. The automation documentation covers the second. The destination CRM build covers the third. Teams that separate these three workstreams and run them in parallel go live on schedule. Teams that treat the migration as a weekend event discover the complexity on Monday morning.

Before starting any migration work, run a full object count query on every object in the Salesforce org, standard and custom, and count active records. That audit tells you the real migration scope. The 30-day data access clock starts ticking the moment the subscription is cancelled.

AI App Development

Your Business. Powered by AI

We build AI-driven apps that don't just solve problems—they transform how people experience your product.

Let's talk

Migrating off Salesforce into a custom CRM that costs less and fits better

Most Salesforce migrations are underscoped in three places: the custom object audit, the Apex documentation, and the integration rebuild. These three gaps are where migration timelines and budgets blow up, usually after the subscription has already been cancelled.

We are LOW/CODE Agency, the leading AI development partner for SMBs and mid-market businesses. We migrate teams from Salesforce to custom CRM systems: SOQL extraction, field mapping, custom object migration, Apex logic documentation, automation rebuild, and go-live parallel running, so the team exits Salesforce on time without losing data or breaking the sales workflow.

• Custom object audit before scoping begins: SOQL record counts and last-modified dates for every object in the org. Archive decisions signed off before any migration script is written.
• Apex and automation documentation as a required phase: every active trigger, Flow, and Process Builder documented as plain-language business logic before the migration starts.
• External ID strategy from the first load: every destination record stores the Salesforce source ID, enabling relationship re-linking across all subsequent object loads.
• Polymorphic activity migration handled correctly: Task and Event WhatId and WhoId references resolved to destination object IDs using cross-reference tables, not manual linking.
• 30-day extraction completed before cancellation: every standard object, every custom object, every file and attachment extracted before the data access window closes.
• Rebuild workstream running in parallel: automation, reports, integrations, and permission model rebuilt in the destination during the parallel running period, not after cutover.

With 450+ projects delivered for clients including American Express, Medtronic, Zapier, and Sotheby's, we know what a Salesforce migration looks like when the team goes live with everything intact.

If you are ready to migrate off Salesforce into a custom CRM that costs less and fits better, schedule a call with LOW/CODE Agency and we will start with the custom object audit before anything else.