CRM migration

Migrate from tab32 to Twenty CRM

Field-level mapping, validation, and rollback between tab32 and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.

tab32 logo

tab32

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

100%

11 of 11

objects map 1:1 between tab32 and Twenty CRM.

Complexity

BStandard

Timeline

5–10 business days

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

tab32 logo

tab32

What's pushing teams away

  • Support response times of 24–48 hours frustrate practices during critical operations — one reviewer described waiting days for answers to simple questions during an onboarding window.
  • Training relies heavily on pre-recorded video content rather than live, scheduled onboarding sessions, creating access problems for practices operating outside standard business hours.
  • The platform is not user-friendly by default and requires a significant time investment even for tech-savvy teams, with one reviewer recommending competitors for better onboarding UX.
  • Add-on costs and tier-based feature gating reported by multiple sources push the realistic monthly cost above the advertised starting price, creating sticker shock for budget-conscious practices.
  • Feature discoverability is poor — staff report difficulty finding and configuring features even after initial training, suggesting the UI does not surface functionality in an intuitive way.

Choosing

Twenty CRM logo

Twenty CRM

What's pulling them in

  • Top open-source CRM on GitHub with 40.6K stars, giving teams full source code access and infrastructure ownership without per-feature licensing surprises.
  • Free self-hosting under AGPL-3.0 means unlimited users and custom objects for the cost of cloud infrastructure alone, typically $20–100/month.
  • Pricing page explicitly mocks competitors for charging add-on fees for API access, webhooks, and workflows — transparency that resonates with RevOps teams burned by Salesforce.
  • Unlimited custom objects and fields with no price impact, letting teams shape the data model to their business rather than forcing business into rigid schemas.
  • Modern TypeScript/React/PostgreSQL stack means developer-led teams can extend, self-host, or integrate without fighting legacy architecture.

Object mapping

How tab32 objects map to Twenty CRM

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

maps to

Twenty CRM

People

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Company

1:1
Fully supported

tab32'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

maps to

Twenty CRM

Workspace Member

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Task

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Custom Object: Treatment Plan

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Custom Object: Perio Exam

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Custom Object: Insurance Claim

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Custom Object: Tooth Condition

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Custom Object: Payment Record

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Custom Object: Fee Schedule

1:1
Fully supported

tab32 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

maps to

Twenty CRM

Note

1:1
Fully supported

tab32 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.

Gotchas + challenges

What specifically takes care here

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 logo

tab32 gotchas

High

Data quality inheritance blocks clean migration

High

DSO multi-location structure requires explicit office mapping

Medium

Imaging data lives outside the standard export path

Medium

Fee schedule consolidation is a pre-migration prerequisite

Low

Training and support model assumes daytime availability

Twenty CRM logo

Twenty CRM gotchas

High

Import order is enforced and critical

High

Export limited to 20,000 records and visible columns only

Medium

Soft-deleted records count toward uniqueness and trigger restores

Medium

API rate limits cap at 200 req/min on Organization tier

Low

No native email sequences — follow-up cadences require external tools

Pair-specific challenges

  • Dental clinical objects require custom object creation in Twenty before import

    tab32's tooth charts, perio exams, and treatment plans have no direct equivalents in Twenty CRM's standard data model. Twenty's Data Model section (Settings → Data Model) requires creating custom objects and custom fields before any CSV import can land data in those objects. FlitStack AI generates a schema setup plan listing every custom object and field that must exist in Twenty before the import runs — including the field type (text, number, select, multi-select, relation) and pick-list values for clinical fields like CDT codes and tooth conditions. Running the import before the schema is ready results in silent failures on those records.

  • 20,000 record per-export ceiling requires batched multi-file imports from tab32

    Twenty CRM's CSV import caps each file at 20,000 records. For DSOs with 50,000+ patient records across multiple practice locations, tab32's export must be split into multiple batches by practice location or alphabetically by patient name. We handle the batch splitting and cross-file relationship mapping (linking each patient People record to the correct Company practice record using the companyId field) so no relationships break across batches. The provider/patient/appointment data from each batch is reconciled post-import to ensure no orphaned records.

  • Provider-to-Workspace-Member email resolution is mandatory before import

    tab32 provider records may not include email addresses for all staff members (some providers use the practice's main contact email). Twenty CRM requires a Workspace Member email to create the user record and to link Task assigneeId values. We run a pre-flight email resolution pass across all provider records before migration: providers with email addresses are invited to Twenty first; providers without are flagged and assigned to a fallback DSO admin. Tasks assigned to unresolved providers during migration are placed in a staging queue and reconciled after member setup.

  • CDT codes and perio measurements require custom pick-list creation per clinical workflow

    tab32 stores CDT procedure codes and perio pocket depth measurements as structured clinical data. When migrating these to Twenty's custom fields, the exact pick-list values (all 800+ CDT codes, perio ranges like 1–9 mm) must be pre-loaded into Twenty's field settings. If the pick-list values do not exist in Twenty before import, the import UI either rejects the records or stores the values as free text, breaking any downstream filtering or reporting on those fields. We deliver a CDT code subset (based on frequency of use in the source data) and full perio scale values for the admin to load before migration begins.

  • tab32 file attachments re-attach as Notes — original file hosting must be preserved

    tab32's file attachments (consent forms, insurance card images, treatment plan PDFs) are downloaded and re-attached as Twenty Notes on the corresponding People record. The original file hosting (tab32's cloud storage) is not transferred — files are downloaded to FlitStack's staging environment and uploaded to Twenty's storage during import. File size limits from Twenty's storage configuration apply; files exceeding limits are flagged for alternative handling. Inline images embedded in clinical notes are extracted, downloaded, and re-hosted as Note attachments.

