Migrate from Zoho CRM to EspoCRM

Migrate from Zoho CRM to EspoCRM: what the move involves

Most Zoho CRM exits that are driven by a renewal, a per-user increase or a data residency requirement are less a software project than a data mapping and workflow rebuilding exercise. The work is to decide how each Zoho module, field, layout and automation rule becomes an EspoCRM entity, field, layout and workflow or Business Process Management (BPM) item, and then to prove the result with your own sales users. Internal CRM administrators usually lead this, with an implementation partner handling the server build, the import scripts and the cutover checks. Effort and risk depend mainly on how many custom modules, blueprints and integrations Zoho is carrying, not on the size of the sales team alone. Ask for a written inventory of these items before anyone commits to a timeline.

Plan for the gap in Zoho's export before you plan the import. A Zoho CRM data backup produces CSV files in a ZIP archive with record attachments, but it excludes email content, documents and data from integrations. Those items need a separate extraction path, such as the Zoho CRM APIs or the mail and document systems that hold them, and each one needs an owner and a decision on whether it is migrated, archived or dropped. Also confirm the 7-day window for downloading a backup link, because a missed download means requesting a new backup. Your sales operations lead should decide which history is worth carrying into EspoCRM and which can stay in a read-only archive.

Two areas need a decision before build work starts. First, confirm which Zoho automation your team actually relies on, then decide whether each rule maps to an EspoCRM workflow, a BPM flow, a before-save Formula Script or a manual step. Second, decide how users sign in. EspoCRM supports OpenID Connect and LDAP, including Active Directory, but its own two-factor authentication is not compatible with OIDC, so the identity provider must carry that control. Reports and BPM come through the Advanced Pack, which is included in EspoCRM Cloud plans, so confirm whether you will self-host the Advanced Pack or use the hosted option. Ask your implementation partner for a quote that lists each of these items separately.

Which Zoho CRM capabilities map cleanly to EspoCRM

This table compares the main Zoho CRM capabilities with the EspoCRM mechanism that covers each one, marked as clean, needs rework or gap. Read it as a planning checklist: a clean mapping still needs a test import, and a gap or rework row should go into the written scope before any data moves. Most small and mid-size teams find the core sales entities straightforward, while Zoho-specific blueprints and integrations need the most design time.

Zoho CRM capability	Status	EspoCRM mechanism and what to confirm
Core entities (leads, contacts, accounts, deals, activities)	Clean	Standard entities exist in EspoCRM. Map field types and pipeline stages in a test instance and confirm how Zoho lead conversion history is represented.
Custom modules and custom fields	Needs rework	Entity Manager creates custom entities and fields. Zoho module relationships and lookups need a field-by-field mapping before import.
Page layouts	Needs rework	Layouts are configured per entity in the administration area. Rebuild them by hand from Zoho views, since layouts are not carried over automatically.
Roles, profiles and permissions	Needs rework	EspoCRM uses roles, teams and record-level access. Zoho profile and sharing rules must be translated, and the design should be reviewed with the sales managers.
Reports	Needs rework	Reports are part of the Advanced Pack, which is included in all EspoCRM Cloud plans. Self-hosted installs need the extension licensed and installed, so confirm this before rebuilding dashboards.
Workflow rules	Needs rework	Advanced Pack workflows and BPM replace Zoho workflow rules. Rules must be rewritten, not exported, and tested with sample records.
Blueprints and stage-based processes	Gap	No direct one-to-one equivalent is supplied for Zoho blueprints. Plan to rebuild stage logic with BPM and Formula Script, and confirm the coverage with the vendor.
Calculated logic and validation	Needs rework	Formula Script runs in before-save scripts, API before-save scripts, workflows and BPM. Translate Zoho formula fields and validation into these scripts.
API access and integrations	Needs rework	EspoCRM's REST API supports API key, HMAC and basic authentication through dedicated API users. Zoho API calls and third-party connectors must be rewired to the new endpoints.

What Zoho exports, what it leaves out and what to rebuild

Moving off Zoho CRM means choosing how to extract data, then accounting for what the extraction does not carry. The backup and the API each cover different ground, and several items never leave Zoho in either path. The cards below set out what to pull, what to rebuild by hand and what to confirm before cutover.

