Migrate from HubSpot to EspoCRM

Migrate from HubSpot to EspoCRM: what the move involves

Most teams leave HubSpot because seat costs keep rising, because they want contact data on servers they control, or because a data residency or lock-in review has made the current setup hard to justify. The migration is mainly a data export, a field mapping exercise and a pipeline rebuild. The effort depends less on the number of users than on the size of the portal, how many custom properties and associations it holds, and how many integrations write to or read from it. A small portal with a few pipelines can be moved in a short project, while a portal with years of deal history, custom objects and connected marketing tools needs far more planning.

In most cases an internal CRM or sales operations administrator owns the project, because they know the pipelines, the reporting and the people who depend on both. Many teams bring in an implementation partner for the hosting build, the data mapping scripts and the cutover checks, and keep the administrator in charge of business decisions such as which stages survive and which fields are retired. EspoCRM is licensed under AGPL-3.0, and the open-source edition can be downloaded and hosted in your own environment. It runs on PHP with MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, so the database choice and the hosting team's skills should be settled before the import design starts. Confirm the currently supported PHP and database versions in the EspoCRM server configuration documentation before you size the server.

Before any records move, ask the project team to confirm three things in writing: who holds HubSpot export permissions, which objects and associations must be preserved, and what the cutover window will look like if the old and new systems must run side by side for a period. Those answers set the export plan and the cost of the work, which is mostly one-time (scoping, mapping, migration runs, testing and training) plus recurring hosting, patching and admin time after go-live. Ask any partner for a fixed scope that lists the portal inventory, the mapping document and the acceptance tests, so that the price follows from the work described rather than from an estimate of hours.

Which HubSpot capabilities map cleanly to EspoCRM

This table compares the main HubSpot CRM capabilities with what EspoCRM provides out of the box, what needs rework, and where a gap remains. Read the rows marked clean as the core of the move, and budget time for the rework and gap rows before you set a cutover date. Marketing email, forms and sequences are a separate decision.

Capability	EspoCRM fit	What to plan
Contacts and companies	Clean	Map HubSpot contact and company properties to EspoCRM fields, then confirm duplicate handling during import
Deals and pipelines	Needs rework	Recreate each pipeline and stage by hand, then map deal properties and closed-won or closed-lost outcomes
Tickets and help desk	Needs rework	Confirm ticket and help desk coverage against your own use before committing, since ticket workflows are a separate design
Custom properties	Clean	Create matching fields in the Entity Manager and keep the HubSpot internal names in a mapping sheet
Associations	Needs rework	Export associated IDs with each record and rebuild links through import relationship columns
Activities and notes	Needs rework	Check which activity types your export includes, then decide whether historical notes move or are archived
Reports and dashboards	Needs rework	Reports are part of the Advanced Pack, included in all EspoCRM Cloud plans, so confirm the self-hosted licensing path for your setup
Workflows and automation	Needs rework	The Advanced Pack provides workflows and Business Process Management, and Formula Script drives before-save logic, so each HubSpot workflow needs a fresh design
User roles and login	Clean	EspoCRM supports OpenID Connect and LDAP, but its own 2FA is not compatible with OIDC, so plan login before cutover

Which HubSpot exports and integrations to plan for

Moving from HubSpot to EspoCRM runs on three routes: a one-time export from HubSpot, a one-time import into EspoCRM, and an ongoing sync through the REST API if both systems must run side by side. Each card below covers one of these routes or a related dependency, so the team can plan access, formats and mapping before any data moves.

HubSpot export permissions and formats

HubSpot lets users with export permissions export contacts, companies, deals, tickets and custom objects with their property values and associations, as CSV, XLSX or XLS files. Confirm with the HubSpot super admin which users hold export permission before the project starts, because a migration team without it will stall at the first extraction. Choose CSV or XLSX as the working format and test one object type end to end before running full portal exports.

Association columns and record linking

Deals, tickets and contacts reach their companies and each other through associations, which appear in the export as separate columns. Plan how each HubSpot record ID will be kept as an external ID field in EspoCRM so that contacts, accounts and opportunities can be relinked after import. Without that key, relationships must be rebuilt by hand from names and email addresses, which creates duplicates.

EspoCRM import as the load step

EspoCRM's import feature loads CSV files into entities, and the import docs describe how to map source columns to fields and choose how duplicates are handled. Run test imports into a staging instance with a copy of the data, then check record counts and sample relationships before loading production. Confirm that the import handles the custom fields and link columns you exported, since unsupported columns will need a scripted load.

REST API for ongoing sync

