Migrate from NeoDeck Holdings to Twenty CRM

NeoDeck multi-module data does not share a unified object graph

NeoDeck Holdings stores patient records in NeoMed EHR, claims in NeoBiller, and prescriptions in NeoMed Rx as separate data modules with cross-references by patient ID. Twenty CRM has no native multi-module concept — each module's data must be mapped independently, and the cross-references (patient-to-claim, patient-to-prescription) must be rebuilt as Twenty custom object relations (custom object ID fields). We establish these relations during migration by matching on the preserved NeoDeck patient ID stored as Source_System_ID__c on each Twenty People record. If your NeoDeck instance has custom integrations between modules (e.g., auto-linking prescriptions to encounters), those rules do not transfer — they are operational logic to be designed in Twenty post-migration.

Twenty's CSV import limit of 20,000 records per operation requires staged migration

Twenty's UI-based CSV import caps at 20,000 records per operation. Healthcare practices with large patient populations or multi-year billing histories routinely exceed this. We stage the migration in object batches — Companies first (practices), then People (patients), then custom objects (claims, prescriptions), then Notes and Tasks. Each batch stays within the 20,000-record limit. For imports exceeding this cap, we use Twenty's REST/GraphQL API with rate-limit-aware throttling (100 req/min on Free tier, 200 req/min on Pro) to push records in controlled batches. This adds sequencing complexity and is factored into the project scope during planning.

Healthcare field equivalents require custom field creation in Twenty

Twenty CRM is a general-purpose sales CRM with no native healthcare fields. Fields like patient allergies, insurance member IDs, NPI numbers, DEA schedules, ICD diagnosis codes, and claim denial reasons have no standard Twenty equivalent. We create custom fields on the People object (Primary_Insurance__c, Member_ID__c, DEA_Number__c) and on custom objects (Claim_Status__c, Diagnosis_Code__c, Prescription_Status__c). This means your Twenty admin needs to pre-create these custom fields before data lands, or FlitStack AI creates them as part of the migration schema setup. Custom field creation in Twenty requires the Organization (Enterprise) plan or self-hosted — Starter/Pro limits apply.

NeoDeck provider and staff assignments must resolve to Twenty Workspace Members

In NeoDeck Holdings, every patient record, encounter, prescription, and claim carries a provider or staff assignment (provider ID, billing staff ID). Twenty CRM's ownership model uses Workspace Members — users who have accepted an invitation to the Twenty workspace. We resolve NeoDeck provider IDs to Twenty Workspace Members by email match. Any NeoDeck provider whose email does not have a corresponding Twenty user is flagged as an unresolved owner before migration. The practice must create those users in Twenty first, or records are assigned to a designated fallback Workspace Member. This is a pre-migration task, not handled automatically.

Billing rules, e-prescribing logic, and EHR automations do not migrate

NeoDeck Holdings' revenue cycle management rules (claim scrubbing, payer-specific edits, auto-submission logic), e-prescribing workflows (refill request routing, prior authorization triggers), and EHR automations (clinical alerts, care gap reminders) are platform-native business logic that does not export. These must be rebuilt as Twenty workflows, manual procedures, or third-party integrations post-migration. FlitStack AI exports NeoDeck workflow definitions as a reference document for the practice's operational team to use during redesign. We do not attempt to translate or replay NeoDeck's automation logic in Twenty — the constructs are fundamentally different.