Migration approach

Six steps for a successful tab32 to Twenty CRM data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Context on both ends of the pair

tab32 logo

tab32

Source

Strengths

  • Fully cloud-native on Google Cloud Platform with no server infrastructure required and no per-practice hardware footprint.
  • Purpose-built for DSO-scale multi-location management with centralized reporting, fee schedule normalization, and office-level permission structures.
  • Bundled patient engagement suite: two-way texting, automated reminders, e-forms, e-statements, and mobile payments in one platform without per-feature add-on pricing.
  • Open Data Warehousing API provides transparent access to the practice data warehouse for BI and analytics integrations.
  • AI voice charting and AI-driven perio exam dictation are first-to-market clinical features that reduce manual documentation burden.

Weaknesses

  • Support responsiveness lags at 24–48 hours for routine queries, making the platform difficult to use during onboarding and operational troubleshooting.
  • Steep learning curve even for technically sophisticated teams — one reviewer explicitly recommended competing platforms for better live training support.
  • Pricing lacks transparency with reported hidden add-on charges pushing realistic costs above advertised tiers, particularly at enterprise scale.
  • Poor feature discoverability in the UI means staff frequently cannot locate or configure capabilities they have paid for without external consulting help.
  • Customer reviews are sparse on major platforms, making independent evaluation difficult — the available reviews show a bimodal pattern of enthusiastic long-term users and frustrated switchers.
Twenty CRM logo

Twenty CRM

Destination

Strengths

  • AGPL-3.0 open-source license with full source code on GitHub — no vendor lock-in, no sunset risk.
  • Unlimited users and unlimited custom objects on self-hosted, with no feature gating based on headcount.
  • REST and GraphQL APIs available on all paid tiers, not locked behind an enterprise add-on fee.
  • MCP server and webhooks shipped as standard features, not premium upgrades.
  • Modern PostgreSQL-backed data model that developer teams can query, extend, and self-host.

Weaknesses

  • Recent v1.0 release means limited production hardening compared to CRMs with multi-year operational track records.
  • No native email sequencing or sales engagement tools — follow-up cadences require a separate platform.
  • No native two-way email sync or inbox integration, requiring third-party connectors for full activity logging.
  • Self-hosting 'free' pricing hides real infrastructure and DevOps costs that stack up over time.
  • Workflow automation is functional but lacks the complexity needed for sophisticated multi-step sales motions.

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across tab32 and Twenty CRM.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    tab32: Not publicly documented.

  • Data volume sensitivity

    A

    tab32 exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your tab32 to Twenty CRM migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about tab32 to Twenty CRM data migrations

Answers to the questions buyers ask most during tab32 to Twenty CRM migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most tab32-to-Twenty migrations complete in 5–10 business days for under 50,000 total records. DSO-scale migrations with 100,000+ records across multiple practice locations, provider records, and custom clinical objects (perio exams, treatment plans, insurance claims) extend to 3–6 weeks. The longest planning step is creating the Twenty custom objects and clinical pick-lists before import runs — that schema build typically takes 3–5 days depending on how many CDT codes and perio measurement fields are included.

Adjacent paths

Related migrations to explore

Ready when you are

Move from tab32.
Land in Twenty CRM, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day