Migrate from Atomic CRM to Microsoft Dynamics 365 Sales

Atomic CRM stores all person records in a single Contacts table with no distinction between prospect and customer. We split at migration time using an active-deal association heuristic: Contacts with at least one associated open Deal map to Salesforce Contact; Contacts with no Deal association and no explicit customer flag map to Salesforce Lead. We preserve the original Contact record ID in a custom field atomic_crm_id__c on both Lead and Contact for audit traceability.

Atomic CRM Company records map directly to Dynamics 365 Account. We use the Company domain_name or website column as the dedupe key during import to prevent duplicate Account creation. Account must be inserted before Contact to satisfy the AccountId lookup reference on the Contact record.

Atomic CRM Deals map to Microsoft Dynamics 365 Sales Opportunity. Deal value, currency, expected close date, and owner reference transfer directly. The deal category (e.g. SaaS, Consulting, eCommerce) is captured from the CRM component props file during scoping and becomes a custom picklist field dst_deal_category__c on Opportunity because Dynamics does not have an equivalent native field. We set the OwnerId by resolving the Supabase auth UUID to the destination User email lookup.

Atomic CRM defines pipeline stages as TypeScript props in App.tsx or equivalent, not in the database. We extract the full stage enumeration from the shared CRM configuration file during scoping and replicate it as a Microsoft Dynamics 365 Sales Process with corresponding StageName values. Stage probability percentages are set per the original props definition and rounded to the nearest Dynamics-allowed integer.

Task types in Atomic CRM — Call, Email, Meeting — are passed as props to the CRM component rather than stored in the database. We extract the task type enumeration from the CRM configuration file and create a custom picklist field task_type__c on the Task entity in Dataverse. All migrated Tasks receive the correct type value from this enumeration. Any task type not present in the original props is flagged during scoping so the customer can confirm the correct classification.

Atomic CRM Notes are stored as Postgres records with a polymorphic or foreign-key relationship to Contact or Deal. We map them to Microsoft Dynamics 365 Sales Annotation records with IsDocument=false and the original note body preserved as the notetext column. The Regarding (objectid) lookup is resolved to the migrated Contact or Opportunity GUID at migration time.

Custom fields in Atomic CRM are Postgres columns added via Supabase Studio, not UI-configured properties. We run a pre-migration schema diff against a reference Atomic CRM export to discover every column on every table that is not part of the standard schema. Each discovered column is created as a Dataverse column of the equivalent type (text, number, boolean, date) before data migration begins. Any column with a Postgres type that has no direct Dataverse equivalent is flagged for customer decision during scoping.

Owner assignment on Deals and Tasks references Supabase auth UUIDs, not email addresses. We resolve source owners by email match against the destination Dynamics 365 User table. Any Supabase owner without a matching User record is held in a reconciliation queue for the customer's admin to provision before record import proceeds. Owner-less records are held with ownerid=null and flagged in the reconciliation report rather than silently skipped.