Scheduled data backup

The data backup produces CSV files for each module inside a ZIP archive, with record attachments included. You can run it immediately or schedule it weekly, twice a month or monthly, so plan a final backup close to the cutover date. Zoho keeps the download link active for 7 days, so download, checksum and store the archive on your own storage the same day it is generated. Check that every custom module and field appears in the CSV headers before you start the import mapping.

API extraction for scripted pulls

Use the Zoho CRM API when you need repeatable or incremental pulls, such as syncing records during a parallel run. Scripted extraction needs an OAuth client, a scope set limited to read access and a schedule that stays within your edition's API credit allowance. Confirm the current Bulk Read limits and call quotas with Zoho for your edition, because they determine how long a full extraction takes. Log every request so you can prove completeness to the business owners.

Email and documents stay behind

Zoho's backups exclude email content, documents and data from integrations. Mailbox history tied to contacts and deals must come from the mail server, through IMAP export or the sync tool you choose for EspoCRM. Documents stored in Zoho's file features need a separate download pass and a mapping back to the parent records. Decide before cutover which historical email you keep, and tell sales teams where it will be found.

Integrations to rebuild

Connected apps such as mail, calendar, telephony, marketing and billing connectors do not transfer with the data export. List every active connection in Zoho, note its direction and the fields it writes, and then choose an EspoCRM extension or a custom integration for each. EspoCRM's official extensions include the Google, Outlook, VoIP, MailChimp, Zoom and Stripe integrations, so check each one for fit before you assume a match. Retire any connection that no longer has an owner.

Users, teams and sign-in

Zoho user accounts, profiles, roles and team membership do not come across as CRM records, so recreate them in EspoCRM with teams and role-based permissions that match your access model. For sign-in, EspoCRM supports OpenID Connect since version 7.3, with optional user creation on first login and mapping of identity provider groups to teams. It also supports LDAP, including Active Directory and OpenLDAP. Note that EspoCRM's own two-factor authentication is not compatible with OIDC, so plan your MFA at the identity provider.

Workflows, blueprints and rules

Zoho workflow rules, blueprints and scheduled actions must be rewritten, not exported. In EspoCRM, reports and workflows with Business Process Management come from the Advanced Pack, and before-save logic uses Formula Script in the Entity Manager or workflows. Document each Zoho rule with its trigger, conditions and actions, then test it against sample records in a staging instance. Background jobs need cron or a scheduled task to run, so confirm that on your server before go-live.

The migration sequence from inventory to decommission

This sequence moves Zoho CRM data, configuration and daily sales work into a self-hosted EspoCRM instance in controlled stages. Each step ends with a written check, so the team knows when it can move on and when Zoho can be retired with its archives kept.

