Migrate from Salesforce to EspoCRM

Migrate from Salesforce to EspoCRM for standard-object sales teams

EspoCRM suits sales teams that run on standard accounts, contacts, leads and opportunities. If your renewal is driving the decision, whether through per-seat increases, a data residency requirement or concern about lock-in, the first question is how much of your Salesforce org sits in those four standard objects and in simple custom fields. When that footprint is modest, EspoCRM can usually be configured through its Entity Manager, Formula Script and workflows without rewriting the business process. The move is typically run by your own administrators, with an implementation partner handling hosting, data loading, integration rework and cutover planning. Effort and risk are driven mainly by the number of custom entities, the volume of history you need to carry over, and how many external systems write to Salesforce today.

Before you commit, inventory every Apex trigger, Flow, validation rule and AppExchange package in the org, and record which ones users depend on daily. Apex and AppExchange dependence changes the picture materially: logic written in Apex has no direct EspoCRM equivalent, and managed packages usually have no open-source counterpart, so each one becomes a redesign decision rather than a copy. Ask your current Salesforce partner or internal developers to produce that list, then score each item as recreate, replace with an integration, or retire. A short pilot with one sales team, using a copy of real exported data, will show quickly whether the standard-object model fits your process or whether a heavier platform should be considered.

Confirm the EspoCRM edition and extensions you need before sizing the system. The open-source edition is free to download and self-host under AGPL-3.0, but reports, Business Process Management and workflows sit in the Advanced Pack, which is included in EspoCRM Cloud plans and is a separate add-on for self-hosted deployments, so confirm that licensing position directly with EspoCRM. Also confirm which identity method your organization requires, since EspoCRM supports OpenID Connect and LDAP, and that its own two-factor authentication is not compatible with OIDC. Put these questions in writing to your implementation partner so the quote reflects the components you will actually run.

Which Salesforce capabilities map cleanly to EspoCRM

This table compares the Salesforce Sales Cloud capabilities a sales team typically relies on with their EspoCRM equivalents, marking each as clean, needs rework or gap. Reports and BPM sit in the Advanced Pack, which is included in EspoCRM Cloud plans and available as an official add-on for self-hosted installs. Use it to size the rebuild work before you commit to a cutover date.

Capability	EspoCRM equivalent	Fit
Standard objects (accounts, contacts, leads, opportunities)	Built-in Account, Contact, Lead and Opportunity entities with their core fields	clean
Custom fields	Created in the Entity Manager; confirm field types match your Salesforce data before import	clean
Custom objects	Custom entities created in the admin tools; relationships must be modeled again by hand	needs rework
Reports and dashboards	Reports require the Advanced Pack, included in EspoCRM Cloud plans and an official add-on for self-hosted installs; rebuild each Salesforce report	needs rework
Workflows and process automation	Workflows and BPM in the Advanced Pack; before-save logic uses Formula Script, so Flow and Apex logic must be rewritten	needs rework
Apex triggers and custom code	No direct equivalent; logic must be reimplemented as Formula Script or custom extensions	gap
Sign-in (OIDC and LDAP)	OpenID Connect since version 7.3 and LDAP including Active Directory; EspoCRM's own 2FA is not compatible with OIDC	clean
API access	REST API with API key, HMAC and basic authentication through dedicated API users; HMAC is the recommended method	needs rework
AppExchange integrations	Official extensions cover a limited set of services; confirm each connector you use exists before you plan the exit	gap

How Salesforce data and logic land in EspoCRM

Most of the rebuild happens in EspoCRM's Entity Manager and Layout Manager, not in code. Standard Salesforce objects such as accounts, contacts, opportunities and tasks have counterparts in EspoCRM's built-in entities, so the first job is a field map: for each Salesforce field, decide whether it maps to an existing EspoCRM field, needs a new custom field on that entity, or needs a new custom entity for a Salesforce custom object. Record the Salesforce API name, field type, picklist values and required flag in that map, because EspoCRM field types and option lists do not always match Salesforce one for one. Relationships such as account to contact or opportunity to account need to be defined explicitly before the CSV files are loaded, so that the import can populate the link columns correctly. Confirm the exact field types and relationship options available in your EspoCRM version before you finalize the map.

