CRM migration
Field-level mapping, validation, and rollback between eZnet CRM and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.
eZnet CRM
Source
Twenty CRM
Destination
Compatibility
7 of 12
objects map 1:1 between eZnet CRM and Twenty CRM.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from eZnet CRM to Twenty CRM is an open-source migration for teams seeking more control and transparency than a proprietary SaaS vendor with a thin market footprint provides. eZnet CRM organizes data as Accounts, Contacts, Leads, Opportunities, and Activities with per-tier record limits and no publicly documented API. Twenty CRM uses a modern data model of People, Companies, Opportunities, and Activities with a documented REST and GraphQL API available both on cloud and self-hosted. We handle the migration by running a structured export against eZnet CRM, reconstructing the custom field schema from source metadata, then loading records into Twenty through its API using dependency order: Companies first, then People with AccountId resolved, then Opportunities with the resolved Company and Person references, then Activities. Workflows, marketing automation, and territory configurations do not migrate; we deliver a written rebuild guide for each.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a eZnet CRM object lands in Twenty CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
eZnet CRM
Account
Twenty CRM
Company
1:1eZnet CRM Accounts map directly to Twenty CRM Companies. The Account Name becomes Company name, Website maps to Company website, and any Account-level custom fields (industry classification, employee count, annual revenue) map to equivalent Company custom fields. Account-Contact associations are preserved by creating the Company record first in migration order so that Person records can reference it via the companyId field. We use Account name as the dedupe key during import.
eZnet CRM
Contact
Twenty CRM
Person
1:1eZnet CRM Contacts map to Twenty CRM Person records. Standard fields (firstName, lastName, email, phone, address) transfer directly. The Contact-Account association resolves to the Company record via companyId. Contact custom fields (department, title, preferred contact method) map to Person custom fields. If the Contact has an associated email integration record from eZnet CRM Professional tier, we preserve that as a note attached to the Person.
eZnet CRM
Lead
Twenty CRM
Person (or CSV staging)
1:manyeZnet CRM Leads are distinct from Contacts and carry lead status, source, and custom lead fields. Twenty CRM currently uses a unified Person model without a separate Lead object. We map Leads to Person records and flag them with a custom status field (e.g., lead_status__c = 'Lead') to preserve the original lead lifecycle. The customer's admin reviews and converts these Person records to opportunity-ready status post-migration. Lead source and score fields transfer to custom Person fields.
eZnet CRM
Opportunity
Twenty CRM
Opportunity
1:1eZnet CRM Opportunities map directly to Twenty CRM Opportunities. Pipeline stage names, deal amounts, expected close dates, and probability percentages transfer. The Opportunity-Account and Opportunity-Contact associations resolve to CompanyId and PersonId respectively during migration. Stage names map from eZnet pipeline stages to Twenty Opportunity stage values, with a stage mapping table reviewed and approved by the customer before import.
eZnet CRM
Pipeline and Stages
Twenty CRM
Opportunity stage configuration
lossyeZnet CRM pipeline and stage configuration (stage names, order, win/loss definitions) is captured from source and mapped to Twenty's Opportunity stage values. We create a stage mapping table as part of the migration scope document. The customer reviews and approves the mapping, then we configure Twenty's opportunity stages to match the business logic of the source pipeline. Probability percentages migrate from eZnet to Twenty stage probability fields.
eZnet CRM
Activity
Twenty CRM
Note and Task
1:1eZnet CRM Activities (calls, emails, tasks, events) map to Twenty CRM Notes and Tasks. Activity type distinguishes between note entries (mapped to Note) and action items (mapped to Task with Task status). Activity date, owner, and notes text transfer directly. The Activity-Contact and Activity-Account associations resolve to PersonId and CompanyId via the parent-record lookup we performed during scoping. Meeting-type activities become Event records in Twenty's activity model.
eZnet CRM
Document Library
Twenty CRM
Attachment (metadata only)
lossyeZnet CRM Document Library records contain file metadata (name, type, creation date, associated Contact or Account). We export the document metadata and link it to the parent Person or Company record in Twenty. Actual file blobs (PDFs, images, spreadsheets) require separate handling: we flag them as a manual step during scoping, provide the customer with a file list and attachment procedure, and note that the files need to be uploaded to Twenty's attachment system post-migration.
eZnet CRM
Custom Fields
Twenty CRM
Custom Field
lossyeZnet CRM custom fields (available on Standard tier and above) include data type, picklist values, and visibility settings. We capture the full custom field schema from the source system during scoping, then reconstruct it in Twenty CRM using Twenty's field creation interface or API. Picklist values map as-is; validation rules do not transfer and must be recreated manually in Twenty. The customer's admin reviews the custom field schema reconstruction before migration begins.
eZnet CRM
User (Owner)
Twenty CRM
Workspace User
1:1eZnet CRM Users with role-based assignments map to Twenty CRM workspace Users. Owner associations on Opportunities, Activities, and Contacts transfer by matching on user email. We reconcile owners by email against the Twenty workspace user list; missing users go to a provisioning queue for the customer's admin to create before record import resumes. Inactive users in eZnet CRM are preserved as historical owners in Twenty with inactive status where supported.
eZnet CRM
Marketing Campaign
Twenty CRM
Campaign (metadata)
1:1eZnet CRM Marketing Campaign records and associated campaign member associations to Contacts are exported. Campaign member status and engagement data transfer to Twenty as Campaign records linked to Person records. We note that marketing automation logic (email sequences, lead scoring triggers) does not migrate and must be rebuilt. The campaign metadata provides a record of what marketing programs existed for audit and attribution purposes.
eZnet CRM
Inventory Item
Twenty CRM
Custom Object or linked record
lossyeZnet CRM Inventory Items (Professional tier and above) include item records, stock levels, and pricing. We export inventory metadata as a custom data set. In Twenty CRM, there is no native inventory object, so inventory data is mapped to a custom object or linked as note-attached data on the relevant Company or Person. The customer's admin determines whether inventory data is relevant for their Twenty use case and how to structure it.
eZnet CRM
Custom Modules
Twenty CRM
Custom Object
1:1eZnet CRM Enterprise tier supports Custom Modules and Custom Related Lists. These map to Twenty CRM custom objects. We capture the full module schema including related list definitions, field types, and inter-object relationships, then reconstruct them in Twenty before the main record migration begins. Custom object naming follows Twenty conventions. Lookup relationships to standard objects (Company, Person, Opportunity) are re-established using the IDs resolved during parent-record import.
| eZnet CRM | Twenty CRM | Compatibility | |
|---|---|---|---|
| Account | Company1:1 | Fully supported | |
| Contact | Person1:1 | Fully supported | |
| Lead | Person (or CSV staging)1:many | Fully supported | |
| Opportunity | Opportunity1:1 | Fully supported | |
| Pipeline and Stages | Opportunity stage configurationlossy | Fully supported | |
| Activity | Note and Task1:1 | Fully supported | |
| Document Library | Attachment (metadata only)lossy | Fully supported | |
| Custom Fields | Custom Fieldlossy | Mapping required | |
| User (Owner) | Workspace User1:1 | Fully supported | |
| Marketing Campaign | Campaign (metadata)1:1 | Fully supported | |
| Inventory Item | Custom Object or linked recordlossy | Fully supported | |
| Custom Modules | Custom Object1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
eZnet CRM gotchas
Per-tier record limits create migration scope boundaries
No publicly documented API endpoint reference
Sparse public review corpus limits migration risk assessment
Twenty CRM gotchas
Import order is enforced and critical
Export limited to 20,000 records and visible columns only
Soft-deleted records count toward uniqueness and trigger restores
API rate limits cap at 200 req/min on Organization tier
No native email sequences — follow-up cadences require external tools
Pair-specific challenges
Migration approach
Discovery and export format assessment
We audit the source eZnet CRM instance across tier (Standard/Professional/Enterprise/Private Cloud), total record counts per object (Accounts, Contacts, Leads, Opportunities, Activities, Documents, Custom Modules), and custom field inventory. Because eZnet CRM has no documented API, we work with the customer to identify the available export mechanism: CSV export from within eZnet, direct database read for Private Cloud deployments, or a third-party export tool. We document the export format (columns, delimiters, encoding) and use it to infer the full field schema. The discovery output is a written migration scope document with record counts, identified export mechanism, and any data quality flags (missing required fields, duplicate candidates, orphaned relationships).
Schema design and custom field reconstruction
We design the destination Twenty CRM schema. This includes creating the standard objects (Companies, People, Opportunities) with any required custom fields mapped from the inferred eZnet field schema. We reconstruct picklist values, data types, and visibility settings based on what we observed in the export data. The customer reviews and approves the custom field reconstruction before we begin building the destination schema. We also configure Twenty's Opportunity stages to match the eZnet pipeline stage names and probabilities using the stage mapping table. For self-hosted Twenty, we coordinate with the customer's infrastructure team to confirm API access and database backup procedures.
Sandbox validation and reconciliation
If the customer is using Twenty Cloud or has a staging self-hosted instance, we run a full migration into the sandbox using production-like data volume. The customer reconciles record counts (Companies in, People in, Opportunities in, Activities in), spot-checks a random sample of records against the eZnet source, and validates that relationships (Person-Company, Opportunity-Company, Opportunity-Person) are intact. Any field mapping corrections happen in the sandbox, not in production. For customers without a staging environment, we perform the first migration as a dry run and review the output with the customer before committing to production.
Owner and user reconciliation
We extract every distinct eZnet CRM User referenced as an owner on Opportunities, Activities, and Contacts and match by email against the Twenty workspace user list. Any eZnet User without a matching Twenty User goes to a reconciliation queue for the customer's admin to provision. This step cannot be skipped because OwnerId references on Opportunities and Activities must resolve to a valid Twenty user at import time. We also flag any inactive eZnet users for preservation as historical owners.
Production migration in dependency order
We run production migration in record-dependency order. First, we migrate Companies (from eZnet Accounts), resolving any duplicate Company names against the dedupe key. Second, we migrate People (from eZnet Contacts and Leads), resolving the companyId reference for each Person. Third, we migrate Opportunities with AccountId, PersonId, and OwnerId resolved at migration time. Fourth, we migrate Activities (Notes and Tasks), resolving WhoId and WhatId to the migrated Person and Company IDs. Fifth, we migrate any Custom Modules to Twenty custom objects (last, because they often have lookups to standard objects). Document metadata migrates as attachments linked to the parent record. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and rebuild handoff
We coordinate a cutover window during which no new records are created in eZnet CRM. We run a final delta migration of any records modified during the migration window, then the customer switches their team to Twenty CRM as the system of record. We deliver the workflow and automation inventory document to the customer's admin team for rebuild in Twenty's configuration options or a third-party automation layer. We provide a document upload guide with the file inventory from the eZnet Document Library for bulk upload. We support a one-week hypercare window where we resolve any record relationship or data quality issues reported by the customer's team. Workflow rebuild, automation rebuild, and post-migration admin training are outside standard migration scope and can be scoped as separate engagements.
Platform deep dives
eZnet CRM
Source
Strengths
Weaknesses
Twenty CRM
Destination
Strengths
Weaknesses
Complexity grading
Moderate CRM migration. 4 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across eZnet CRM and Twenty CRM.
Object compatibility
4 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
eZnet CRM: Not publicly documented.
Data volume sensitivity
eZnet CRM doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during eZnet CRM to Twenty CRM migration scoping. Not seeing yours? Book a call.
Walk through your eZnet CRM to Twenty CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave eZnet CRM
Other ways to arrive at Twenty CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.