Inventory modules, fields, automations and integrations
The Zoho administrator and a sales operations lead list every module in use, each custom field with its type and required status, page layouts, workflow rules, blueprints, scheduled actions, approval processes, and every connected app or API client. Mark which items are actively used, because unused fields and rules are often the cheapest to drop. Record record counts per module and note what the Zoho backup excludes, such as email content, documents and integration data, so those gaps are planned for separately. Done when the inventory is signed off by the business owner and each item is marked to migrate, rebuild or retire.
Build a staging EspoCRM and run a pilot import
Install EspoCRM on a staging server inside your own infrastructure, following the installation documentation and the server requirements for PHP, the database and cron. Create the custom entities and fields from the inventory using the Entity Manager, then import a small sample of Zoho CSV exports using the import documentation to test column mapping, duplicate handling and relationships between accounts, contacts and deals. Log every error and the row it came from. Done when a sample of each module imports with correct relationships and the error log is understood and documented.
Map fields and cleanse the data
Build a mapping sheet that pairs each Zoho module and field with its EspoCRM entity and field, including picklist values, date formats, currency and owner assignment to EspoCRM users. Deduplicate accounts and contacts, standardize phone numbers and country values, and archive stale records according to the retention rule the business has agreed. Rebuild the rules that matter as EspoCRM workflows or Business Process Management (in the Advanced Pack) and Formula Script, and confirm each rule against its original Zoho behavior. Done when the mapping sheet is approved, a second pilot import runs with no unexplained errors, and the rebuilt rules pass test records.
Run a parallel period with both systems
Keep Zoho CRM as the system of record while a controlled group of sales users works in EspoCRM on the migrated data. Compare pipeline totals, record counts and owner assignments between the two systems on a regular schedule, and log every discrepancy with its cause. Test the integrations you need, such as email, calendar or single sign-on through OIDC or LDAP, and confirm each one works before cutover. Done when the reconciliation shows no open discrepancies in core records and the pilot users confirm their daily tasks work in EspoCRM.
Cut over with a final delta export
Announce a write freeze in Zoho CRM, then run a final full backup or API extraction and download it while its link is active, since Zoho's backup download link stays active for 7 days. Import only the records changed since the last full load, using the same mapping and the import documentation, and reconcile counts against the frozen Zoho data. Switch users to EspoCRM, disable the Zoho integrations and point any downstream systems at the new API user with its permissions. Done when the reconciliation matches, users have logged in to EspoCRM and no integration still writes to Zoho.
Decommission Zoho and keep retained archives
Once the parallel run and cutover checks are accepted, store the original Zoho backup files, attachments, mapping sheet, import logs and reconciliation reports in a read-only, access-controlled location within your own infrastructure. Confirm with Zoho what happens to your data under your subscription terms and how long it stays accessible after you cancel, and ask for written confirmation. Remove Zoho user accounts and revoke API clients, then cancel the subscription on the date your contract allows. Done when the archive is verified as readable, the retention period is documented for auditors, and Zoho access is removed.

How the EspoCRM side is built and hosted

The self-hosted EspoCRM stack runs on PHP 8.3 to 8.5 with a database of MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, served by Apache, Nginx or IIS. Background jobs such as scheduled workflows and email processing depend on cron (or a scheduled task on IIS), so that scheduler must be configured and monitored from day one, not left for later. Your platform team should decide which database engine and web server match existing operational standards, then confirm the exact PHP and database versions against the current server configuration documentation before building the host. The licensing question is simpler: EspoCRM is published under AGPL-3.0, and the open-source edition can be downloaded and self-hosted at no license cost. Legal review should still cover what AGPL-3.0 requires if you modify the code and make it available to users over a network.

For Ubuntu, Debian and Linux Mint, the installation script deploys a Docker-based stack with Nginx and MariaDB, and can configure optional Let's Encrypt certificates. That speeds up a proof-of-concept host, but a production deployment should be reviewed against your own network design, backup targets and secrets handling before anyone imports client data. The command.sh utility handles backups, restores and upgrades for that stack. Test a restore into a separate instance before go-live, because a backup you have never restored is not a recovery plan. Confirm with your administrators whether the script's Docker layout fits your change control, and whether an existing database server or web tier should be used instead.

EspoCRM Cloud is a separate, paid, hosted option run by the EspoCRM project, priced per user with minimum seat counts on each plan. Choosing it moves hosting, patching and backups to the vendor, so it changes who is responsible for data location and availability. Self-hosting keeps those responsibilities inside your organization, along with the cost of servers, backup storage and administrator time. Ask the EspoCRM project to confirm current plan terms and where cloud data is stored before comparing the two options, and make the hosting decision before the data migration starts, because the import target depends on it.

How the migration changes by team size and starting point

A small team on Zoho CRM Standard or Professional that uses the standard Leads, Contacts, Accounts and Deals modules with a handful of custom fields usually has the smallest migration. The main work is a clean data export, a field map and a short list of automations to recreate. Little of the Zoho configuration needs to be reproduced exactly, so the project is mostly about deciding what to keep.

Export scope: Run a full data backup from Zoho and confirm the CSV files cover every module you still use before the download window closes.
Field mapping: Map standard fields one to one and drop unused custom fields instead of recreating them.
Automations: Rebuild only the rules that drive daily work, such as lead assignment or stage reminders, using EspoCRM workflows.
Users and access: Create EspoCRM users and teams from your current Zoho user list and set roles before import.
Test import: Load a sample into a staging EspoCRM instance and check counts, dates and owners.