Formula Script covers a useful share of the simple before-save logic that Salesforce teams wrote as validation rules, field defaults or formula fields. It is configured in before-save scripts in the Entity Manager, and the same language also runs in API before-save scripts, workflows and Business Process Management (BPM). Its scope is narrower than Apex, so any Salesforce Flow or Apex trigger that calls external services, performs complex bulk processing or runs across many related records should be listed separately and re-scoped. Workflows and BPM, which are part of the paid Advanced Pack in the cloud plans, handle much of the multi-step Flow logic, but confirm which of your Flows depend on features only in self-hosted installs with that extension. Each rebuilt rule needs a test case that uses real migrated records in a staging instance.

Treat Formula Script as a replacement for logic you can express, not a port of Apex. Any Apex class that depends on governor-limit patterns, asynchronous jobs or custom Lightning components will need a different design, usually an external service that calls the EspoCRM REST API, which in turn needs a dedicated API user with the narrowest role permissions. Before cutover, document which automations are rebuilt in Formula Script, which move to workflows or BPM, and which are retired, and have a business owner sign off on the retired list. That document also becomes the input for a quote from any implementation partner, since the number of logic items drives the effort more than the record count does.

What data to extract and which integrations to replace

Salesforce gives you two documented export routes, and EspoCRM gives you its import tooling, identity options and REST API on the receiving end. The cards below follow the data from export to import, then to identity and integrations, and they flag what each step leaves behind. Plan these together, because a clean record import still fails if users, attachments or integration credentials are not mapped.

Data Export Service cadence

The Data Export Service packages org data as CSV files in a compressed archive. Per the documented schedule, it runs weekly in Enterprise, Performance and Unlimited editions and every 29 days in Professional and Developer editions. Plan your final extract around that cadence, so the delta between your last export and cutover is small. Confirm which objects and whether your org includes files and attachments in the export, because the default output does not replace a separate file check.

Data Loader for scripted extracts

Data Loader is a separately installed client that runs from a graphical interface or the command line, so it suits repeatable, scripted extracts. Use it for objects the Data Export Service does not cover well, or for a dry run before cutover. Ask your Salesforce admin which user runs it, because its permissions set what records come out. Keep the output files, the mapping definitions and the run logs together so a re-run produces the same columns.

Importing records into EspoCRM

Map each Salesforce object to an EspoCRM entity before you import, and load parent records such as accounts before contacts and opportunities so the relationships resolve. Use the import tool for CSV files, and test with a small subset that includes one account with many contacts. Check that custom fields exist in the Entity Manager first, since a missing field can cause rows to fail or silently drop values. Keep the Salesforce record IDs in a dedicated field so you can trace records back to the source.

Mapping users through OIDC or LDAP

Salesforce users and their roles must map to EspoCRM users, teams and roles before anyone signs in. EspoCRM supports OpenID Connect sign-in with optional user creation on first login and mapping of identity provider groups to teams, and it also documents LDAP, including Active Directory and OpenLDAP. Decide which identity source is authoritative, and remember that EspoCRM's own two-factor authentication is not compatible with OIDC. Ask whether owner fields in exported records should map to existing accounts or to placeholder users.

Replacing integrations with the REST API

Each Salesforce integration, such as a marketing sync or an ERP connector, needs an equivalent that calls the EspoCRM REST API. Create a dedicated API user with only the roles that integration requires, and prefer HMAC authentication, which the docs describe as the most secure option. Basic authentication is documented as not recommended, so avoid it for new integrations. Inventory every connected app and middleware job first, because Apex triggers and AppExchange packages do not transfer and each needs a rebuilt or retired counterpart.

Gaps in exports and files

Exports carry records and field values, but they do not automatically move everything you rely on. Confirm how attachments, files, email content and data from connected integrations are handled, since these often sit outside the standard export. Plan a separate extraction and checksum step for files, and decide whether historical email stays in an archive. Document each excluded item with its owner, so no one discovers a missing contract attachment after you retire the Salesforce org.

The migration sequence from inventory to decommission

This sequence moves one sales team at a time from Salesforce Sales Cloud to EspoCRM, proving each step with counts and pipeline totals before the next one starts. It ends with a documented, archived export so the old org can be shut down without losing records.