If HubSpot stays live during cutover, the EspoCRM REST API is the route for keeping records in step, since a one-time CSV load cannot capture changes made after export. The API supports API key, HMAC and basic authentication through dedicated API users with role-based permissions. Use HMAC for integration accounts, as the docs describe it as the most secure method, and avoid basic authentication, which the docs do not recommend.

User sign-in with LDAP or OIDC

Sales and service users will sign in to EspoCRM with the organization's identity provider rather than local passwords. EspoCRM supports OpenID Connect since version 7.3, 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. Note that EspoCRM's own two-factor authentication is not compatible with OIDC, so decide where second factors will be enforced before cutover.

Marketing and email sync mapping

Email sync, marketing consent, lists and form submissions do not travel with a CRM export in the same way as contacts and deals. Inventory which HubSpot marketing and email integrations are in use, then decide for each whether it moves to another tool, is rebuilt in EspoCRM through an official extension or integration, or is dropped. Map consent and unsubscribe status explicitly, because it cannot be inferred from a contact export alone.

Migration sequence from inventory to decommission

This sequence moves HubSpot sales records into a self-hosted EspoCRM instance in controlled stages, so each object, pipeline and user group is verified before HubSpot is switched off. Each step ends with a named output that the next step depends on.

Inventory objects, properties and workflows
List every HubSpot object in scope (contacts, companies, deals, tickets and any custom objects), along with its standard and custom properties, pipelines and deal stages, associations, active workflows, sequences and integrations that write data. Confirm the export permissions your admin user holds, since only users with export permissions can run exports. The output is an inventory sheet with an owner for each item and a decision on whether it is migrated, rebuilt or retired. The step is done when the business owners have signed off the list.
Build the field mapping sheet
Map each HubSpot property and association to an EspoCRM entity field, relationship or custom field, and note where a property has no equivalent and needs a new field or a decision to drop it. Record the data type, required status and picklist values for every field, and map HubSpot stage names to EspoCRM sales pipeline statuses. Agree the mapping with sales operations and the person who will own the EspoCRM configuration. The output is a field mapping sheet that serves as the reference for the staging import and for later reconciliation.
Run a pilot import into staging
Install EspoCRM on a staging instance in your own infrastructure, following the server requirements in the EspoCRM documentation, and configure the pipeline, stages and custom fields from the mapping sheet. Export a small, representative set of contacts, companies and deals from HubSpot, then import them with EspoCRM's import tool, using the import documentation to check file format and field matching. Load the associated records in an order that keeps relationships intact, and fix mapping errors before the next run. The output is a documented import procedure and a pilot dataset that users have reviewed.
Reconcile full extraction and record counts
Plan the full extraction around HubSpot's export limits, which allow up to 300 exports in a rolling 24-hour window and up to three exports running at once, so large portals may need to be split by object, owner or date range. Import the full set into staging and compare record counts, association counts, deal totals and stage distribution against HubSpot for every object. Investigate any difference and document its cause. The output is a reconciliation report signed by the data owner, with each variance either resolved or accepted in writing.
Run the parallel period
Keep HubSpot live while a defined group of sales users works in EspoCRM against the staging or production instance, and agree which system is the system of record for each object during this period. Set up the scheduled jobs EspoCRM needs for background processing, and test the notification, email and reporting features your team relies on. Track issues in a shared log, and rerun the delta import of changed HubSpot records when the parallel period needs refreshed data. The output is a log of resolved issues and a go decision from the business owner for cutover.
Cut over users and integrations
Move all users to EspoCRM and set up their roles, teams and permissions, then configure single sign-on or LDAP if your identity provider supports it. Repoint integrations, such as web forms, email sync and API clients, to EspoCRM, and create dedicated API users with the least permissions required. Freeze HubSpot data entry, run a final delta export and import, and reconcile the counts again. The output is a cutover record listing each integration, its new endpoint and the test that confirmed it worked.
Archive records and decommission HubSpot
Export a full archive of HubSpot records with properties and associations, store it in your own retention location, and confirm it can be read before access is removed. Check with your compliance and legal teams which retention rules apply to the archive. Then cancel or downgrade HubSpot subscriptions and remove the related integrations and API keys once the owners approve. The output is a stored, verified archive and a written decommission approval that records the date HubSpot access ended.

How HubSpot's export limits shape a large portal

HubSpot allows up to 300 exports in a rolling 24-hour window and up to three exports running at once. For a small portal this is invisible, but for a large one it sets the pace of the whole migration. Plan the extraction as a scheduled series of batches rather than one pull per object. Split each object (contacts, companies, deals, tickets and any custom objects) by date range, such as creation or last modified date, so that no single file is too large to handle and each batch can be rerun on its own if it fails. Run no more than three at a time, and keep the batch queue well under the 24-hour allowance so that a failed export does not block the rest of the plan.

