CRM migration

Migrate from OpenCRM to Twenty CRM

Field-level mapping, validation, and rollback between OpenCRM and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.

OpenCRM logo

OpenCRM

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

80%

8 of 10

objects map 1:1 between OpenCRM and Twenty CRM.

Complexity

CModerate

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from OpenCRM to Twenty CRM is a migration from a UK-based VtigerCRM fork to a modern open-source CRM built in 2023 with a TypeScript/React stack and a GraphQL API. OpenCRM uses CSV exports as its primary data extraction mechanism and stores Contacts linked to Companies via foreign-key relationships; Deals carry pipeline stage names that require manual mapping. Twenty CRM uses a different object model: OpenCRM Companies map to Twenty Companies, OpenCRM Contacts map to Twenty Persons, and OpenCRM Deals map to Twenty Opportunities. A key migration constraint is that Twenty ships with minimal standard fields on Person and Company objects, requiring custom field creation via the /metadata GraphQL API before record import begins. We pre-create the full custom field schema in Twenty, sequence the import as Companies first then Persons then Opportunities, and resolve owner references through email matching. Workflows, automations, and custom integrations do not migrate; we deliver a written inventory of these for the customer to rebuild in Twenty's workflow builder or via connected n8n automations.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

OpenCRM logo

OpenCRM

What's pushing teams away

  • User interface looks and feels dated compared to modern CRM tools, with clunky navigation, hard-to-find menus, and a visual design that frustrates teams accustomed to contemporary UX.
  • Bugs and performance issues reported by some users including software freezing and unexpected behavior, particularly under heavy use or with large datasets.
  • Limited public API documentation and no developer community presence, making custom integrations and programmatic data access harder to implement without vendor involvement.
  • Smaller market share and review volume compared to major CRM platforms, meaning fewer community resources, third-party integrations, and migration guides are available online.

Choosing

Twenty CRM logo

Twenty CRM

What's pulling them in

  • Top open-source CRM on GitHub with 40.6K stars, giving teams full source code access and infrastructure ownership without per-feature licensing surprises.
  • Free self-hosting under AGPL-3.0 means unlimited users and custom objects for the cost of cloud infrastructure alone, typically $20–100/month.
  • Pricing page explicitly mocks competitors for charging add-on fees for API access, webhooks, and workflows — transparency that resonates with RevOps teams burned by Salesforce.
  • Unlimited custom objects and fields with no price impact, letting teams shape the data model to their business rather than forcing business into rigid schemas.
  • Modern TypeScript/React/PostgreSQL stack means developer-led teams can extend, self-host, or integrate without fighting legacy architecture.

Object mapping

How OpenCRM objects map to Twenty CRM

Each row shows how a OpenCRM 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.

OpenCRM

Company

maps to

Twenty CRM

Company

1:1
Fully supported

OpenCRM Company records map directly to Twenty Company records. We extract the full OpenCRM Company dataset via CSV export including all standard fields (name, domain, address, phone) and any custom fields discovered during scoping. The Company record is imported first because OpenCRM Contacts are linked to Companies via foreign-key relationship; without the parent Company present, Contact imports would create orphaned Person records with no company association.

OpenCRM

Contact

maps to

Twenty CRM

Person

1:1
Fully supported

OpenCRM Contact records map to Twenty Person records. The OpenCRM contact_email, contact_phone, contact_firstname, and contact_lastname fields map to Twenty's Person standard fields. A key pre-migration requirement in Twenty is that many industry-standard fields (job title, department, phone type) do not exist as standard fields and must be created via the /metadata GraphQL API before Person import. We create these custom fields during the schema preparation phase so that field mapping can complete field-by-field rather than collapsing into generic text fields.

OpenCRM

Deal

maps to

Twenty CRM

Opportunity

1:1
Fully supported

OpenCRM Deals map to Twenty Opportunities. The OpenCRM deal name, value (amount), expected close date, and owner assignment transfer directly. Pipeline stage names from OpenCRM require a stage-mapping table because Twenty Opportunity stages are tenant-defined and rarely align one-to-one with OpenCRM's workflow-specific stage names. We produce this mapping during scoping and present it for customer confirmation before the Opportunity import runs.