Inventory objects, fields and automations
Your admin lists every standard and custom object in use, the fields on each, the active flows, validation rules, approval processes and reports, and the integrations that read or write data. A sales operations owner confirms which items the sales team uses day to day and which are left over from old projects. The output is a signed inventory that maps each item to an EspoCRM entity, field, formula script, workflow or external integration, or marks it as dropped. You know this step is done when every item has one of those outcomes and the sales lead has approved the list.
Build a test instance and recreate the model
The implementation team installs EspoCRM on a test host inside your infrastructure and recreates the agreed entities and fields in the Entity Manager, along with teams, roles and the Formula Script logic from the inventory. Sample data is loaded from CSV extracts so the import mapping can be tested before any real records move. The output is a working test instance with a documented field map and a list of import errors. The step is done when a test import of each object type completes and the errors are either fixed or recorded as known issues.
Pilot with one sales team
One sales team uses the test instance for its normal pipeline work for an agreed period, with the pilot's scope written down in advance. Users check that stages, probabilities, assignments, activities and reports behave as they did in Salesforce, and they log every gap in a shared tracker. The output is a list of accepted differences and a set of fixes, each with an owner. The next step starts only when the sales lead signs off that the pilot team can run its daily work in EspoCRM.
Run a parallel period with reconciliation
Production EspoCRM runs alongside Salesforce for a defined window, with a scheduled import from the latest Salesforce extract. Record counts per object, open pipeline totals by stage and owner, and closed-won totals for the period are compared between both systems and recorded in a reconciliation report. Differences are traced to a cause such as a failed row, a timezone conversion or a changed owner, and fixed in the import mapping. The output is a reconciliation report with every variance explained. You know this step is done when the totals match or every remaining variance has an approved explanation.
Cut over with a final delta extract
The sales team stops writing to Salesforce, the final delta extract is taken from the Data Export Service or Data Loader, and only records changed since the last import are loaded into EspoCRM. Integrations are switched to the EspoCRM REST API using dedicated API users with role-based permissions, and scheduled jobs are confirmed to run through cron. The output is a production instance with the final counts and totals checked against the Salesforce snapshot taken at cutover. The step is done when the reconciliation repeats cleanly and the integration owners confirm that data flows in the new direction.
Decommission with an archived export
After a read-only period agreed with the business, you take a full archived export of the Salesforce org, store it under your own retention rules and document where it sits and who can access it. Salesforce licenses, integrations and scheduled jobs are then deactivated in a controlled order, and access is removed for former users. The output is an archive record with its location, checksum and retention owner, plus a closure note for the programme. The decommission is complete when the archive has been restored or sampled successfully and the Salesforce subscription is formally ended.

What drives the cost and duration of the move

This table lists the main drivers of effort and cost when moving Salesforce Sales Cloud to EspoCRM, with why each one matters and how to keep it down. Read it as a checklist for scoping, since most of the spend follows from how many custom objects, automations and integrations you carry across. Hosting fees are usually the smallest and most predictable line, while data work and internal admin time tend to set the schedule.

