Companies stay on Salesforce because the org stopped being a list of customers and deals. Custom objects, fields, validation rules, automations, Apex, integrations, reports, and permission models grew around it until the CRM was part of how sales operates. Exporting the records does not recreate those dependencies.
Quick answer
A Salesforce migration is a dependency problem. The database of accounts, contacts, and deals is the portable part. The expensive part is the business logic the company built on the platform: objects that reference each other, flows that fire other flows, API fields an integration expects, and reports an executive team already uses. Before you pay for a migration project, run a read-only inventory and separate what looks portable, what has to be rebuilt, and what you still cannot see.
Best for: a team that is tired of the licence and the admin load, and wants evidence of how deep the lock-in goes before hiring a migration partner. Honest limit: a basic Salesforce MCP connection cannot see every flow, Apex class, or installed package. A partial inventory is a starting point. It does not prove you can leave.
Cipher Projects is an Australian-led studio that ships production AI agents and the systems around them. We use this read-only pass when a company wants to know whether a CRM move is an export or a rebuild, including orgs that already sit under a CRM, website, and assistant that have to keep working during any change.
Last updated: 11 October 2026. Salesforce tool names below are from the hosted SObject Reads MCP server.
Why don't companies just leave Salesforce?
They leave the licence conversation and stay for the operating model. Salesforce is expensive to keep, and customising it takes ongoing admin and developer time. The switching cost is the process that now lives inside the org, not the monthly invoice.
At the start, a CRM looks like familiar records:
- Customers
- Contacts
- Deals
- Activities
- Notes
Most modern databases can store those. Over years, the org picks up custom objects, relationships, validation rules, automations, Apex, integrations, reports, and a permission model. Salespeople work inside that shape every day. The CRM becomes part of how the business operates.
Is exporting the database a Salesforce migration?
A CSV of accounts and opportunities is the portable part. The records travel, and the behaviour stays behind.
Picture an org with 150 custom objects. That number is an illustration, not a client count. Some objects are obsolete. Some hold history you still need. Some sit under a workflow a salesperson uses every day. One object references three others. A flow updates a field that starts another process. An integration expects one API name to stay put. A report feeds a decision the executive team already makes.
Exporting the rows leaves those links behind. Finding them after the migration has started is an expensive way to learn your own business. The question that matters is how much of the business logic depends on the platform.
| What you might count | What a move actually requires |
|---|---|
| Accounts, contacts, deals, activities, notes | Export the rows, then remap Salesforce IDs so relationships survive |
| Custom objects and fields | Rebuild the schema in the destination. Dead objects should be confirmed, then left behind |
| Validation rules, flows, Apex | Rewrite them. They do not import as portable configuration |
| Integrations | Reconnect each system. One field name can be a contract with another product |
| Reports and dashboards | Recreate the ones people decide from, or lose the decision, not just the chart |
| Profiles and permission sets | Rebuild who can see what in the new tool's own model |
Can an AI agent show how deep the lock-in goes?
A read-only agent can inventory a slice of the org and force the unknowns into the open. That is enough to change a migration conversation from a guess into evidence.
Salesforce exposes data and metadata through APIs. Its hosted SObject Reads MCP server is the safe door for this job: agents can discover schema, query records, search, and walk relationships, and they cannot create, update, or delete. The tools that matter here are getObjectSchema (an object index with no arguments, then fields and relationships for one object) and soqlQuery (reads, including counts, with a filter and a limit).
With only that connection, an agent can list objects, inspect fields it is allowed to see, count accessible records, map relationships, and flag likely dependencies. It will miss anything the connected user cannot see, because sharing rules still apply.
Flows, Apex, validation rules, permission sets, and installed packages need a metadata retrieve, the Tooling API, or an administrator export. If those tools are not connected, the report should say unknown. Unknown is a finding. It means you do not yet know how far down the rabbit hole you are.
What can Salesforce MCP see, and what stays unknown?
Treat SObject Reads as a partial inventory. Use the gaps to decide the next admin export, not to declare the org simple.
| Layer | Read-only MCP | Still needs an admin path |
|---|---|---|
| Standard and custom objects | Index of queryable objects via getObjectSchema |
Objects this user cannot query |
| Fields and relationships | Types, required flags, picklists, lookups | Full formula logic, history-tracking setup |
| Record counts | Counts the connected user can query | Rows hidden by sharing |
| Automation and code | Not on this server. Write unknown | Flows, workflow rules, validation rules, Apex |
| Integrations | Object and field names that look like another system | Connected apps, named credentials, middleware |
| Permissions | What this login can see | Profiles, permission sets, the rest of the org |
How do you run a Salesforce migration readiness assessment?
Connect an AI agent to Salesforce MCP with an authorised user, keep the session read-only, and ask for a report that separates evidence from gaps.
Use SObject Reads, or another MCP server locked to read mode. Do not point the agent at a server that can create, update, or delete records. The goal is a migration-readiness report covering standard and custom objects, record counts, fields and relationships, automation and custom code, integrations, blockers, missing permissions, and the next checks required to judge portability.
Copy the prompt below.
You are running a read-only Salesforce migration readiness assessment.
Rules:
- Use only read tools. Prefer Salesforce hosted SObject Reads (getObjectSchema, soqlQuery, and the other read tools on that server). Do not create, update, or delete records. Do not run Apex. Do not change metadata.
- Work as the connected user. If a query fails, record the error and the missing permission. Do not ask for a broader login unless the report cannot continue.
- Call getObjectSchema with no arguments first, then again per object before you describe fields.
- For counts, use a bounded query. If the API refuses a count, say so and give the closest figure you could retrieve.
- If you cannot see flows, Apex, validation rules, permission sets, connected apps, or installed packages, write "unknown" for that section. Do not infer that they are absent.
- This report does not prove a migration will succeed. It estimates how much business logic appears to depend on this org.
Produce these sections:
1. Access
- Org and user you can see
- Which tools responded
- What you were denied
2. Objects
- Standard objects in use, with record counts you could actually query
- Custom objects: API name, label, record count, and a last-modified signal if a field exists
- Objects with no records or no recent change are candidates to confirm with an admin, not objects you may drop
3. Fields and relationships
- For each custom object, and for Account, Contact, Opportunity, Lead, Case, Task, and Event: custom field count, required fields, lookup and master-detail relationships
- Note Task and Event WhoId and WhatId if you can see them
- Name formula and roll-up fields. Do not try to reimplement them
4. Data you can reach
- Counts the connected user can query
- Objects that returned insufficient access
- Whether OpportunityHistory or field history is queryable
5. Automation and code
- State that SObject Reads does not return Flow, Process Builder, workflow rules, validation rules, or Apex
- If a metadata or tooling tool is actually connected, list what you found. Otherwise write: unknown, needs a metadata retrieve or an admin
6. Integrations and dependencies
- Custom objects or fields whose names suggest an external system
- Say when named credentials and connected apps were not visible
7. Migration blockers, evidence only
- For each item: what you observed, why it would have to be rebuilt, and what is still unknown
- Split portable records from logic that has to be rebuilt
8. Next checks before anyone prices a migration
- Metadata export for flows, validation rules, permission sets, and installed packages
- An integration list from the people who own each connected system
- Twenty records on the busiest custom objects, walked through with a salesperson
- A decision to stay, simplify the org, or migrate, plus the fact that would change it
End with one sentence: how far down the rabbit hole this org appears to be, and what you could not see.What do you do with the report?
Use it to choose the next conversation. A clean object list still needs a metadata export before anyone cuts over.
| What the inventory shows | Next conversation |
|---|---|
| Mostly standard objects, few custom relationships, integrations you can name | A migration can be scoped. Still export metadata before anyone quotes a fixed price |
| A large custom-object graph, and automation or Apex marked unknown | Price a rebuild, or simplify inside Salesforce first. Guessing a timeline from record count will be wrong |
| The agent could not see metadata at all | Stop. Retrieve metadata with an admin, then talk. A partner who prices the move from a CSV is pricing the easy part |
The result will not prove you can migrate. It gives you a starting point: what you have, what looks portable, what has to be rebuilt, and what remains unknown.
FAQ
Why don't companies migrate off Salesforce?
Because the org has become part of how sales operates. Custom objects, automations, Apex, integrations, reports, and permissions are business logic. Moving the database does not move that logic.
Is a Salesforce data export the same as a migration?
No. An export gives you rows and Salesforce IDs. Relationships, validation, flows, code, and the tools connected to specific fields have to be rebuilt or reconnected in the destination.
Can an AI agent see Apex and flows through Salesforce MCP?
Not through SObject Reads. That server covers schema and records for the connected user. Flows, Apex, validation rules, and installed packages stay unknown until you add a metadata or tooling path, or an admin export.
What should we know before we pay for a Salesforce migration?
How many custom objects are still in use, which relationships and integrations depend on them, and which automations nobody has listed yet. Record count is the wrong sizing number.
Who should we talk to about a Salesforce migration?
Talk to someone who will read the inventory before they propose a destination. Cipher Projects will have that conversation with you: what looks portable, what has to be rebuilt, and whether the honest outcome is to stay.
Salesforce will let you export the data. The work is discovering what the business built on top of it, and how much of that you would have to rebuild to leave. Run the prompt. The unknown rows are how deep your rabbit hole goes.