Keep a reconciliation log from the first export. For every batch, record the object type, date range, file name, the row count HubSpot reported, the row count you loaded into EspoCRM and any records that were rejected during import. Count associations separately, because a contact-to-company link can be lost even when both records arrive intact. Store every exported file in write-once storage with a checksum and a retention period set by your legal and compliance team, so you can rerun an import or answer a dispute without depending on HubSpot still holding the data. Confirm with your portal administrator which export permissions your team holds, since only users with export rights can run these batches.

Before you build the plan, check the current row limits, column limits and association caps for your own portal in HubSpot's export records article. Those limits govern how many associated records appear in each file and whether a large association set is truncated, which decides how you split the batches. Ask HubSpot support to confirm anything the article does not state for your subscription tier. Also confirm how long download links remain active and how exports are delivered by email, because an expired link can cost you a batch and a day of the rolling allowance.

What drives migration cost and duration

This table lists the main drivers that change the cost and timeline of moving from HubSpot to EspoCRM, why each one matters and how to keep it down. Read it before requesting a quote, because the same scope can be fast and cheap or slow and expensive depending on how these drivers are set.

Driver	Why it changes cost or effort	How to keep it down
Objects and custom properties	Every HubSpot custom property needs a matching EspoCRM field, and field types, options and validation must be re-created by hand or by script.	Audit properties before export, retire unused ones and agree a field map in writing before any import begins.
Association complexity	Contacts, companies, deals and tickets link through associations, and HubSpot caps how many associations an export carries, so links must be rebuilt in a second pass.	Confirm which associations matter for daily work and document the key used to relink records in EspoCRM.
Pipelines and stages	Each HubSpot pipeline with its own stages becomes an EspoCRM stage configuration, and stage history rarely maps one to one.	Consolidate pipelines where possible and decide in advance whether historical stage timestamps must be kept.
Data quality and deduplication	Duplicate contacts, stale companies and inconsistent country or industry values add cleanup work before and after import.	Run deduplication in HubSpot or in a staging copy and set rules for which record wins before migrating.
Export volume and rate limits	HubSpot allows up to 300 exports in a rolling 24-hour window and up to three running at once, so large portals need a scheduled extraction plan.	Batch exports by object and date range, and plan extraction runs ahead of the cutover window.
Integrations and automations	Each connected tool, email sync, form or workflow must be rebuilt, re-pointed or dropped, and EspoCRM workflows use Formula Script and the Advanced Pack where needed.	Inventory every integration first and mark each as rebuild, replace or retire before scoping.
User, team and permission model	Teams, roles and field-level access in HubSpot must be mapped to EspoCRM teams and roles, and identity sign-in through OIDC or LDAP adds configuration.	Reduce roles to a short list agreed with the business and decide early on the identity provider and user provisioning method.
Self-hosting and hardening	Server build, PHP and database setup, cron jobs for background tasks, backups, TLS and API user setup are one-time tasks that recur with upgrades.	Use a standard reference architecture, automate backups and restores, and confirm the upgrade procedure before go-live.
Training and parallel run	Sales and service staff must learn new screens and processes, and a parallel run keeps HubSpot and EspoCRM open for a period, which extends the timeline and adds licence cost on the HubSpot side.	Train on a sandbox with real pipeline examples and set a fixed parallel-run end date with exit criteria.

What usually goes wrong in a HubSpot to EspoCRM move

Most failed CRM moves do not fail on the day of cutover. They fail because associations were dropped, duplicates were imported, or background jobs never ran after go-live. The six risks below connect the export, import, and operations steps, so each prevention step should be tested in a staging copy before the production load.

Lost associations between records

HubSpot exports contacts, companies, deals and tickets as separate files, and the links between them live in association columns. If those columns are not carried into EspoCRM's relationships, deals appear without a company and contacts without an account. Export each object with its association fields, import parent records first, then load links using the record IDs you saved from HubSpot. Spot-check a sample of deals against their contacts and companies in both systems before you sign off.

Duplicate records from repeated imports

Running an import twice, or importing contacts that already exist from a sales rep's manual entry, creates duplicate people and accounts that are hard to unwind later. Keep the HubSpot record ID as a custom field in EspoCRM so each row can be matched on a stable key rather than a name or email alone. Decide the matching rule before the first run, and deduplicate contacts that share an email address in the source file.

Pipeline stage mismatches

HubSpot deal stages and pipelines rarely map one to one onto EspoCRM's stage values. If stages are created on the fly during import, reports will split one business stage into several labels and forecasts will drift. Build the EspoCRM stage list first, write a table that maps each HubSpot pipeline and stage to it, and confirm that closed won and closed lost keep their dates and amounts. Ask sales leaders to sign off the mapping.