Driver	Why it changes cost or effort	How to keep it down
Custom objects and fields	Each custom object needs an entity defined in the Entity Manager, with fields, layouts and permissions rebuilt by hand. Field count drives both admin work and import mapping.	Inventory fields in your Salesforce org first, then drop unused ones. Map standard objects before adding custom entities.
Automation to rebuild	Workflow Rules and Process Builder have no direct copy. Flows, triggers and Apex must be re-expressed with EspoCRM workflows, BPM (in the Advanced Pack) or Formula Script.	Rank automations by business value and retire the ones nobody uses. Confirm which features need the Advanced Pack before you budget for it.
Integration count	Each Salesforce connector or custom integration must be replaced or reconnected through the REST API, with its own authentication, field mapping and error handling.	List every integration with its owner and data flow. Replace the high-volume ones first and retire the rest.
Identity and sign-in setup	Connecting OpenID Connect or LDAP means agreeing group-to-team mapping, first-login user creation and a fallback login, and EspoCRM's own 2FA is not compatible with OIDC.	Decide the identity provider and group model before the import. Test sign-in with a pilot group.
Data quality and deduplication	Duplicate accounts, stale contacts and inconsistent picklist values slow the import and create bad records in the new system. Cleanup often takes longer than the import itself.	Deduplicate and standardize in Salesforce before the final export. Agree rules for what is migrated and what is archived.
Hosting choice	Self-hosting adds server build, PHP and database setup, backups and upgrades. The cloud option trades that work for a per-user subscription (EspoCRM Cloud is listed at 15, 25 and 69 US dollars per user per month, per the EspoCRM pricing page).	Compare the hosting work you can staff with the monthly cost of the cloud plans. Ask the partner to quote the self-hosted and cloud options side by side.
Internal admin availability	Someone who knows Salesforce and the business process must sign off on mappings, test cases and cutover. Limited availability extends the schedule more than any technical item.	Name an admin owner and a business approver early. Book their time in the plan rather than assuming it.
Support and upgrades (recurring)	EspoCRM major releases and extension updates need testing and deployment. Support cost depends on how often you change the system after go-live.	Use the built-in backup and upgrade utility, keep a tested rollback, and agree which upgrades a support retainer covers.

How the move differs by team size and starting point

This is the situation where EspoCRM usually fits best. Accounts, contacts, leads, opportunities and tasks map to EspoCRM's standard entities with little redesign, and the main work is cleaning exported CSV files, mapping fields and training users on the interface. Most of the effort sits in data quality, not in building logic, so the project is largely a one-time import with a short parallel run. Recurring cost is the hosting you pay for and the administrator time you allocate to user and field changes.

Field mapping: Standard fields usually map one to one, so the list of fields to recreate in the Entity Manager stays short.
Simple pipelines: A single sales pipeline with a few stages is straightforward to rebuild with EspoCRM's stage and status settings.
Limited automation: Basic assignment and notification rules can often be recreated without custom code.
Import validation: Duplicate contacts and orphaned records are the most common problems and need a cleanup pass before import.
Cutover: A short parallel run with a freeze on Salesforce edits is usually enough.

Before committing, confirm which Salesforce reports, dashboards and email templates your sales managers rely on, and whether the team needs the reports and workflow features that EspoCRM provides in its paid Advanced Pack.

What usually goes wrong and how to prevent it

Most failed Salesforce exits to EspoCRM do not fail during the import itself. They fail afterward, when history is missing, records are duplicated, users see the wrong data, or a process that nobody wrote down stops running. The cards below cover the risks that recur most often and a concrete check for each one before cutover.

Lost attachments and history

A standard CSV extract carries field values but not the binary files, and the Data Export Service only includes attachments when you choose that option. Activity history, notes and files may sit in separate exports, so a plain import can leave accounts and opportunities without their timeline. Before cutover, confirm which files and activity records you exported and test a sample account end to end in EspoCRM, including its attachments and history, before accepting the full dataset.

Duplicate records after import

Re-running an import, or loading the same contacts from both an old extract and a fresh one, creates duplicate accounts and people. Duplicates then split activity and pipeline across records, and sales reps stop trusting the data. Assign each Salesforce record ID to a dedicated external ID field, use it as the matching key on every run, and run each import once in a staging instance so that reruns update rather than add.

Broken ownership and team mapping

Salesforce owner IDs do not match EspoCRM user IDs, so records can arrive unassigned or assigned to a retired account. Teams and role-based permissions then decide who sees which pipeline, and a wrong mapping can expose customer data to the wrong group. Build a user map from Salesforce usernames to EspoCRM users before importing, create teams that mirror your Salesforce roles, and check record visibility for at least one user per role before anyone logs in.

Automations that silently stop

Salesforce Workflow Rules, Process Builder flows and Apex triggers do not move to EspoCRM. Nothing reports an error when they stop, so lead assignment, follow-up tasks and stage notifications simply cease. List every active automation in the source org, then rebuild each one as a Formula Script, workflow or BPM flow and test each rule with a sample record to confirm it fires as the original did.

Integration gaps after connector removal

