Migrate from Atomic CRM to Freshsales

Atomic CRM Company records map to Freshsales Account. The Supabase companies table has columns for name, website, address, and any custom fields added via Supabase Studio. We audit the Postgres schema during scoping to capture all columns before designing the Freshsales Account field mapping. Account is the parent record for Contact, so we migrate Accounts first to satisfy referential integrity on the Contact import.

Atomic CRM Contact records map to Freshsales Contact with first_name, last_name, email, phone, and any custom columns from the Supabase contacts table. The relationship to Company migrates by resolving the source contact.company_id foreign key to the destination Account ID created during the Accounts phase. Owner mapping resolves by email match between the Supabase auth UUID on contact and the Freshsales user email.

Atomic CRM Deal records map to Freshsales Deal. The deal value, stage, and expected close date transfer directly. Pipeline stage names in Atomic CRM are defined as TypeScript props in App.tsx rather than stored in the database, so we request the customer share their App.tsx configuration during scoping to capture the exact stage names and probabilities. These are replicated as Freshsales pipeline stages before Deal import. Deals are imported after Accounts and Contacts so that the AccountId and ContactId lookups are resolved.

Atomic CRM Notes migrate to Freshsales Notes linked to the parent record (Contact, Account, or Deal). We inspect the Supabase notes table for its content column, parent reference columns, and any polymorphic relationship structure the instance uses. Notes are migrated after the parent records exist in Freshsales to avoid orphaned entries. Rich-text formatting in notes transfers as-is if the destination field supports it.

Atomic CRM Task records migrate to Freshsales Task. Task type categories (Call, Email, Meeting) are defined as props in App.tsx, not stored in the database, so we extract the enum values from the source code during scoping and configure corresponding task categories in Freshsales before import. Task status, priority, due date, and owner email map directly from Supabase columns. Owner resolution uses the same email-based mapping used for Contact and Deal owners.

Custom fields in Atomic CRM are Postgres columns added via Supabase Studio. There is no UI for managing custom fields in Atomic CRM itself, so undocumented columns added post-deployment are a real risk. We run a pre-migration schema diff against a reference export to identify every custom column on the contacts, companies, deals, notes, and tasks tables. Each column is then configured as a corresponding custom field in Freshsales before data ingestion begins. Field type mapping from Postgres types (text, integer, boolean, timestamp, uuid) to Freshsales field types is documented in the scoping deliverable.

User management in Atomic CRM uses Supabase Auth, where owner references on Contacts, Deals, and Tasks store auth UUIDs rather than readable identifiers. We map owners by email match between the Supabase users table and Freshsales User records. Any Atomic CRM owner without a corresponding Freshsales user is flagged in the reconciliation report and held until the customer's admin provisions the missing user. Owner resolution must complete before Deal and Task import because Freshsales requires OwnerId on those objects.

File attachments in Atomic CRM are stored in Supabase Storage buckets if the instance uses that storage backend, not in the Postgres tables. During scoping we check whether attachments exist and request the Supabase Storage bucket configuration. Files are exported from the bucket and uploaded to Freshsales as attachment records linked to the parent Contact, Account, or Deal. Files stored in custom S3 buckets or external storage require separate coordination and fall outside the standard migration scope.