Permission gaps when importing users

Users, teams and roles in HubSpot do not carry over automatically. If records are imported under an administrator account, ownership and visibility will be wrong, and sales reps may see or edit accounts outside their territory. Create user accounts and teams before the import, assign each record to its owner, and test access with a non-admin account for each role. If you plan to use SSO, confirm how identity provider groups map to EspoCRM teams using the OIDC settings.

Broken integrations after cutover

HubSpot may still be feeding email tracking, form submissions, calendar links or other tools through its own connectors. When HubSpot is switched off, those flows stop silently. Inventory every integration and webhook that touches HubSpot, decide which ones move to EspoCRM's official extensions or REST API, and run both systems in parallel for a short period. API users should use HMAC keys with role-based permissions rather than basic authentication, which the docs do not recommend.

Missing backups and cron jobs

A self-hosted EspoCRM needs a scheduled job for background processing, such as workflows, email sending and some imports. If cron is not configured, these tasks queue and never run, which can look like a broken system after go-live. Set up cron on the server or scheduled task on Windows before cutover, and confirm the job runs. Take a full database and file backup before each large import, and test a restore on a separate host. Confirm the backup routine with your DBA or your hosting team.

How the migration differs by portal size and starting point

A small team on the free CRM tier usually has a modest number of contacts, companies and deals, a single pipeline and few custom properties. The export is typically the simplest of the three profiles, and a single full extraction of each object often covers the whole history. Because the data model is light, the pilot can be the full migration run on a copy of the data, and the parallel run can be short, since the team can re-enter a few late changes by hand if needed.

Export planning: Export each object once with its associations, then confirm row counts against the HubSpot views before you start the import.
Pilot scope: Load the full dataset into a test EspoCRM instance and check a sample of deals and their linked contacts.
Pipeline rebuild: Recreate the single pipeline and its stages by hand and compare them with a list of stage names exported from HubSpot.
Parallel run: Keep HubSpot read-only for a short window to catch late edits, then switch the sales team over.
Admin effort: Expect one person to handle the migration in a few working sessions, with the team's own time spent on checking records.

Confirm with your EspoCRM partner or your own admin how many users will need accounts, since the free tier of HubSpot does not carry over cost assumptions to self-hosted seats.

Questions buyers ask before a HubSpot to EspoCRM migration

How long does a HubSpot to EspoCRM migration take?

There is no fixed duration that fits every portal, and the honest answer depends on record volume, how many custom properties and pipelines exist, and how much cleanup happens before export. A small portal with a few pipelines and clean contact data is a very different project from a large portal with years of duplicate companies and undocumented custom objects. Ask for a written scope that lists object counts, the number of pipelines and stages to rebuild, the integrations to reconnect, and the export plan, because those items drive the timeline far more than the platform does. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the timeline follows from that document.

Can an internal team migrate from HubSpot to EspoCRM on its own?

A competent internal team can move a modest portal, provided one person owns the data model and someone can administer a PHP application server. The harder parts are usually not the import itself but mapping HubSpot associations to EspoCRM relationships, deciding which duplicates to merge, and rebuilding pipelines and workflows in the Entity Manager and Advanced Pack. Teams with no server administration experience, or with heavy automation in HubSpot, often bring in outside help for the migration and then run EspoCRM internally. Decide this before starting, and be clear about who will maintain the platform after cutover.

What does the migration need from our staff?

The work needs time from a sales operations owner who can sign off the field mapping, a HubSpot admin who can run exports with the right permissions, and a technical contact who can provision hosting and identity access. Sales leaders should review pipeline stages and reports before cutover, because rebuilding them is where users notice differences. Plan for parallel access during testing, a freeze window on HubSpot data entry, and users who can validate records after import. Ask any provider to name these roles in the scope so the dependency on your staff is visible before the project starts.

Can EspoCRM replace HubSpot tickets and marketing email?

EspoCRM covers contacts, accounts, opportunities, leads, cases and a REST API, so it can hold sales records and basic customer support cases. It does not provide a bundled marketing email, landing page or forms suite like HubSpot Marketing Hub, and it does not include a customer-facing help desk portal out of the box. Marketing usually needs a separate tool such as Mautic, and service ticketing may need a dedicated help desk if your support team relies on SLAs, channels and knowledge base articles. Confirm which HubSpot features your teams actually use before deciding the scope, because the gaps are where migrations stall.

How do HubSpot export limits affect the migration timing?