Marketing forms, email sync, telephony and ERP links often run through Salesforce connectors or AppExchange packages. Removing the Salesforce side cuts those feeds without warning, and the EspoCRM side may have no matching integration. Inventory every system that reads or writes Salesforce data, then decide per system whether an official extension, a REST API script or a retirement is the answer. Use dedicated API users with HMAC authentication, since the docs describe basic authentication as not recommended, and keep the Salesforce connector running in parallel until each feed is verified.

2FA conflicts with OIDC sign-in

If you enable OpenID Connect sign-in, EspoCRM's own two-factor authentication is not compatible with it, so users may find that the second factor they set up does not apply or that login flows break. Users then ask for workarounds that weaken access control. Decide before rollout which factor is enforced at the identity provider, document a fallback login method for administrators, and test sign-in, logout and first-login user creation with a pilot group.

Questions buyers ask before moving from Salesforce to EspoCRM

How much effort does a move from Salesforce to EspoCRM take?

The effort depends mostly on how much of your Salesforce org is standard. A sales team that uses accounts, contacts, leads, opportunities and tasks with a few custom fields has a much smaller job than one with dozens of custom objects, Apex triggers, Flows and managed AppExchange packages. The main work falls into four parts: exporting and cleaning CSV extracts, recreating custom fields and entities in the Entity Manager, rebuilding automation with Formula Script, workflows and BPM, and replacing integrations with the REST API. Each part grows with the number of records, the volume of attachments and the number of integrations that feed the CRM. Ask any implementation partner for a written breakdown by these four parts before work starts.

How long does a Salesforce to EspoCRM migration usually run?

No duration can be stated for your organization until the inventory of objects, fields, automation and integrations is complete. The schedule is driven by the number of custom entities, the amount of historical data your sales team needs to keep, how many systems depend on Salesforce APIs, and how much parallel running you want during cutover. Plan separate time for user acceptance testing with real pipelines, and for a rollback window in case imports or integrations need correction. A fixed-scope written plan from DeployOpen will state the timeline for your scope before any work starts, so ask for the milestones and the acceptance criteria attached to each one.

Can our internal Salesforce admins migrate to EspoCRM alone?

Internal admins with Salesforce experience can often handle the admin side of a small, standard-object migration, including the Entity Manager, layouts, roles and teams. They usually need help with the parts that depend on server work and integration design: installing and hardening the server, configuring cron for background jobs, setting up backups and upgrades, and writing API clients that replace Salesforce integrations. Be honest about the time they can give to the project alongside their day jobs. A useful test is whether someone on your team can explain how each Apex trigger or Flow in scope will behave in EspoCRM before the cutover date.

What does our team need to provide for the migration?

The project needs a named business owner who can decide field mappings and sign off on process changes, a sales operations lead who knows how pipelines are used day to day, someone who can run a full Salesforce data export and confirm record counts, and an IT contact who can provide hosting, DNS, certificates and identity settings. If you plan to sign in with OIDC or LDAP, your identity team must provide the identity provider configuration and group mappings. Security or compliance staff should review where the data will be hosted and who holds administrative access. Confirm each of these responsibilities in the written scope so that delays on your side are visible.

Can EspoCRM replace Salesforce Apex code and AppExchange apps?

EspoCRM can replace many common Apex and Flow patterns with Formula Script, before-save scripts, workflows and BPM, and the Advanced Pack adds reports and business process management in its paid cloud plans. It does not run Apex, and most AppExchange packages will not install into it. Each Apex class, trigger and managed package needs an individual review: some logic moves cleanly, some needs a custom PHP extension or an external service, and some has no practical equivalent and should be dropped or redesigned. Build an inventory with a go or no-go decision for each item, and treat any package that has no open-source counterpart as a scope question, not an assumption.

How does EspoCRM Cloud pricing compare with self-hosting?

The EspoCRM pricing page lists EspoCRM Cloud at 15 US dollars per user per month on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included in all cloud plans. The open-source edition can be downloaded and self-hosted for free, so the self-hosted cost is made up of infrastructure, implementation, backups, upgrades, support and internal admin time. Cloud costs scale with seats, while self-hosting costs depend more on the size of the server, the scope of the migration and who maintains the platform. Compare both over the same number of years, and include the Advanced Pack or equivalent reporting and workflow work in the self-hosted side.

How do we request a quote from a fixed-scope written plan?

