Migrate from Pearl Dental Software to Twenty CRM

Pearl's patient-centric model has no native company concept, creating a Many-to-One routing problem in Twenty

Pearl organises everything around the patient record — referring dentists, NHS trusts, and DSO parent organisations are stored as free-text on patient records rather than as separate account entities. Twenty's data model requires a Company record to exist before you can link a People record via companyId. We extract every unique organisation name or domain from Pearl's patient records, deduplicate them, and create Company records first. This sequencing is mandatory: People import fails if the referenced companyId does not exist. The extracted organisation data is often incomplete (inconsistent spelling, missing addresses), so a fuzzy-deduplication step is required before the Companies batch is created.

Twenty has no appointment scheduling module — appointment history migrates as completed Tasks, not a live diary

Pearl's diary module manages live surgery scheduling with room bookings, practitioner availability, and patient recall flags. Twenty's task model has due dates and assignees but no calendar view, no room/surgery concept, and no availability overlap checking. Historical appointment records migrate as completed Tasks with the appointment type in the subject and the original date as the due date. Any future appointments in Pearl at cutover time are captured in the delta window as Tasks, but ongoing scheduling requires a third-party tool (Calendly, SimplyBook, or a dedicated dental scheduling system). This is a process gap, not a data gap — the history migrates; the live diary does not.

Clinical notes and treatment plans require custom objects not present in Twenty's standard schema by default

Pearl stores per-patient clinical notes, periodontal charting, treatment codes, and radiograph references as structured fields. Twenty's standard People object has no clinical fields — treatment plans, invoice history, and clinical note text must be modelled as a Treatment Plan custom object and a custom Invoice object, both created under Settings → Data Model before the CSV import runs. Twenty's documentation explicitly warns: 'Fields must exist before import. The CSV import creates records, not fields.' If custom objects are not pre-created, the import skips those fields silently. We deliver a schema setup plan listing every custom object and field to be created, with field types, before migration validation begins.

Pearl's NHS contract values and UDA/UDC targets are practice-level data that require careful routing to the correct Twenty object

NHS contract data (annual UDA targets, achieved UDA values, contract type) belongs to the practice entity rather than individual patients, but Pearl stores it inconsistently — sometimes as practice-level settings, sometimes as per-patient fields on NHS patients. In Twenty, the practice-level data should sit on the primary Company record representing the dental practice. If this data is stored per-patient in Pearl, we deduplicate and aggregate it to the practice-level Company record. Incorrect routing results in duplicated or missing contract data in Twenty's reporting.

Pearl's staff and practitioner records must be split — clinical staff go to People, admin users must be invited to Twenty before migration

Pearl treats practitioners (dentists, hygienists) and admin staff as staff records in one object. Twenty separates Workspace Members (users who log into Twenty) from People (contacts/patients). Clinical practitioners migrate as People records with a custom practitioner_role field. Admin users who need to access Twenty must be invited under Settings → Members first — their staff records can only reference them as Task assignees after their Twenty accounts exist. We generate a pre-migration checklist of every staff email that needs a Twenty invitation, so no staff record lands in Twenty without a resolvable assignee.