OpenCRM

Activity (Call, Meeting, Task)

maps to

Twenty CRM

Task / Event

1:1
Fully supported

OpenCRM Activity records (calls, meetings, tasks) are supported for migration with timestamp normalization to UTC and owner mapping by email match to Twenty users. Twenty stores task-type activities as Task records and meeting-type activities as Event records. We validate that each activity has a valid Person or Company reference before import so the activity lands in the correct Twenty timeline.

OpenCRM

Note

maps to

Twenty CRM

Comment

1:1
Fully supported

OpenCRM Notes attached to Contacts, Companies, or Deals migrate to Twenty Comment records linked to the corresponding Person or Company. Note body content migrates as rich text. We validate parent record linkage after import to confirm notes are associated with the correct entity in Twenty.

OpenCRM

Custom Field (all objects)

maps to

Twenty CRM

Custom Field

lossy
Fully supported

OpenCRM custom fields on Contacts, Companies, and Deals require pre-creation in Twenty via the /metadata GraphQL API before migration begins. We discover all custom field names, data types, and object assignments during the scoping phase, then create the corresponding Twenty custom fields with matching API names. This is a required step because Twenty's Person and Company objects ship with minimal standard fields and imports that attempt to populate non-existent fields will silently fail or reject records.

OpenCRM

Tag / Label

maps to

Twenty CRM

Tag

1:1
Fully supported

Tag-based categorisation on OpenCRM Contacts and Companies migrates as flat string arrays to Twenty Tags. Tags used for content classification migrate as Twenty Tag records with TagAssignment records linking to the Person or Company. The customer confirms tag strategy during scoping since Twenty supports both object-level tags and workspace-level topic tagging.

OpenCRM

User / Owner

maps to

Twenty CRM

WorkspaceMember

1:1
Fully supported

OpenCRM user records and deal/contact ownership assignments are resolved by email match against Twenty WorkspaceMember records. Any OpenCRM Owner without a matching Twenty user goes to a reconciliation queue for the customer to provision before record import resumes. Owner resolution is required before Contacts and Deals can be imported because both record types carry an owner reference in Twenty.

OpenCRM

Pipeline Stage

maps to

Twenty CRM

Pipeline Stage

lossy
Fully supported

OpenCRM allows full customisation of pipeline stage names per workflow. We produce a stage-mapping table during scoping that maps each OpenCRM stage name to the corresponding Twenty Pipeline stage value. The customer reviews and approves this table before Opportunity import so every Deal lands in the correct stage.

OpenCRM

Attachment

maps to

Twenty CRM

Attachment (file reference)

1:1
Fully supported

File attachments stored against OpenCRM Contacts, Companies, or Deals are extracted from the OpenCRM UI export and staged in a file store. We generate reference links in Twenty pointing to the staged file store so the attachment context is preserved even if the attachment content is not embedded in Twenty's object model. Full file embedding in Twenty is available via the /graphql API for implementations that require it.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

OpenCRM logo

OpenCRM gotchas

High

Bulk import without CRM ID or ExternalID creates duplicate records

Medium

Import ordering dependency: Companies before Contacts

Medium

No documented public REST API for programmatic export

Low

Pipeline stage names are tenant-defined and require manual mapping

Twenty CRM logo

Twenty CRM gotchas

High

Import order is enforced and critical

High

Export limited to 20,000 records and visible columns only

Medium

Soft-deleted records count toward uniqueness and trigger restores

Medium

API rate limits cap at 200 req/min on Organization tier

Low

No native email sequences — follow-up cadences require external tools

