Migrate from Atomic CRM to Salesforce Sales Cloud

Atomic CRM Contact records (name, email, phone, company association, custom fields) map to Salesforce Contact. The Supabase UUID primary key is held as a reference string in a custom field atomic_crm_id__c on the destination Contact for audit traceability. We query Contacts first during migration to resolve the AccountId lookup before any dependent import begins.

Atomic CRM Company records map to Salesforce Account. The company domain becomes the Account Website field and serves as the dedupe key during import. We create Account records before Contact import so the AccountId foreign key is satisfied at the moment of Contact insert. Any custom columns discovered on the Supabase companies table migrate as Account custom fields.

Atomic CRM Deal records map to Salesforce Opportunity. The Deal value, stage category (eCommerce, SaaS, Consulting, etc.), and custom fields migrate directly. The App.tsx Deal category prop values become Salesforce Opportunity StageName picklist entries that we pre-configure in Setup before migration. Closed-Won and Closed-Lost dates migrate to CloseDate and a custom Loss_Reason__c field.

Each distinct Deal category value found in App.tsx becomes a Salesforce Opportunity StageName picklist value. We configure stage probabilities based on the original Atomic CRM deal stage distribution. If the customer has modified the stage enum in App.tsx post-deployment, we capture those values during scoping and replicate them as picklist entries rather than allowing Salesforce's default stage set to overwrite the existing data model.

Atomic CRM Notes use a polymorphic Supabase relationship (referencing either Contact or Deal as parent). We resolve the polymorphic foreign key by querying the actual Supabase table structure, identify the parent type per note, and map Notes linked to Contacts to Salesforce Note with a Contact WhoId; Notes linked to Deals map to ContentDocumentLink on the Opportunity. The note body migrates as rich text. This polymorphic resolution step is unique to Atomic CRM and requires a schema-level inspection before any note records are written.

Atomic CRM Tasks map to Salesforce Task. The Task type classification (Call, Email, Meeting, and any custom types from App.tsx) migrates as TaskType or TaskSubtype. Status, Priority, ActivityDate, and assignee (via Supabase Auth UUID-to-Salesforce User email lookup) transfer directly. Tasks are imported after Owner reconciliation so that OwnerId references are valid at insert time.

Custom fields in Atomic CRM are Postgres columns added via Supabase Studio — not UI-configured properties. During scoping we run a pg_catalog column query against every table to capture every column, type, nullable status, and default value. We then map each to an equivalent Salesforce custom field (custom__c API name) with the matching field type (text, number, date, checkbox, picklist). Custom field audit happens before schema design, not after, to prevent silent data loss.

Atomic CRM User records are Supabase Auth users. We resolve owners by email match against the Salesforce destination org's User table. Owner assignment on Deals and Tasks references Supabase Auth UUIDs, which have no meaning in Salesforce. We map by email so that the correct Salesforce User record is assigned to each migrated Opportunity and Task. Owners without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision before record import resumes.

If the Atomic CRM instance uses tag-style multi-checkbox properties on Contacts or Deals, these map to Salesforce multi-select picklist fields on the Contact or Opportunity object. We capture the distinct tag values from the Supabase column values at migration time and pre-populate the picklist entries before import. Tags with more than 150 distinct values are evaluated for conversion to Salesforce Topics instead.

Atomic CRM stores attachment metadata in Supabase but the actual binary files live in Supabase Storage buckets. We check whether file attachments are present during scoping. If they are, we export the bucket contents (images, PDFs, documents) and map them to Salesforce ContentVersion records, linked to the parent Contact or Opportunity via ContentDocumentLink. Files stored outside Supabase (e.g. on a custom S3 bucket) require separate coordination outside the standard migration scope.

Supabase Row Level Security policies on the source tables can block bulk reads during extraction. We audit RLS policies during scoping and request that the customer grants the migration service account SELECT permission on all tables before extraction begins. Without this step, bulk SELECT queries return empty result sets for some record subsets.

Deal category enums and Task type enums are passed as TypeScript props to the CRM root component in App.tsx, not stored in the database. We ask customers to share their App.tsx (or equivalent configuration file) during discovery so we capture every enum value used in the instance. These values become Salesforce picklist entries on Opportunity.Stage and Task.Type. Without this file, we cannot enumerate the full set of stage and task type values and some records will land with empty or mismatched picklist fields.

If the customer added custom tables beyond the five core entities (Contacts, Companies, Deals, Notes, Tasks), those map to Salesforce custom objects with __c API names. We pre-create the destination schema via the Salesforce Metadata API including custom fields, lookup relationships, and validation rules before importing any data. Custom tables with foreign key dependencies on core tables are imported after the core migration phase to satisfy the lookup constraints.