CRM migration
Field-level mapping, validation, and rollback between tab32 and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.
tab32
Source
Twenty CRM
Destination
Compatibility
11 of 11
objects map 1:1 between tab32 and Twenty CRM.
Complexity
BStandard
Timeline
5–10 business days
Overview
tab32 is a cloud dental practice management system built for dental service organizations. Its data model centers on patient records, clinical tooth charts, perio charting, treatment plans, appointments, provider schedules, insurance claims, and billing transactions. It exposes an Open Data Warehousing API for analytics exports. Twenty CRM is a general-purpose open-source CRM built on PostgreSQL with standard objects for People (contacts), Companies (accounts), Opportunities (deals), Notes, and Tasks, plus unlimited custom objects. The migration maps tab32's patient-centric clinical model into Twenty's relational object graph — Patients become People, Practices become Companies, and clinical data like tooth charts and perio records migrate as custom objects or custom fields on the People record. We pull data through tab32's export and API surfaces, sequence the import respecting Twenty's dependency order (Companies → People → Opportunities → Custom objects), and surface dental-specific clinical data that requires manual schema design in Twenty. A sample migration with field-level diff runs before the full cutover; a 24–48-hour delta pickup captures in-flight records during the switch.
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 tab32 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.
tab32
Patient
Twenty CRM
People
1:1tab32 Patient records map directly to Twenty CRM People. Patient first name, last name, date of birth, phone, email, address, and emergency contact fields translate to the corresponding Twenty People fields. Original patient ID stored as a custom field (tab32_Patient_ID__c) for traceability and delta-run de-duplication.
tab32
Practice / Office Location
Twenty CRM
Company
1:1tab32's practice or office location records map to Twenty CRM Companies. Practice name becomes Company name, address maps to the Company address fields, phone maps to the main phone field. Each DSO location becomes a distinct Company record so pipeline reporting can aggregate across locations.
tab32
Provider / Doctor
Twenty CRM
Workspace Member
1:1tab32 Provider records (dentists, hygienists, specialists) map to Twenty CRM Workspace Members. Provider specialty (GP vs. specialist) and license number map to custom text fields on the member profile since Twenty does not have a native specialty field. Providers who are also sales contacts map as both People and Workspace Members.
tab32
Appointment
Twenty CRM
Task
1:1tab32 appointment records (date, time, provider, operatory, procedure) map to Twenty CRM Tasks linked to the People (patient) record. The appointment status (confirmed, completed, no-show) maps to Task status. Custom fields capture the CDT procedure code, operatory, and provider assignment since Twenty Tasks lack native scheduling fields.
tab32
Treatment Plan
Twenty CRM
Custom Object: Treatment Plan
1:1tab32 treatment plans list procedures with CDT codes, tooth numbers, fees, and clinical notes. These require a custom Treatment Plan object in Twenty CRM with a relation to the People record. Each plan line item becomes a child record or a multi-select field on the treatment plan, depending on the volume of line items per patient.
tab32
Perio Chart / Periodontal Record
Twenty CRM
Custom Object: Perio Exam
1:1tab32 perio pocket depth records (six sites per tooth, BOP, furcation, mobility) have no Twenty CRM equivalent. We create a custom Perio Exam object linked to the People record, with numeric fields for each tooth site and a date field for the exam date. Historical perio exams are preserved as separate records ordered by exam date.
tab32
Insurance Claim
Twenty CRM
Custom Object: Insurance Claim
1:1tab32 insurance claim records (claim ID, status, submitted amount, paid amount, payer, CDT codes, adjustment reasons) map to a custom Insurance Claim object linked to the People record. Claim status values (submitted, pending, paid, denied) map via value mapping to the custom pick-list in Twenty.
tab32
Tooth Chart / Clinical Notes
Twenty CRM
Custom Object: Tooth Condition
1:1tab32 tooth chart records (surface conditions per tooth using the Universal Numbering System) require a custom Tooth Condition object linked to People. Each tooth number (1–32) plus surfaces (M, O, D, B, F, L) map to a custom pick-list field. Surface condition values (amalgam, composite, missing, implant, crown) also map as pick-list values.
tab32
Billing / Payment Record
Twenty CRM
Custom Object: Payment Record
1:1tab32 patient payment records (payment date, amount, method, provider adjustment, write-off) map to a custom Payment Record object linked to the People record. Payment method (credit card, check, insurance payment, plan) maps as a custom pick-list. Provider adjustments and write-offs stored as separate numeric fields.
tab32
Fee Schedule
Twenty CRM
Custom Object: Fee Schedule
1:1tab32 fee schedules define procedure fees per provider or location. These map to a custom Fee Schedule object with a relation to the Company (practice location) and a text field for CDT code + fee amount pairs. For DSOs with location-specific fees, multiple Fee Schedule records are created per Company.
tab32
Document / Attachment
Twenty CRM
Note
1:1tab32 file attachments (consent forms, insurance cards, treatment plan PDFs) re-upload as Twenty CRM Notes attached to the corresponding People record. File size limits from Twenty's storage configuration apply. Inline clinical images downloaded from tab32 and re-hosted or attached as Note records.
| tab32 | Twenty CRM | Compatibility | |
|---|---|---|---|
| Patient | People1:1 | Fully supported | |
| Practice / Office Location | Company1:1 | Fully supported | |
| Provider / Doctor | Workspace Member1:1 | Fully supported | |
| Appointment | Task1:1 | Fully supported | |
| Treatment Plan | Custom Object: Treatment Plan1:1 | Fully supported | |
| Perio Chart / Periodontal Record | Custom Object: Perio Exam1:1 | Fully supported | |
| Insurance Claim | Custom Object: Insurance Claim1:1 | Fully supported | |
| Tooth Chart / Clinical Notes | Custom Object: Tooth Condition1:1 | Fully supported | |
| Billing / Payment Record | Custom Object: Payment Record1:1 | Fully supported | |
| Fee Schedule | Custom Object: Fee Schedule1:1 | Fully supported | |
| Document / Attachment | Note1: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.
tab32 gotchas
Data quality inheritance blocks clean migration
DSO multi-location structure requires explicit office mapping
Imaging data lives outside the standard export path
Fee schedule consolidation is a pre-migration prerequisite
Training and support model assumes daytime availability
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
Audit tab32 data model and export paths
FlitStack AI connects to tab32 via the available export and API surfaces to inventory all patient records, practice locations, provider accounts, appointments, treatment plans, clinical charts, insurance claims, and file attachments. We assess record counts per object, field completeness rates, and the volume of historical appointments to size the import batches. The audit also identifies which clinical data (perio, tooth charts, CDT codes) needs custom objects in Twenty so the schema plan is complete before any data moves.
Build Twenty CRM schema: custom objects and fields
Before any data lands in Twenty, the schema must be built. FlitStack AI generates a schema setup plan listing every custom object (Treatment Plan, Perio Exam, Insurance Claim, Tooth Condition, Payment Record, Fee Schedule) and every custom field with its type, pick-list values, and relations to the People and Company objects. The Twenty admin creates these in Settings → Data Model following the plan. Custom pick-lists for CDT codes and perio measurements are pre-loaded from tab32's frequency data.
Invite providers and resolve Workspace Members by email
FlitStack AI matches tab32 provider records to Twenty Workspace Members by email address. Providers with matching emails are pre-identified for invite sequencing; providers without email addresses are flagged and assigned to a fallback DSO admin. This step ensures that Task assigneeId values resolve correctly during import — tasks assigned to non-existent members are rejected by Twenty's import validation. A pre-flight email resolution pass flags unmatched providers; those without email receive a temporary placeholder linked to the DSO admin, preventing assigneeId validation failures during import.
Run sample migration with field-level diff
A representative slice of 100–500 records across patients, appointments, treatment plans, and clinical objects migrates first. We generate a field-level diff comparing tab32 source values against Twenty destination values so the admin can verify CDT code mapping, perio exam record linkage, provider assignee resolution, and appointment-to-task status mapping before the full run. Any mapping adjustments are made to the migration plan before cutover.
Execute full migration with delta pickup and audit log
The full migration runs in dependency order: Companies (practices) first, then People (patients) linked to Companies, then Tasks (appointments) linked to People, then custom clinical objects linked to People. A delta-pickup window of 24–48 hours runs concurrently, capturing any new patients or appointments created in tab32 during the cutover. Every operation is recorded in an audit log. One-click rollback reverts all records if reconciliation reveals unexpected data gaps after migration.
Platform deep dives
tab32
Source
Strengths
Weaknesses
Twenty CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 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 tab32 and Twenty CRM.
Object compatibility
1 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
tab32: Not publicly documented.
Data volume sensitivity
tab32 exposes a bulk API — large-volume migrations stream efficiently.
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 tab32 to Twenty CRM migration scoping. Not seeing yours? Book a call.
Walk through your tab32 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 tab32
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.