Migrate from Civicrm to Twenty CRM

CiviCRM Individual contacts map to Twenty People. Organization contacts map to Twenty Company. Household contacts — a CiviCRM-specific subtype representing multi-person family units — present a mapping challenge because Twenty has no Household equivalent. We map Household contacts to Twenty Company records (using the Household name as displayName) and store the member relationship in a custom relationship field on each People record. The contact network relationship chain (spousal, employee-employer, household membership) is preserved via Twenty's relationship system, with the original CiviCRM relationship type ID stored as a tag for audit.

CiviCRM Activity is a unified engagement record with activity_type_id distinguishing call, email, meeting, and other types. We split Activities at migration time: type_id 1 (Meeting) maps to Twenty Event, type_id 2 (Email) maps to Note with an is_email flag, type_id 3 (Call) maps to Task with TaskSubtype=Call, and all other types map to Task. The original CiviCRM activity_type_id is preserved in a custom tag on the target record. Activity assignments (assignee_id) map to Twenty workspace members by email match.

CiviCRM Groups with static membership (GroupContact records) map to Twenty tags on People records. We preserve the group hierarchy where it exists. Dynamic (smart) groups that use CiviCRM search-based filtering cannot be fully reproduced because Twenty does not have a smart-group equivalent — we document each dynamic group's criteria as a written filter definition for the customer to recreate manually in Twenty's filter system.

CiviCRM Contributions include financial_type, total_amount, currency, receive_date, payment_instrument, and source. We create a financial_payment custom object in Twenty (via Settings → Data Model) with fields for amount, currency, payment date, payment method, and contribution source. Organizations that prefer Opportunity tracking for donations map Contributions to Opportunity records using a donation record type. Price Sets on Contributions introduce variable line-item complexity that must be flattened — we flatten to a single total_amount unless the customer requests line-item preservation.

CiviCRM Membership records include type, status, start_date, end_date, and source. Membership Price Sets allow complex tier structures. We create a membership custom object in Twenty with fields for membership_type, status, start_date, end_date, and source, linked to the Company record representing the member organization or the People record for individual members. Membership status transitions (e.g., New → Current → Expired) are preserved as tags rather than native status workflows.

CiviCRM Events map to Twenty Event records. We map event title, start_date, end_date, location, description, and event_type. Price sets and participant fees flatten to a single registration_fee field. Participant roles (Attendee, Speaker, Volunteer) migrate as tags on the Event. Online registration profiles are not migrated as forms — we document the registration configuration for the customer's admin to recreate in Twenty's form or external registration tool.

CiviCase stores case_id, case_type, status, start_date, and a set of related activities. Case statuses are defined per case_type in XML or PHP entityType — they are not a global status list. We enumerate every active case_type during discovery, extract its status option values, and map each set individually to a status picklist on the Twenty case custom object. The activity chain (case timeline) migrates as a sequence of Task records with a custom case_id reference. Cases that reference specific case_type XML files require us to parse those files during scoping.

Single-record custom groups appear as fields on the parent entity via the custom.* selector in CiviCRM APIv4. We map each custom field to a typed Twenty custom field (text, number, date, picklist, multi-select picklist) on the corresponding object. Field labels and help text are preserved. Picklist options migrate as picklist values in Twenty's field settings.

Multi-record custom groups appear as separate entities prefixed Custom_ in CiviCRM. We create a custom object in Twenty for each multi-record group and link it to the parent contact record via a lookup relationship. For sites with more than approximately 20 custom groups, we query individual records entity-by-entity rather than using APIv4's custom.* wildcard selector to avoid exceeding MySQL's maximum join count (61 joins). The multi-record table structure is flattened into a standard custom object row format.

CiviCRM Relationships connect contacts (household member, employee-employer, spousal, etc.) with a relationship_type_id and bidirectional flag. We map each Relationship to Twenty's relationship system, resolving both contact references by their CiviCRM contact_id. The original relationship_type_id is preserved as a tag for audit. Bidirectional relationships are mapped as a single relationship in Twenty.

CiviCRM Tags are flat labels attached to any entity via the EntityTag join table. We map tag names to Twenty tags, preserving the entity_id link on each migrated record. Multi-entity tagging (a tag applied to both a Contact and an Event) is handled with separate tag associations per record.

Grants is an optional CiviCRM extension module. Where present, we create a grant custom object in Twenty with fields for grant_type, amount_requested, amount_granted, status, and deadline. Grant data often has tight coupling to the CMS user that submitted it — we map the CiviCRM contact associated with the grant rather than the CMS user account.