Confirm with your own admin how many custom fields and active rules you actually use, because that count largely sets the effort.

What drives migration cost and duration

This table lists the factors that move the effort of a Zoho CRM to EspoCRM migration, why each one matters and how to reduce it. Read it before requesting a quote, because the same data volume can cost very different amounts of work depending on customization and identity setup.

Driver	Why it changes effort	How to keep it down
Record volume	Each module's records must be extracted, cleaned and imported, and large imports need batching and reconciliation checks against record counts.	Archive closed or stale records before export and agree which history must move. Confirm import limits in the EspoCRM import docs.
Attachment size and count	Zoho backups include record attachments in the ZIP archive, and these must be re-linked to the new records in EspoCRM.	Separate attachments from the core data set, set a retention cutoff, and check storage sizing on the new server before the cutover.
Custom modules and fields	Each custom entity, field type and layout needs an equivalent in EspoCRM's Entity Manager, and unmatched field types force design decisions.	Inventory every custom module and field in Zoho first, retire unused ones, and map the rest to EspoCRM field types on a shared spreadsheet.
Workflow rules and blueprints	Zoho workflow rules and blueprints must be rebuilt as EspoCRM workflows or BPM and Formula Script, which is manual design and testing work.	Count active rules and blueprints, rank them by business value, and rebuild only those still in use. Confirm which need the Advanced Pack.
Integrations to rebuild	Zoho backups exclude integration data, so every connected system such as email, telephony, marketing or accounting needs a new connector or a manual feed.	List each integration with its owner and data flow, then decide per integration whether to rebuild, replace or retire it.
Identity setup	OIDC sign-in, optional LDAP and group-to-team mapping require identity provider configuration, and EspoCRM's own 2FA is not compatible with OIDC.	Agree the identity model before build. Confirm with your identity team which login methods and MFA policy apply to CRM users.
Data quality	Duplicates, missing owners, inconsistent picklist values and stale contacts create mapping exceptions that someone must resolve by hand.	Run deduplication and owner reassignment in Zoho before export, and define a cleanup rule for records that fail import validation.
Internal admin availability	Business owners must validate mappings, test workflows and sign off each stage, and their time is often the longest dependency.	Name a single internal decision owner, book test windows in advance, and ask any implementation partner to state in writing which tasks need your staff.

What usually goes wrong and how to prevent it

Most failed Zoho CRM to EspoCRM moves break at the edges: the export window, data the backup never contained, and the authentication and cutover steps around the import. Each card below names one failure, why it matters for this move, and the check that prevents it.

Expired backup download links

Zoho's backup download link stays active for 7 days. If the archive is requested late in a cutover plan, the link expires and the backup has to be requested again. Put the download on a calendar the day the backup finishes, save the ZIP to controlled storage, and checksum it before anyone starts the import. Confirm with Zoho that the scheduled backup you rely on is still generated the way you expect before the freeze date.

Emails and documents left behind

Zoho's CRM backup excludes email content, documents and integration data, so mail threads and files attached through connected mail or document tools will not arrive in EspoCRM. Inventory where these live before the cutover, including Zoho's mail sync and any external storage. Decide whether to archive them separately or accept that they stay in the source system, and record that decision in the migration plan so sales staff do not assume the history moved.

Field types that fail to map

Zoho multi-select, lookup, currency and formula fields do not always map one to one to EspoCRM field types. A value that loads as text can break reports, and a lookup that becomes a plain string loses its link to the related record. Build a field-by-field mapping sheet from the Entity Manager configuration, load a small sample of each entity, and check that filters and totals return the same results in both systems before the full import.

Duplicate records on re-import

Running the import twice, or importing contacts that already exist from a partial test load, creates duplicate accounts and contacts. Duplicates then split activity history and skew pipeline totals. Use the Zoho record ID kept in a custom field as the matching key, run a test import into a staging instance first, and delete the test records before the production load. Set a rule that one designated run is the only production import.

Workflows rebuilt with wrong logic

