EspoCRM migration from Salesforce, SugarCRM or spreadsheets

What an EspoCRM migration involves

A migration moves accounts, contacts, leads, opportunities, activity history and attachments from Salesforce, SugarCRM or spreadsheets into a self-hosted EspoCRM instance that your organization runs. Teams usually start this work for a clear reason: a license renewal that costs more than expected, a requirement to control where customer data lives, a plan to consolidate spreadsheets that have drifted apart, or a decision to standardize on a self-hosted stack. Whatever the trigger, the work is less about copying rows and more about deciding how each source object and field maps to an EspoCRM entity and field.

Short answer: teams with a strong CRM administrator and a clean, well-understood data set often do the mapping in-house. Teams with many related objects, years of activity history or compliance constraints on who can see which records usually bring in a partner for the mapping design, test runs and cutover. Ask a partner to show how they handle relationships between records, not only the field list, because that is where most rework occurs.

EspoCRM's import is CSV-based. That means the export side belongs to the source system, and it must be confirmed early. Confirm which objects and history records the source can export, in what format, with which related identifiers, and whether attachments come out as separate files that can be linked back to their parent records. Salesforce, SugarCRM and spreadsheets each behave differently here, so run a sample export from each source before the project plan is fixed.

What the work includes

The migration runs as a sequence of work packages, and each one ends in a checkpoint your administrators can review before the next package starts.

Source assessment and export inventory

Each source is inventoried before any mapping begins: record counts per object, field owners, attachments, activity history and custom fields that exist only in the old CRM or spreadsheet. Salesforce, SugarCRM and spreadsheet exports differ in encoding, date formats and multi-select handling, so the inventory records what each export actually contains. Ask how unused or duplicated columns will be retired.

Target data model alignment

The target is checked against the entities, fields and layouts already configured in your EspoCRM instance, not an assumed default. Gaps are either added in the Entity Manager or dropped with a recorded decision. Where a value needs conversion before save, such as a picklist label mapped to the stored option value, the rule is written as Formula Script and tested on sample rows.

Duplicate rules and import order

Duplicate matching uses fields the business trusts, such as email address or an external ID carried over from the source, and each load uses a defined mode: Create Only, Create and Update, or Update Only. Records load in dependency order, with accounts first, then contacts, then opportunities, so lookups resolve to existing records. Confirm that source IDs are stored for later reconciliation.

Test imports and reconciliation reports

Test imports run against a staging instance built from the same configuration as production. Each run produces a reconciliation report comparing source counts, matched duplicates, rejected rows and a field-by-field sample of records. Test records are then reverted with the import revert function, and the reversal is checked so the next pass starts from a clean state.

Cutover import and job scheduling

The production load runs in a planned window against a frozen source. Large files are processed through idle import, which depends on cron or the scheduled task running correctly, so confirm the job runner works before the window opens. The sequence, rollback point and sign-off owner should be agreed in writing before the load begins.

Handover deliverables for administrators

The deliverables are a mapping specification, an import runbook, reconciliation evidence, a cutover checklist and handover notes for your administrators. Ask that each document name the source file versions and the EspoCRM version used. The handover notes should state which fields are now authoritative, how a load is rerun and who owns the duplicate rules after go-live.

What drives cost and duration

The table lists the factors that most change how long an EspoCRM migration takes and what it costs, with the effect of each and practical ways to keep it manageable.

Driver	Why it matters	How to keep it down
Record volume and file size	Large files are run through idle import via cron, so each batch waits for scheduling and needs verification afterward, which stretches the calendar more than the effort.	Archive closed records older than the agreed retention period, and split very large files into logical batches ahead of time.
Number of source objects and relationships	Accounts, contacts, leads, opportunities, products and notes depend on each other, so every link needs a mapped target and a defined import order.	Limit the scope to objects the business uses daily, and document each parent-child link before any mapping starts.
Quality of source data	Duplicate accounts, inconsistent picklist values and free-text dates force cleansing and matching rules before import, and they multiply the number of review passes.	Run deduplication and picklist normalization in the source system or a staging copy, and agree on one date format before export.
History, attachments and activity	Email threads, call logs and documents add file transfer, storage sizing and extra mapping, and they often expose permission questions the old system answered implicitly.	Decide which history must be migrated, keep the rest in a read-only archive, and confirm the storage location for attachments early.
Custom entities and fields in the target	Each source field that has no EspoCRM equivalent needs a custom field or entity, along with layouts, validation and permissions, which adds design and build work.	Map to standard entities where possible and agree a short list of custom fields before the build begins.
Number of users validating mappings	Sales, service and finance staff each review their own records, and conflicting answers from different teams delay sign-off on mappings.	Name one accountable owner per object and set a fixed review window with a single consolidated list of open questions.
Number of test cycles	Each test import is reverted and rerun after fixes, so every extra cycle repeats the scheduling, verification and review time.	Test on a representative sample first, use the revert feature for clean reruns, and define exit criteria for each cycle.
Parallel run and sync between systems	If the old system stays live while EspoCRM is in use, changes made in both must be reconciled, which requires sync logic, a cut-over date and extra checks.	Shorten the parallel period, freeze the source for final loads where the business allows, and confirm the sync method with your team in writing.

