CRM migration
Field-level mapping, validation, and rollback between Concord CRM and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.
Concord CRM
Source
Twenty CRM
Destination
Compatibility
6 of 10
objects map 1:1 between Concord CRM and Twenty CRM.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Concord CRM to Twenty CRM is a migration between two self-hosted, open-source CRMs with different data models and API architectures. Concord CRM organizes around Contacts, Companies, Deals, Products, and Activities with a Laravel-based REST API and CSV export capability. Twenty CRM uses People instead of Contacts, Opportunities instead of Deals, and supports Custom Objects via a metadata API at /metadata with data queried through GraphQL at /graphql. We sequence the export starting with Companies (referenced by Contacts via company_id), map Concord pipeline stages to Twenty Opportunity stages, and reconstruct Activity associations using the linked resource type and ID. Concord workflows, Views, and permission sets do not migrate; we document every active workflow trigger and action for the customer to rebuild in Twenty's workflow engine. Attachment files stored in Concord's storage/app directory require manual file-system extraction and re-upload because Concord provides no attachment export feature.
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 Concord 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.
Concord CRM
Company
Twenty CRM
Company
1:1Concord CRM Companies map directly to Twenty CRM Companies. We export Companies first in the migration sequence because Concord Contacts reference company_id as a foreign key. The Concord company name maps to Company.displayName, domain maps to Company.domainName, and address fields map to Company.address with street, city, state, country, and postalCode parsed from the exported address string. Custom fields on Company migrate to custom fields on Twenty's Company object.
Concord CRM
Contact
Twenty CRM
People
1:1Concord CRM Contacts map to Twenty CRM People. The contact's email is the primary identifier used for deduplication during import. We resolve the company association by looking up the Concord company_id against the migrated Company records and populate CompanyMember on the Twenty People record. First name and last name split from the exported full name or name fields. Phone, email, job title, website, and all standard fields map to their Twenty equivalents.
Concord CRM
Deal
Twenty CRM
Opportunity
1:1Concord CRM Deals map to Twenty CRM Opportunities. The Concord dealstage maps to the Twenty Opportunity stage field, but stage names must be reconciled because Concord stages are free-text values exported from the pipeline configuration, and Twenty Opportunity stages are configured in workspace settings before import. We require the customer to configure matching stage names in Twenty before migration begins so that stage assignment lands correctly.
Concord CRM
Deal Stage
Twenty CRM
Opportunity Stage
lossyConcord CRM pipeline stages export as raw values (e.g., 'Qualified', 'Proposal Sent', 'Won', 'Lost'). Twenty CRM Opportunity stages must be pre-created in Settings with exact name matches. We generate a stage mapping table during scoping that the customer uses to create matching stages in Twenty. Probability percentages from Concord custom stage configuration map to stage probability fields in Twenty if available.
Concord CRM
Pipeline
Twenty CRM
Pipeline
lossyConcord CRM supports multiple deal pipelines. Twenty CRM uses a single pipeline model with stage-based progression. If the customer uses multiple pipelines in Concord, we map each pipeline to a Twenty Opportunity stage group or document the mapping for manual segmentation after migration. Multi-pipeline reporting in Concord will require rebuilding views in Twenty.
Concord CRM
Product
Twenty CRM
Product
1:1Concord CRM Products export with name, price, SKU, and description. These map directly to Twenty CRM Products with the SKU mapping to the product code field. Product records are independent of other objects in Concord and import straightforwardly. Price book and pricing information is a future-state consideration for Twenty's pricing model if the customer expands use.
Concord CRM
Activity
Twenty CRM
Task or Note
1:manyConcord CRM Activities (calls, meetings, tasks) are reconstructed in Twenty as Task records for calls and tasks, and as Note records for meeting notes and standalone notes. We use the Concord activity linkedResourceType and linkedResourceId to reconstruct the association to the correct People or Company record in Twenty. The original activity date and notes body transfer to the Twenty record. Meeting invitations and attendee lists do not have a direct Twenty equivalent and are stored as Note body text.
Concord CRM
Custom Field
Twenty CRM
Custom Field
lossyConcord CRM custom fields use UUID as the API key and support boolean, date, select, text, and number types. Twenty CRM custom fields are created via the /metadata API. We create matching custom fields on the target object (People, Company, Opportunity, Product) before importing records, mapping the Concord field UUID and type to the Twenty field API name and data type. Select fields require value mapping if Concord uses picklist-style values.
Concord CRM
User
Twenty CRM
WorkspaceMember
1:1Concord CRM Users and roles are not available via the standard export feature. We retrieve user data via the Concord API (email, name, role) for mapping purposes. Twenty CRM WorkspaceMembers are provisioned by email during workspace setup. We match Concord owners on email and flag any Concord owner without a matching Twenty WorkspaceMember for manual provisioning before record import.
Concord CRM
Workflow
Twenty CRM
Workflow (manual rebuild)
1:1Concord CRM workflows (trigger: Company/Contact/Deal created, Deal stage changed; actions: Create Activity, Send Email, Trigger Webhook) do not execute during data import and cannot be migrated as automation code. We audit every active Concord workflow during scoping and deliver a written inventory documenting the trigger, conditions, actions, and recommended Twenty workflow equivalent. The customer's admin rebuilds workflows in Twenty after migration. This applies to both Concord's native workflow engine and any webhook-based integrations.
| Concord CRM | Twenty CRM | Compatibility | |
|---|---|---|---|
| Company | Company1:1 | Fully supported | |
| Contact | People1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Deal Stage | Opportunity Stagelossy | Fully supported | |
| Pipeline | Pipelinelossy | Fully supported | |
| Product | Product1:1 | Fully supported | |
| Activity | Task or Note1:many | Fully supported | |
| Custom Field | Custom Fieldlossy | Fully supported | |
| User | WorkspaceMember1:1 | Fully supported | |
| Workflow | Workflow (manual rebuild)1: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.
Concord CRM gotchas
Workflows do not fire during data import
Self-hosted data export requires role permission
API pagination cap at 100 records per page
Domain transfer requires full server migration
CSRF headers cause API auth failures
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 Concord audit
We audit the Concord CRM installation across object types (Contacts, Companies, Deals, Products, Activities), custom field definitions, pipeline and stage configurations, and active workflows. We verify API access by confirming the Bearer token permissions, the export permission assigned to the API user (role-based access control restricts export to admin or permitted users), and the server's ability to accept our integration client's requests without CSRF header rejection. We also assess the Activity volume because large activity histories require chunked processing through the Concord API pagination (100 records per page cap with header-based rate limit monitoring). The discovery output is a written migration scope with object counts, field inventory, and a workflow audit summary.
Twenty workspace preparation
Before any data import, we set up the Twenty CRM workspace. This includes configuring Opportunity stage names to match the Concord deal stages (required because Twenty stages must exist before Opportunity records can be assigned), creating Custom Objects and Custom Fields via the /metadata API to mirror Concord's custom field schema, and provisioning WorkspaceMembers for every Concord owner so that OwnerId references resolve during import. We recommend a clean Twenty workspace rather than pre-populated demo data to avoid record count confusion during reconciliation.
Export sequencing and company-first migration
We export Concord data in strict dependency order: Companies first, then Products (independent), then Contacts (with company_id resolved to the migrated Company), then Deals (with company_id and contact_id resolved), then Activities last. Companies must migrate first because Contacts reference company_id as a foreign key. We handle Concord's API pagination by iterating pages sequentially with rate limit header monitoring (X-RateLimit-Limit and X-RateLimit-Remaining) and exponential backoff on 429 responses. CSRF header stripping is applied to every API request to prevent authentication failures.
Activity reconstruction and custom field mapping
We reconstruct Concord Activities by parsing the linkedResourceType and linkedResourceId from the export, mapping each to the corresponding Twenty People or Company record using the migrated record identifiers. Calls and tasks become Task records with TaskSubtype=Call for call engagements; meeting notes and standalone notes become Note records. We map Concord custom field values to the Twenty custom field equivalents created in step two, handling type differences (Concord select fields become Twenty select fields, boolean fields become boolean fields). Concord select field values must be whitelisted in Twenty's field configuration before import.
Delta validation and sample reconciliation
We run a sample migration of the first 50-100 records of each object type and validate the following: record counts match between Concord export and Twenty import, People records are correctly associated to Companies via the company link, Opportunity records show the correct stage assignment, and Activity records appear on the correct People or Company timeline. The customer reviews the sample and confirms mapping accuracy before we proceed to full production migration. This step catches stage name mismatches, custom field type errors, and association resolution failures before they affect the full dataset.
Production migration and cutover
We run production migration in dependency order: Companies, Products, People (with CompanyMember resolved), Opportunities (with companyId and peopleId resolved), and Activities. Each phase emits a row-count reconciliation report. We freeze Concord writes during the cutover window, extract a final delta of any records modified during migration, load the delta into Twenty, and confirm the final record counts match the Concord source. We deliver the workflow inventory document to the customer's admin team for post-migration rebuild. Attachments stored in Concord's storage/app directory are outside our extraction scope and must be manually transferred via file-system access.
Platform deep dives
Concord CRM
Source
Strengths
Weaknesses
Twenty CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Concord CRM and Twenty CRM.
Object compatibility
2 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
Concord CRM: Per-minute limits documented in X-RateLimit-Limit and X-RateLimit-Remaining response headers; exact values vary and are not publicly specified.
Data volume sensitivity
Concord 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 Concord CRM to Twenty CRM migration scoping. Not seeing yours? Book a call.
Walk through your Concord 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 Concord 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.