Zoho workflow rules and blueprints express transitions and conditions differently from EspoCRM workflows and BPM. A rule that fired on a field change may be rebuilt as one that fires on every save, sending duplicate emails or overwriting stage values. Document each Zoho rule with its trigger, condition and action, rebuild it in a staging instance using the Advanced Pack, and test it with a few sample records. Confirm that scheduled and conditional logic behaves as the original did.

API credentials on basic authentication

Integrations that connect to EspoCRM can be set up with basic authentication, which the EspoCRM documentation does not recommend. HMAC is the stronger method for API users. Create a dedicated API user for each integration with the narrowest role permissions, use HMAC where the connecting system supports it, and store secrets in your vault rather than in configuration files. Review these users during the cutover and remove any Zoho-era integration accounts that are no longer needed.

Users locked out at cutover

If sign-in is not ready when the old Zoho instance is switched off, sales staff lose access to pipelines and contacts on the day they most need them. Test OIDC or LDAP sign-in with a pilot group, set a fallback login method for administrators, and confirm that the cron job for background tasks is running on the production server. Keep Zoho read access for a defined period so that users can check records while the new system is validated.

Questions buyers ask before moving from Zoho CRM to EspoCRM

How much does it cost to run EspoCRM in-house compared with using a partner?

In-house cost is mostly internal staff time plus hosting, while a partner cost is the written scope you agree before work starts. EspoCRM itself is free to download and self-host under AGPL-3.0, so the recurring costs are servers or cloud accounts, backups, email delivery, extensions you choose to buy, and admin time for upgrades and user changes. One-time costs cover migration, mapping, rebuilding Zoho workflows and training. Ask any quote to split these components, state who pays for each, and say which costs recur. Compare the total against your current Zoho edition fees over the same period, using your own user count.

How long does a Zoho CRM to EspoCRM migration take?

Duration depends on data volume, how many custom modules and fields you have, how many Zoho workflow rules and blueprints need rebuilding, and how many integrations sit outside Zoho's backup. Zoho's backup link stays active for 7 days, so the export step has a fixed window that your team must plan around. Other drivers include how clean the source data is, how many users must sign off on layouts, and whether you run a parallel period. Ask for a timeline tied to a written scope with named deliverables, and confirm the export window and cutover plan before work begins.

What does the migration need from our own team?

Your team needs to name a business owner who can decide field meanings and layouts, provide a sales operations contact who knows the current pipeline stages and reports, and give an administrator access to Zoho with permission to request backups or use the API. Engineers need access to the target server or cloud account, DNS and mail settings, and a path for identity sign-in if you plan to use OIDC or LDAP. Plan time for user acceptance testing. Ask the partner which of these roles they expect you to fill and when.

Can one admin migrate Zoho CRM to EspoCRM alone?

A single experienced administrator can handle a small, simple Zoho org, but the work is usually broader than one person's day-to-day role. The export needs a Zoho user with backup rights, the mapping needs sales and finance input, and the Zoho workflow rules and blueprints must be translated into EspoCRM workflows, BPM or Formula Script, which requires hands-on configuration and testing. Backups also exclude email content, documents and integration data, so those need separate handling. Ask yourself whether the admin can cover testing, rollback and post-cutover support alongside normal duties.

What changes if we choose EspoCRM Cloud instead of self-hosting?

EspoCRM Cloud moves hosting, patching and backups to the vendor, and it is priced per user per month, with the Advanced Pack included in all cloud plans. The published cloud prices are 15 US dollars per user per month on Basic (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), according to the EspoCRM pricing page. Self-hosting removes per-user fees but shifts server operations, upgrades, backups and security hardening to your team or your partner. The choice mainly affects where customer data lives and who runs operations. Confirm the current cloud terms with the vendor before comparing.

What should we ask for in a migration quote?

Ask for a written scope listing each Zoho module and custom field being mapped, which Zoho workflows and blueprints will be rebuilt, and which integrations and attachments are in or out. Request the server design, the backup and restore approach, the test plan, and the rollback procedure. Ask who performs each step, what the client must provide, what is one-time versus recurring, and what support or upgrade retainer is available after go-live. Confirm how data is handled during transfer and where it is stored. DeployOpen does not publish a price list, so a quote follows from the written scope.

