Migrate from Daffodil CRM to Salesforce Sales Cloud

Daffodil CRM Contact records map to Salesforce Lead or Contact based on the customer's sales process classification. We apply a split rule defined during discovery: prospects without a qualified opportunity become Salesforce Lead; contacts with an active deal or closed-won status become Salesforce Contact attached to an Account. The split rule is documented per-customer because Daffodil CRM's lifecycle or status field naming is bespoke. We preserve the original Daffodil CRM record ID in a custom field daffodil_id__c on both Lead and Contact for audit and cross-reference.

Daffodil CRM Company records map directly to Salesforce Account. The company name becomes Account Name; phone, website, and address fields map to typed Salesforce fields. We use company name as the dedupe key during import. Account is inserted before Contact to satisfy the AccountId Lookup required on Contact. If Daffodil CRM stores multiple contacts per company with a shared company field, we resolve the AccountId reference during Contact import using the company name match.

Daffodil CRM Deals map to Salesforce Opportunity. Deal name becomes Opportunity Name; deal amount maps to Amount; stage maps to StageName using a stage mapping defined against the customer's current Daffodil pipeline. Expected close date maps to CloseDate. We configure a Salesforce Record Type and Sales Process per Daffodil pipeline before migration so that stage values are scoped to the correct sales process. Owner assignment resolves via email match against Salesforce Users.

Each named pipeline in Daffodil CRM becomes a Salesforce Record Type on Opportunity with a corresponding Sales Process that limits the allowed stage values. Stage probability percentages are migrated to StageProbability on each stage entry. If Daffodil CRM uses custom stage names (non-standard pipeline stages), we map them to the closest Salesforce standard stage during transformation before import.

Daffodil CRM activity records (calls, emails, meetings, tasks) export as flat rows with a type field indicating the activity kind. Calls map to Task with TaskSubtype = Call; meetings map to Event with StartDateTime and EndDateTime preserved; general tasks map to Task. Emails map to Salesforce EmailMessage linked to a Task record for timeline display. All activity records reference the related Contact or Deal by the matching field (email, name, or deal name) rather than a numeric ID, because Daffodil CRM exports lack stable record IDs for cross-object lookups.

Custom fields on Contacts, Companies, and Deals in Daffodil CRM are exported with their field names and values. We create corresponding custom fields in Salesforce during the schema phase (before any data import) using Salesforce's typed field model: text fields become Text(255) or Long Text Area; date fields become Date; picklists become Picklist with the source values whitelisted. Multi-select picklists from Daffodil CRM require custom field creation in Salesforce before the import. We do not assume standard field names — every field mapping is built from the customer's actual Daffodil export.

Daffodil CRM user records (sales reps, managers, admins) export with name, email, role, and active status. We resolve each owner by email match against the destination Salesforce org's User table. Any owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Active status maps to Active = true; inactive users are created as inactive Salesforce Users so that historical owner assignments are preserved.

Tags applied to contacts, companies, or deals in Daffodil CRM export as comma-separated values or individual rows. We flatten multi-value tag fields during transformation and reassemble them in Salesforce as multi-select picklist fields on the target object. The customer chooses the target field during scoping: tags on Contacts become a custom multi-select picklist on Contact, for example.

If Daffodil CRM stores product or service items associated with deals, those items map to Salesforce Product2 records. We extract product name, SKU, and price from the Daffodil export, create Product2 records, and add Standard Pricebook entries. The link between product and deal (line items) maps to OpportunityLineItem after both Product2 and Opportunity records exist in Salesforce.

Daffodil CRM's bespoke custom objects (industry-specific or company-specific records not in the standard Contact/Company/Deal/Activity set) map to Salesforce custom objects. We request the full schema for any custom objects during discovery, pre-create the destination custom object in Salesforce with matching lookup relationships, and import after all standard objects are in place. Custom object migration is the most variable step because each Daffodil CRM implementation has a different set of bespoke entities.

File attachments stored within Daffodil CRM (documents, images, uploaded files) are not reliably exportable via standard CSV. We extract attachment metadata (filename, file type, upload date, linked record) and present it as a manual handoff list. The customer's admin downloads files from Daffodil CRM directly and re-uploads them to the Salesforce record, or uploads them to a shared location. We do not migrate attachment binaries directly.

Daffodil CRM record creation dates and last-modified dates export from the source system where available. We map these to Salesforce CreatedDate and LastModifiedDate fields via the Bulk API. If Daffodil exports strip timestamps (common in CSV extracts), we use the record's original export order or an embedded date field as a proxy for CreatedDate and flag the approximation in the reconciliation report.