Migrate from Atomic CRM to Twenty CRM

Atomic CRM Company records map to Twenty CRM Company. The company sector (defined in Atomic CRM's Settings page or Supabase column) maps to Twenty's industry or a custom single-select picklist we create during schema setup. We extract all custom columns on the companies table during the Supabase schema audit and replicate them as custom fields in Twenty before import. Website, size, and phone fields map directly.

Atomic CRM Contact records map to Twenty CRM People. We preserve the link to the parent Company by resolving the Supabase foreign key to the Twenty Company UUID at migration time. Email, name, phone, and any custom columns migrate directly. The contact-to-company relationship requires Companies to be imported first, which we enforce in the migration sequence.

Atomic CRM Deal records map to Twenty CRM Opportunity. The deal stage (e.g. eCommerce, SaaS, Consulting categories) is sourced from the App.tsx props enumeration, not from the database, so we request the customer share their App.tsx during scoping to capture the exact stage labels. We create matching stage picklist values in Twenty's Opportunity settings before importing. Deal value, close date, and company association migrate directly.

Atomic CRM Notes linked to Contacts or Deals migrate to Twenty Notes with the parent record reference preserved. We resolve the polymorphic or foreign-key relationship from the Supabase schema audit to point the Note to the correct Twenty People or Opportunity UUID after import. Note body migrates as plain text.

Atomic CRM Task records migrate to Twenty Tasks. Task type classification (Call, Email, Meeting) comes from the App.tsx props enumeration, not from a database column, so we enumerate the type values from the shared App.tsx during scoping and replicate them as Twenty Task type options before migration. Task status, assignee, and due date migrate directly. Assignee resolution uses email match against Twenty workspace members.

Custom fields in Atomic CRM are Postgres columns added via Supabase Studio — they are not UI-configured properties. We run a pre-migration schema diff against a reference export to discover every column on the contacts, companies, deals, notes, and tasks tables. Each discovered column is replicated as a custom field in Twenty's Settings → Data Model before data import begins. Column type mapping: Supabase varchar/text maps to Twenty text, integer/numeric maps to number, boolean maps to boolean, date maps to date.

Atomic CRM defines deal categories and task types as TypeScript props passed to the CRM root component in App.tsx, not stored in the database. We cannot read these from the Postgres schema. We ask the customer to share their App.tsx (or equivalent configuration file) during scoping so we capture the exact enum values for pipeline stages and task types. These values are then created as picklist options in Twenty's Opportunity settings and Task type settings before any record import begins.

Atomic CRM user management relies on Supabase Auth — owner and assignee references on Deals and Tasks use auth UUIDs. We do not migrate Supabase Auth user records directly. Instead, we extract every distinct owner or assignee email from Deals, Tasks, and Notes, then match against the Twenty workspace Members list by email. The customer provisions Twenty workspace members before migration. Any owner without a matching Twenty member goes to a reconciliation queue for admin provisioning before record import.

Atomic CRM stores file attachments in Supabase Storage buckets when that option is configured. If attachments are present, we export the Supabase Storage bucket contents alongside the database records and attach them to the corresponding Twenty People or Opportunity records. Files stored outside Supabase (e.g. a custom S3 bucket) require separate coordination with the customer. Attachment metadata in Supabase does not migrate — only the binary files and their reference to the parent record.

Atomic CRM supports tags on contacts, companies, and deals as of the March 2026 update. Tags migrate to Twenty's tag model. We preserve the tag names and the record associations (contact-tag, company-tag, deal-tag) and recreate them in Twenty during the data import phase. Tags used for categorization also inform whether a custom single-select or multi-select field should be created instead of a flat tag list.