Pair-specific challenges

  • Twenty requires custom field creation before import

    Twenty CRM ships with minimal standard fields on Person and Company objects. GitHub issue #13953 documents that users must spend 30 to 60 minutes creating basic fields before starting to use the CRM, and CRM-to-CRM import mapping fails because standard fields do not exist. We address this by querying Twenty's /metadata GraphQL endpoint during scoping to enumerate existing fields, then pre-creating all required custom fields (job title, department, phone type, address components, custom OpenCRM fields) via the /metadata API before any Person or Company import runs. Skipping this step results in rejected records or fields silently dropping during CSV-to-GraphQL mapping.

  • OpenCRM has no REST or GraphQL API for programmatic extraction

    OpenCRM's primary data extraction method is the CSV export available through the UI. There is no publicly documented bulk REST or GraphQL endpoint for automated extraction. We work around this by exporting full-column CSV for each object (Company, Contact, Deal, Activity, Note) from the OpenCRM list view, parsing the files, staging them in a transformation environment, and then loading into Twenty via the GraphQL bulk mutation endpoint. The CSV export requires manual initiation per object and column selection, which we coordinate with the customer's OpenCRM admin during the discovery phase.

  • Workflows and automations do not migrate between platforms

    OpenCRM's built-in workflow rules and automation triggers have no direct equivalent in Twenty CRM's workflow builder. Twenty's workflow builder supports record-triggered automations but the action library, trigger conditions, and delay models differ from OpenCRM's rule engine. Reddit discussions on the Twenty CRM community also note that native sequencing (time-delayed follow-up cadences) is not yet a native Twenty feature, requiring n8n or similar external automation for sequence management. We do not migrate OpenCRM workflows as code. We deliver a written inventory of every active OpenCRM workflow with its trigger, conditions, actions, and recommended Twenty or n8n equivalent, and the customer's admin rebuilds them post-migration.

  • Import ordering dependency: Companies before Contacts

    OpenCRM Contacts are linked to Companies via a foreign-key relationship. Importing Contacts into Twenty before Companies results in broken parent references and Persons without a company association. We sequence the migration as Companies first, then Contacts (Persons), then Deals (Opportunities). We validate all Person-to-Company linkage before marking the migration complete and run a post-import audit to confirm every Person has a valid companyId reference in Twenty.

  • Bulk import without matching key creates duplicate records

    OpenCRM's CSV import mechanism requires either the native OpenCRM record ID or a pre-mapped ExternalID to perform update operations. Launching an update import without one of these identifiers creates new, orphaned records rather than updating existing ones. We always export the current OpenCRM record ID column first, include it in the CSV as a legacy key, and use it as the dedupe and upsert matching key during Twenty GraphQL import. This prevents duplicate Companies and Persons from being created if the migration needs to run multiple times for reconciliation.

Migration approach

Six steps for a successful OpenCRM to Twenty CRM data migration

  1. Discovery and CSV export scoping

    We audit the OpenCRM tenant to enumerate all active modules (Contacts, Companies, Deals, Activities, Notes), custom field names and data types, pipeline stage names, owner assignments, and tag usage. We coordinate with the customer's OpenCRM admin to export full-column CSV for each object from the OpenCRM list view. We simultaneously query Twenty's /metadata GraphQL endpoint to enumerate existing standard and custom fields and identify the gap that requires custom field pre-creation. The discovery output is a written migration scope document with the full field mapping matrix and a list of Twenty custom fields to create before import.

  2. Twenty schema preparation and custom field creation

    We create all required custom fields in Twenty via the /metadata GraphQL API before any record import. This includes OpenCRM custom field equivalents on Person and Company, plus any industry-standard fields (job title, department, phone type, industry, annual revenue) that OpenCRM has as standard but Twenty does not. We deploy the schema to a Twenty staging instance (or sandbox equivalent) for validation before production migration. We also configure Pipeline stages in Twenty to match the OpenCRM stage names, using the stage-mapping table confirmed with the customer during scoping.

  3. CSV parsing, transformation, and reconciliation

    We parse the exported OpenCRM CSV files, apply the field mapping matrix, normalize date formats to ISO 8601 UTC, resolve owner email addresses to Twenty WorkspaceMember IDs, and validate that every Contact has a valid Company reference. Any records with broken parent references, missing required fields, or invalid data formats are flagged in a pre-import reconciliation report for the customer to review and resolve before loading. We also deduplicate on the OpenCRM record ID to prevent duplicate creation on any re-run.

  4. Staging migration and sign-off

    We run a full migration into a Twenty staging instance using production-like data volume. The customer's ops lead reconciles record counts (Companies in, Persons in, Opportunities in, Activities in), spot-checks 25 to 50 random records against the OpenCRM source, and confirms the Person-to-Company linkage and Opportunity stage assignments are correct. Any mapping corrections are applied to the transformation logic before the production migration runs. This step is the last opportunity to adjust field mapping without affecting live data.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Companies first (from OpenCRM Company CSV), then Persons with companyId resolved from the newly created Company records, then Opportunities with stage name mapped via the confirmed stage table, then Activities and Notes linked to their parent Persons and Companies. Each phase emits a row-count reconciliation report. Owner resolution by email match happens during the preparation phase; any OpenCRM Owner without a matching Twenty WorkspaceMember is held in a reconciliation queue.

  6. Cutover, validation, and workflow rebuild handoff

    We freeze OpenCRM write access during cutover, run a final delta migration of any records modified during the migration window, then enable Twenty as the system of record. We deliver the OpenCRM workflow and automation inventory document to the customer's admin team with recommended Twenty workflow builder equivalents. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team. We do not rebuild OpenCRM workflows in Twenty's workflow builder or configure n8n sequences inside the migration scope; those are separate engagements or internal admin tasks.

