Migrate from Clinic Management Software to Twenty CRM

The primary patient record maps to Twenty's People object. First name, last name, email, phone, and address fields migrate directly. Date of birth, medical record number, and insurance ID become custom fields on the People record. A source_system_id field stores the original Clinic Management Software record ID for traceability.

Providers map to People records with a custom role pick-list field set to 'Provider' or 'Physician' to distinguish them from patient People records. National Provider Identifier (NPI) and specialty fields migrate as custom fields on the provider's People record. The NPI field is created with a uniqueness constraint to prevent duplicate provider entries, and specialty is stored as a multi-select pick-list if needed for future reporting.

Every appointment becomes a Twenty Task linked to the patient People record (as assignee) and optionally to the provider People record (as a custom relation field). Task status maps from the appointment status value — 'Completed' becomes Task status 'Completed', 'Scheduled' becomes 'Not Started', and 'Cancelled' becomes 'Deferred' or a custom Cancelled value.

The appointment type (e.g., 'New Patient Exam', 'Follow-up', 'Telehealth') maps to a Task custom-type pick-list. We create the pick-list values in Twenty's Data Model during the schema-setup phase so the import script can assign the correct type to each Task record during migration.

Clinical notes and encounter summaries migrate as Twenty Notes attached to the related People record. Rich-text formatting is preserved where the source export supports it; plain-text fallback is applied otherwise. The original encounter date maps to the Note's creation timestamp or a custom date field.

Insurance carrier, policy number, group number, and coverage type have no native Twenty equivalent. We create custom fields on the People object — Insurance_Carrier__c, Policy_Number__c, Group_Number__c — and populate them from the source insurance sub-object before importing each patient record.

Billing claims and invoice records map to a Twenty custom object named BillingClaim with fields for claim ID, amount billed, amount paid, payer, claim status, and service date. We create the custom object via Twenty's Settings → Data Model API before the migration run. The BillingClaim object links to the patient People record via a relation field.

Referring provider name and contact information merges into the patient People record as a custom field (Referring_Provider_Name__c, Referring_Provider_Email__c). If the referring provider also exists as a Provider record in the source, we create a separate People record for them and link it via a custom relation field on the patient's record.

Treatment plan summary text migrates as a Note attached to the patient. Structured plan items (procedure codes, start date, end date) split into a custom CarePlan object with line items, linked to the patient via a relation field. This captures the narrative and the structured data separately in Twenty.

Lab results and diagnostic records lack a native Twenty object. We create a LabResult custom object with fields for test name, result value, unit, reference range, date collected, and status. The result narrative maps to a Note on the same record. Both objects link to the patient People record.

Clinic staff members who own records in the source system are matched to Twenty Workspace Members by email address. Unmatched owners are flagged before migration — the team either invites them to Twenty first or assigns their records to a default migration owner. The owner reference is stored as a relation field on each record.

File attachments from the source (consent forms, intake documents, insurance cards) are downloaded and re-uploaded as Notes with a file attachment reference. If Twenty's note-attachment mechanism is used, the original filename and upload date are preserved in custom metadata fields on the Note record.