Send a written description of your Salesforce org, including object counts, custom fields, Apex and Flow inventory, installed packages, integrations, user counts and data volumes, plus your target go-live window and any compliance requirements. DeployOpen works from that information to propose a fixed scope, deliverables and timeline in writing before work starts. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask that the plan separate one-time migration work from recurring items such as hosting, backup checks, upgrades and optional retainer support, and that each deliverable has an acceptance criterion.

How DeployOpen scopes and runs the Salesforce to EspoCRM migration

A written scope comes first, then a staged move of Salesforce data and sales processes into EspoCRM on infrastructure the client controls, ending with hardened, documented and backed-up systems that the client's team can run.

Agree the written scope and inventory
DeployOpen reviews the Salesforce org with the client's admin and sales leads, listing standard objects in use, custom objects and fields, Apex classes, flows, AppExchange packages, integrations and reports. The output is a written scope that names what moves, what is rebuilt, what is retired and what is excluded, together with deliverables and timelines. Work starts only after the client signs off on that document, and the quote follows from the same scope.
Confirm the hosting target and access model
DeployOpen and the client agree where EspoCRM will run, whether in the client's cloud account, a data center or an air-gapped network, and which server stack applies. The team checks the supported PHP, database and web server versions in the EspoCRM server configuration docs and confirms that cron or a scheduled task can run background jobs. Identity decisions, such as OIDC or LDAP sign-in and the fallback login method, are recorded here, since EspoCRM's own 2FA is not compatible with OIDC. The step closes when the environment, access model and sign-in design are approved in writing.
Build the hardened EspoCRM environment
DeployOpen installs EspoCRM in the agreed environment, using the installation script for Ubuntu, Debian or Linux Mint where it fits the client's standards, or a manually built stack where it does not. The team configures TLS, restricts administrative access, sets up API users with role-based permissions and selects the authentication method for API calls, favoring HMAC over basic authentication. Backups are scheduled and a restore is tested on a separate host. The closing check is a hardening report against the agreed baseline and a documented restore run.
Extract and map Salesforce data
DeployOpen works with the client to export data from Salesforce, either through the Data Export Service on its documented cadence or through Data Loader for repeatable extracts. Each Salesforce object and field is mapped to an EspoCRM entity or field, with decisions on record ownership, teams, duplicates and attachments. Records that Salesforce keeps outside the export, such as email content and some integration data, are listed as gaps for the client to resolve. The step closes with a signed mapping sheet and a row-count reconciliation plan.
Recreate entities, fields and automation
DeployOpen rebuilds custom entities and fields in the EspoCRM Entity Manager and recreates required logic with Formula Script in before-save scripts, workflows and, where licensed, BPM. Reports and dashboards are rebuilt where the Advanced Pack is in use. Each Salesforce automation is classified as rebuilt, replaced or dropped, and anything that depended on Apex code is flagged for the client's decision. The closing output is a rebuild register that lists every object, field and automation with its status.
Import data and replace integrations
DeployOpen imports the CSV extracts into EspoCRM using its import tool, first in a non-production copy and then in the production instance after the client approves the results. Existing Salesforce integrations are replaced with calls to the EspoCRM REST API or with official extensions where those cover the need, and each connection is tested with real sample records. Imported counts are compared with the source extracts and exceptions are logged. The step closes when the reconciliation report and integration test results are accepted by the client.
Run user acceptance and cutover
Sales and admin users test pipelines, lead handling, reports and permissions against the scope in a staging copy. DeployOpen fixes defects that fall within the agreed scope and records changes that go beyond it as a separate quote. The cutover plan sets the freeze, final extract, import and rollback points, and the client confirms who signs off. Cutover is complete when users have logged in through the agreed sign-in method and the rollback point has been tested.
Hand over documentation and support options
DeployOpen delivers architecture notes, admin runbooks, the backup and restore procedure, the upgrade procedure and the rebuild register, so the client's administrators can operate EspoCRM without DeployOpen. The client chooses whether to keep operating in-house or to take a retainer for upgrades, monitoring and support, which is priced from its own written scope. DeployOpen does not publish a price list. The handover closes when the client accepts the documentation pack and the support model is recorded in writing.

Migrate from Salesforce to EspoCRM