Platform deep dives

Context on both ends of the pair

OpenCRM logo

OpenCRM

Source

Strengths

  • All features available at every subscription tier with no feature paywalls or upgrade gates.
  • Per-user flat-rate pricing independent of contact database size.
  • Bundled consultancy, training, and support services included as standard.
  • Built on the proven VtigerCRM open-source codebase with over 5 million downloads since 2004.
  • Web-based deployment with automatic updates and no self-hosting complexity.

Weaknesses

  • Dated user interface and navigation UX compared to modern CRM competitors.
  • Limited public API documentation and developer ecosystem.
  • Small market share with fewer third-party integrations than major platforms.
  • Reported bugs and performance issues under heavy or complex usage.
  • Sparse community resources and migration guides available online.
Twenty CRM logo

Twenty CRM

Destination

Strengths

  • AGPL-3.0 open-source license with full source code on GitHub — no vendor lock-in, no sunset risk.
  • Unlimited users and unlimited custom objects on self-hosted, with no feature gating based on headcount.
  • REST and GraphQL APIs available on all paid tiers, not locked behind an enterprise add-on fee.
  • MCP server and webhooks shipped as standard features, not premium upgrades.
  • Modern PostgreSQL-backed data model that developer teams can query, extend, and self-host.

Weaknesses

  • Recent v1.0 release means limited production hardening compared to CRMs with multi-year operational track records.
  • No native email sequencing or sales engagement tools — follow-up cadences require a separate platform.
  • No native two-way email sync or inbox integration, requiring third-party connectors for full activity logging.
  • Self-hosting 'free' pricing hides real infrastructure and DevOps costs that stack up over time.
  • Workflow automation is functional but lacks the complexity needed for sophisticated multi-step sales motions.

Complexity grading

How hard is this migration?

Moderate CRM migration. 4 of 8 objects need a mapping; the rest are 1:1.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across OpenCRM and Twenty CRM.

  • Object compatibility

    C

    4 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    OpenCRM: Not publicly documented.

  • Data volume sensitivity

    B

    OpenCRM doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your OpenCRM to Twenty CRM migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about OpenCRM to Twenty CRM data migrations

Answers to the questions buyers ask most during OpenCRM to Twenty CRM migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your OpenCRM to Twenty CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between three and five weeks for accounts under 15,000 Contacts and 3,000 Deals with fewer than 30 custom fields. Migrations with extensive custom field schemas (over 50 fields), multiple OpenCRM modules, large activity histories, or complex tag and owner structures move to seven to twelve weeks because of the custom field pre-creation work via Twenty's /metadata API and the CSV parsing and reconciliation steps.

Adjacent paths

Related migrations to explore

Ready when you are

Move from OpenCRM.
Land in Twenty CRM, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day