How the migration runs

The sequence moves from agreed scope to repeatable test imports to a reconciled production dataset, with each phase closing on a written output.

Inventory the source and confirm the target model
DeployOpen and your admins list every object, field, attachment and history record in Salesforce, SugarCRM or the spreadsheets, with record counts, owners and known data quality problems. Each source object is matched to an EspoCRM entity, such as Account, Contact, Lead or Opportunity, or to a custom entity built in the Entity Manager. Sales and service leads confirm the model. The step closes with a source inventory and a signed target model.
Write the mapping specification and duplicate rules
The mapping specification sets out each source column, its EspoCRM field, value conversions such as picklist translation and date formats, and the import order for related records, so accounts load before the contacts, leads and opportunities that reference them. Duplicate matching fields and the import mode for each object, such as Create Only or Create and Update, are chosen here. The step closes when the specification is reviewed and approved.
Build the staging environment
DeployOpen builds an EspoCRM staging instance in your infrastructure on a supported stack. Confirm the current PHP, database and web server versions in the EspoCRM server configuration docs before the build. Cron must run, because background jobs and idle execution of large import files depend on it. The step closes when a scheduled job run is confirmed in the logs.
Run iterative test imports with reverts
Each test run imports one object or group of objects into staging, then the team reviews the error log, skipped rows and duplicate matches. Imported records are reverted before the next run, so every test starts from a clean state and each mapping fix is measured against a known baseline. The step closes when a full run completes with no unresolved mapping errors on the agreed sample.
Validate with named business users
Named users from sales, service and finance check a sample of imported accounts, opportunities and history against the source system, including owners, stages, amounts and dates. Each user records accepted and rejected items, and rejected items return to the mapping specification for another test run. The step closes with written sign-off from each named user for the objects they own.
Run the cutover import and reconcile
Your team freezes edits in the source system. DeployOpen then runs a final extract and the approved import sequence into production. Reconciliation compares record counts, owner assignments and opportunity totals against the final extract, and each discrepancy is fixed or documented before users receive access. The step closes with a signed reconciliation report.
Support users through hypercare
After go-live, DeployOpen monitors cron jobs, import logs and error reports, and works with your admins on user questions about migrated records, duplicates and missing history. Issues are logged and handled within the agreed scope. The step closes when the hypercare exit criteria in the written schedule are met and your team accepts the handover documentation.

What teams keep in-house and what they outsource

This table splits a CRM migration into its working parts, lists the skills each part needs, and shows whether teams usually keep it in-house or hand it to a partner.

Work part	Skills needed	Usually in-house or outsourced	Business owner decision
Source export and access to the old system	Source CRM administration, API or export tooling, security approval for read access	Usually in-house, because only the current admins can grant access and confirm what the export contains	Which objects, date ranges and archived records must move at all
Business rules for duplicates and active opportunities	Sales operations knowledge, data analysis to test the rules against real records	Must be decided in-house, with a partner testing the rules against sample data	What counts as a duplicate account, contact or lead, and which opportunity stages are still active
Mapping design	EspoCRM entity and field knowledge, source CRM data model knowledge	Often shared: the team lists fields and owners, a partner drafts the field mapping	Which source fields map to which EspoCRM fields, and which legacy fields are retired
Transformation scripting	Data analysis, scripting, EspoCRM formula and entity knowledge	Often outsourced when the volume of cleanup is large, otherwise kept in-house by a technical admin	Rules for cleaning values, such as picklist translations and currency conversion
Import execution	EspoCRM import tool use, Linux and database operations on staging and production hosts	Usually outsourced for the first runs, with the team confirming results in a test instance	When the production import runs and who approves it
Reconciliation	Data analysis, record count and sample checks, EspoCRM reporting	Shared: a partner produces counts and exceptions, business users confirm the totals	Which differences are acceptable and which block cutover
User acceptance	Sales and service workflow knowledge, EspoCRM layouts and permissions	Kept in-house, since only the business team can judge whether records are usable	Sign-off criteria and the people who give acceptance
Cutover and reversion	Linux and database operations, backup handling, use of the import revert function	Often shared, with the team's infrastructure staff or partner running the steps	Cutover date, freeze window for the old system, and the rollback decision