What does the migration not cover that we still need to plan for?

Zoho's standard data backup excludes email content, documents and data from integrations, so those must be extracted another way through the API or from the source systems. Zoho's Bulk Read API may be needed for larger scripted exports, and EspoCRM's import tools and REST API will need correct field types and relationships. Plan separately for email history, file storage, phone and calendar sync, and any Zoho apps such as Books or Desk that feed CRM records. Ask the partner to confirm in writing which of these sit inside the migration scope and which need a separate project.

What to confirm with Zoho and your own environment before you start

Start by confirming your current Zoho CRM edition and which automation features are live, because that list sets the migration scope. Pull the inventory of workflow rules, blueprints, scheduled actions and custom functions from the Zoho admin console, not from memory, and record which ones drive daily work such as lead assignment, stage approvals or renewal reminders. Also confirm which export option your plan gives you. Zoho's scheduled data backup is the path described in the Zoho help article on requesting data backup, and the number of backups and the download window depend on your edition, so check both with your Zoho administrator before planning the extraction date. Next, measure attachment volume and decide what the backup will not carry. Zoho's backup excludes email content, documents and data from integrations, so list every mailbox, document library and connected app that holds customer records and assign each one its own extraction or rebuild task. Count attachments per module, since the backup archive is a ZIP of CSV files plus record attachments and a large attachment set can stretch download and restore time. Ask your team which mailboxes are synced to Zoho and whether the business needs historical threads in EspoCRM or only a link to the mail system.

On the target side, confirm the EspoCRM release you will deploy by checking the current version on the EspoCRM releases page rather than relying on any version named in this guide, then match it against the supported PHP, database and web server versions in the server configuration docs. Decide where the instance will run, which cloud account, data center or on-premises rack, and confirm that the hosting location meets your residency and sovereignty obligations for customer data. Record who will hold backup copies and where they are stored, since EspoCRM's command.sh backup and restore tooling only protects data you keep under your own control. Finally, settle the identity provider design before users are created. Decide whether sign-in goes through your existing OpenID Connect or LDAP directory, whether users should be created on first login, and how identity provider groups will map to EspoCRM teams. Note that EspoCRM's own two-factor authentication is not compatible with OIDC, so your identity provider must enforce MFA. Confirm which accounts will become API users, because the REST API allows API key, HMAC and basic authentication, and the docs describe HMAC as the most secure choice and basic authentication as not recommended. Agree these decisions in writing before the pilot starts.

How DeployOpen plans, runs and supports the move

DeployOpen approaches the move from Zoho CRM to EspoCRM as a fixed-scope implementation inside your own infrastructure. We agree the scope in writing first, then build, document and hand over the EspoCRM instance and the migrated data, with ongoing support available as a retainer.

How we scope

Inventory which Zoho modules, custom fields, layouts and workflow rules your sales team actually uses today.
Agree in writing which backup or API extraction method feeds the migration and which records are in or out of scope.
Confirm the hosting target, PHP and MySQL, MariaDB or PostgreSQL versions, and who holds administrator access before work starts.

How we build

Map Zoho modules and custom fields to EspoCRM entities, layouts and Formula Script logic, and document each mapping decision.
Rebuild Zoho workflow rules and blueprints in EspoCRM workflows or BPM, deciding per rule whether the Advanced Pack is needed.
Import test extracts, reconcile record counts and test sign-in, permissions and API access on a staging instance before cutover.

How we hand over

Deliver the configured EspoCRM instance, the mapping documentation and the reconciliation reports for your sign-off.
Provide runbooks for backups, restores and upgrades, and train administrators on entity, role and API user management.
Record what Zoho backups do not carry over, such as email content, documents and integration data, and how each gap was handled.

How we support

Offer ongoing support, upgrades and testing as a retainer after the fixed-scope migration is complete.
Review EspoCRM releases and extension changes with your team before they reach production.
Confirm support terms, response expectations and retainer scope in the written quote, since these vary by engagement.

Migrate from Zoho CRM to EspoCRM