Migrate your Civicrm data

Contacts are the primary entity with three built-in subtypes. We map each subtype to its destination equivalent and preserve all standard fields: names, addresses, emails, phones, and relationship links. The contact's internal ID is preserved as a cross-reference during migration.

Activities are the catch-all engagement record in CiviCRM. We map Activity type, subject, date, details, and assignee to the destination's activity or engagement object. Activities that represent pipeline-like stages require a structural translation into Deals or Opportunities.

Single-record custom groups appear as fields on the parent entity via the custom.* selector in APIv4. Multi-record sets appear as separate entities prefixed Custom_. We query both via API and reconstruct the full field set, but destination custom field creation must be scoped and ordered to avoid hitting MySQL's 61-join limit on the receiving platform.

Groups and their membership lists (GroupContact) are migrated as static segments. We preserve the group hierarchy where it exists. Dynamic (smart) groups cannot be fully reproduced without re-running the underlying search criteria on the destination platform.

Contributions include financial_type, total_amount, currency, receive_date, and payment_instrument. Price sets introduce variable line-item complexity that must be flattened or mapped to the destination's product/line-item model. Recurring contribution schedules are migrated as standing-order records.

Membership records include type, status, start_date, end_date, and source. Membership Price Sets allow complex tier structures that must be mapped to the destination's membership or subscription tiers. Membership-related custom fields land in the Custom_* migration path.

Events map to the destination's event or calendar object. Price sets, event types, and participant roles introduce variation. Online registration profiles are reconstructed as registration forms or intake fields on the destination. Recurring event series are split into individual event records.

CiviCase stores case_id, case_type, status, start_date, and a set of related activities. We map case records and their activity chains preserving timeline and assignee history. Case statuses are defined per-type and must be explicitly mapped to destination case statuses.

Relationships connect contacts (e.g., household member, employee-employer, spousal). We preserve the relationship type and both contact references. The bidirectional nature of some relationship types must be handled explicitly during import.

Tags are flat labels that attach to any entity. We map the tag name and its entity_id link to the destination's tagging or labeling system. Multi-entity tagging requires separate association records.

Grants is an optional extension module that not all CiviCRM instances have. Where present, we map grant_type, amount_requested, amount_granted, status, and deadline. Grant data often has tight coupling to the contact record as applicant.

ECK allows arbitrary custom entity types with user-defined properties and custom field attachments. These are extension-scoped and can reference contacts. We handle them as custom objects requiring explicit schema discovery per instance; there is no standard template for ECK entities.

CiviCRM stores file attachments either in the database (civicrm_file / civicrm_entity_file) or on the filesystem. We extract files and re-associate them with the destination record using the original file name and MIME type. Files stored outside the database require filesystem access and path remapping.

CiviMail mailing records include subject, body HTML, recipient groups, and delivery statistics. Mailings are tightly coupled to the mailing infrastructure (SMTP, SPF/DKIM configuration) and cannot be meaningfully reproduced on a different platform without re-creating templates and re-sourcing recipient lists from Groups.