What usually goes wrong

Most EspoCRM migration problems trace back to decisions made late or skipped entirely, such as matching rules, load order and export handling. Each risk below has a check to put in place before the first production run.

Duplicates from late match fields

If match fields are chosen after the first test import, accounts and contacts get created twice because the duplicate check no longer compares the same keys across runs. Agree the matching fields, such as email domain or the source system's external ID, before any import. Run a test in Create Only mode and review a sample of matches before enabling updates.

Child records imported before parents

Contacts, opportunities and activities need their parent accounts or leads to exist first, or the link fields stay empty. Import in dependency order: accounts, contacts, opportunities, then activities. Keep the source IDs in a mapping column so links can be rebuilt, and check a sample of each child type for a populated parent field after every stage.

Misread dates and currency

Spreadsheets often mix day-first and month-first dates, and exports may drop currency codes or store amounts as text with thousands separators. A value such as 03/04/2025 can import as the wrong day or month without raising an error. Set date and number formats explicitly in the mapping, confirm the currency for each record, and compare totals against the source report.

Activity, ownership and attachments lost

Flattening history into a single notes field removes the timeline that sales teams rely on. Owner and team columns map to nothing if the users and teams do not exist yet, and attachments often stay in the old system because they sit in a separate store. Create users and teams before import, map each activity to its parent record, and track attachments as a separate item with a named owner.

Cutover without a tested revert path

A production run that cannot be reversed turns a bad mapping into a cleanup project. EspoCRM can revert imported records, but only if the revert has been practiced on a copy of the data first. Large files also depend on idle import through cron, so confirm cron is running on the target server before the cutover window, or imports stall in the queue.

Exports left on shared drives

Exported CSV files contain customer names, contact details and deal values, and copies on shared drives or in email attachments extend access well beyond the migration team. Restrict the export folder to named people, encrypt it where your data policy requires, and record who holds copies. Delete temporary exports and intermediate files after cutover, and keep written confirmation of the deletion.

How the work changes by starting point

Salesforce migrations start with an export whose shape depends on which objects you pull, how your org is configured and which attachments and history you keep. Confirm the export method and file format with your Salesforce administrator before mapping starts.

Object scope: Confirm which standard and custom objects hold accounts, contacts, leads, opportunities and history, and whether activities and notes are in scope.
Relationships: Map lookup and master-detail fields to EspoCRM relationships, and set import order so accounts load before contacts and opportunities.
Custom fields: Create matching fields in the Entity Manager first, because CSV import maps only to fields that already exist.
Testing: Run a test import into a staging instance, check duplicate matching on fields such as email and account name, and use the revert function before the full run.

What your team needs to provide

The migration moves only as fast as the decisions and access your team provides, so the first thing to settle is who speaks for the source data. Name a contact who understands the source data model, whether that is Salesforce objects, SugarCRM modules or the structure of your spreadsheets, and who can answer questions about custom fields, record ownership and historical stages. Provide export access or extracts from the source system, along with sample files for review before the full run. Ask the source owner to confirm which objects, fields and attachments are in scope, because undocumented custom fields are a common source of rework.

Business owners decide the rules that the import cannot infer. For each entity (accounts, contacts, leads, opportunities and any custom entities), a named owner should approve duplicate matching fields, the status and stage mapping from the old system to EspoCRM values, and how records without an owner are assigned. Your team also needs a staging host that meets the EspoCRM server requirements published in the server configuration docs, with cron scheduling rights, because large imports run as idle jobs and cron must be available to process them. Confirm these before the first test import, not during it.

A test user group should validate imported records against the source before cutover, checking counts, relationships, owners and a sample of history. Agree a freeze window on the source system so that no new records arrive during the final run, and decide in writing how long reverting test imports is needed for the staging environment. Retention of history and attachments is a separate decision: state whether activity history, notes and files move in full, move in part or stay in an archive, since this drives file storage sizing and import order.