HubSpot lets permitted users export records such as contacts, companies, deals, tickets and custom objects with property values and associations as CSV, XLSX or XLS files. HubSpot allows up to 300 exports in a rolling 24-hour window and up to three exports running at once, so large portals need a staged extraction plan rather than a single export. Start the export schedule early, split large object sets by date or owner, and reconcile associations after each batch. Confirm current limits with HubSpot's knowledge base before you plan, since the limits are the controlling constraint on how long extraction takes.

What hosting and security work follows the migration?

EspoCRM's server configuration lists PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, running on Apache, Nginx or IIS, and it requires cron or a scheduled task for background jobs. The installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB and can set up Let's Encrypt certificates, and its command.sh utility handles backups, restores and upgrades. Ongoing work includes patching, monitoring, backup testing, and access control. EspoCRM supports OpenID Connect and LDAP, including Active Directory, but its own two-factor authentication is not compatible with OIDC, so plan identity design before go-live. Confirm the current release line in the EspoCRM releases page; the 10.0.10 release came out on October 14, 2026, and the previous major version 9.0.0 was released on January 20, 2025.

What does the migration cost, and what recurs afterward?

Costs fall into four groups: hosting infrastructure, one-time migration work, paid EspoCRM extensions if you need them, and recurring administration and support. The open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page, so the main spend is labor and infrastructure rather than licenses. The EspoCRM Cloud plans are priced per user per month, for example 15 US dollars per user on the Basic plan with a three-user minimum, according to the same pricing page, and this is a separate option from self-hosting. Ask any quote to separate one-time migration effort from recurring hosting, upgrades, backups and support.

How DeployOpen scopes and runs the move

DeployOpen plans, implements, integrates, hardens, backs up and documents a self-hosted EspoCRM instance inside your own cloud account, data center or air-gapped network, so the contact, deal and ticket data never leaves infrastructure you control. Most engagements are fixed-scope: the written scope, deliverables and timeline are agreed before any work starts. For a HubSpot move, that scope usually names the source portal and exports, the object mapping for contacts, companies, deals and tickets, the pipeline and stage rebuild, the user and team model, the authentication design, the migration rehearsals and the cutover window. Ask for each item to be listed with an owner on both sides, because the decisions that most often stall a migration (who signs off the field mapping, who approves the cutover) are rarely technical.

Hardening and handover are part of the scope, not extras. Expect work on the EspoCRM server configuration, the database and file-store backups, the cron job that EspoCRM requires for background tasks, and the API users with role-based permissions that your integrations will call. If your identity provider is the single sign-on source, the OpenID Connect or LDAP configuration, group-to-team mapping and fallback login should be specified in writing, since EspoCRM's own two-factor authentication does not work alongside OIDC. Documentation covers runbooks for backup, restore and upgrade, and evidence for your own assessors. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work.

After go-live, ongoing support, upgrades and continuous testing are available as a retainer, which is useful when your admin team is small and EspoCRM releases need to be planned and tested. The retainer scope should state which versions are covered, how security fixes are applied, and how incidents are escalated. DeployOpen does not publish a price list. Request a written scope and quote that separates one-time migration work from recurring hosting and support, and confirm what your own staff must provide, such as the source export, business sign-off and user acceptance testing.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a HubSpot to EspoCRM move, we start by agreeing the scope in writing, then build and test the EspoCRM environment and the record migration together, and hand over documented systems your team can run.

How we scope

Written, fixed scope listing the HubSpot objects, properties and associations to move into EspoCRM
Agreed inventory of pipelines, stages, users, teams and any Sales Hub automation to rebuild or drop
Confirmed hosting target, database choice and identity approach before any build work begins
Quote follows from the written scope, and ongoing support is available as a retainer

How we build

Install EspoCRM on your servers or cloud account with the supported PHP, database and web server versions
Map HubSpot export files and their association columns to EspoCRM entities, fields and links
Rebuild pipelines and stages, then run test imports on a copy of the data before any cutover
Test record counts, associations and permissions in a staging instance against the agreed scope

How we hand over

Document the field mapping, import steps, rerun procedure and any records that were not migrated
Provide runbooks for backups, restores and upgrades, including the scheduled jobs cron must run
Walk administrators through role, team and API user setup so access rules stay under your control
Deliver the configuration and evidence your compliance team needs to review the new CRM

How we support

Support after go-live covers fixes, upgrades and changes to pipelines or integrations, as agreed in the scope
Retainers can add scheduled upgrades, security testing and periodic restore checks
Compliance readiness work prepares systems and evidence, while independent auditors issue any reports
Confirm response expectations, support hours and change handling with us in the written agreement

Migrate from HubSpot to EspoCRM