Security preparation should be settled before any export leaves the source system. Confirm who may see personal data during the project, including DeployOpen engineers, your staff and any contractors, and record that access in writing. Decide where exports are stored, which encrypted locations are approved, and how working copies are deleted once the migration is accepted, including staging copies and any local spreadsheets. Ask for the deletion steps to be documented so you can show them to your data protection or compliance lead.

Questions buyers ask before hiring help

How much does an EspoCRM migration cost and what drives the price?

DeployOpen does not publish prices. A quote follows from the written scope, and the main cost drivers are visible in that scope. Cost components: discovery and field mapping, export and cleaning of the source files, import design for related records, each test cycle, cutover support, and any extensions or integrations that touch the migrated data. Recurring costs sit outside the migration itself, such as hosting and, if you choose EspoCRM Cloud instead of self-hosting, the per-user subscription listed on the EspoCRM pricing page. Ask the quote to price each component separately and state how many test cycles it assumes.

How long does moving CRM data into EspoCRM take?

The schedule depends on three things: data volume, the quality of the source records, and the number of test cycles you run before go-live. Clean source data with few duplicates moves faster than records that need merging, and every test cycle adds time for review and fixes. The timeline is agreed in writing as part of the fixed-scope plan, with milestones for mapping sign-off, test imports and cutover. Ask that the schedule name its assumptions, including who signs off each test cycle and how long your team has to review results.

Can our own team migrate to EspoCRM alone, and what does the work need from us?

Yes, for simple data with a careful administrator. A file of contacts or leads with clear columns is usually manageable in-house, if the administrator reads the import documentation, tests on a copy of the instance and checks duplicate matching before the first real run. It gets harder when several related objects must link correctly, such as accounts, contacts and opportunities, because import order and record references must be right. Whichever route you choose, the work needs a business owner who approves the field mapping, admin access to the source export, sample files, documented sales or service stages, and people with time to review test results.

Do we have to shut down our old CRM at cutover?

Not always. The parallel run decision sets whether the old CRM is switched off at cutover or kept read-only for a period. A parallel run lets users check results against the source and gives you a fallback if a problem appears late, but records edited in both systems need a clear rule for which one wins. The decision depends on how many active users rely on the old system, whether reports or integrations still read from it, and what access your contract allows after cutover. Decide this during planning, so the cutover date and the rollback path are set before test imports begin.

Can history and attachments move from Salesforce or SugarCRM?

It depends on what the source system can export. Activity records, notes and files linked to accounts, contacts or opportunities each need an export path, and options differ by product, edition and configuration. Confirm this with the source system or its administrator before scoping. Where files come out separately from their parent records, the mapping must relink them to the correct EspoCRM records. Ask for a short export test on a sample of records before agreeing on the scope of history and attachments.

What happens if a test import loads the wrong records?

EspoCRM's import feature supports reverting imported records, and that covers the import itself. Before each test run, take a database backup and keep the exact source files, so you can compare results and rerun with corrected mapping. Confirm with your team how reverting handles records that users edited after an import, since that depends on your workflows and integrations. DeployOpen does not issue audit reports or certifications. It can keep import logs, mapping documents and test results as evidence for independent auditors to review.

How DeployOpen delivers this service

DeployOpen plans and runs EspoCRM migrations inside infrastructure you control, moving accounts, contacts, leads, opportunities and history from Salesforce, SugarCRM or spreadsheets with a written scope agreed before work starts. Each migration is tested on copies of your data and documented so your team can repeat or audit the import later.

How we scope

The written scope lists each source system or spreadsheet, the entities being moved and the fields that map to EspoCRM.
It defines how duplicates are matched, which records are created, updated or skipped, and how related records are imported in order.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any data is moved.

How we build

We map source fields to EspoCRM entities and agree transformation rules with your sales and service owners before the first test import.
We run test imports into a non-production instance, using CSV import modes and idle execution through cron for large files, and review results with you.
We use EspoCRM's revert function on test batches so each trial can be undone and repeated cleanly before the production load.

How we hand over

You receive the field mapping, duplicate rules, import order and a reconciliation report showing record counts by entity and source.
We document the production import runbook, including the steps to revert a batch and the checks to run after each load.
Your administrators are trained to read import logs and to correct or reload records without relying on our team.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
Retainer scope should cover EspoCRM upgrades, which in version 10 are run from the command line because UI upgrades are off by default.
Ask any provider to confirm how they handle post-migration data fixes, backups taken before each load, and the owner of the import logs.