Migrate from Daylite to Salesforce Sales Cloud

Daylite People with at least one linked Opportunity map to Salesforce Contact attached to the corresponding Account. Daylite People with no linked Opportunity map to Salesforce Lead. The split is evaluated at migration time by querying the Opportunity foreign key in the People table. We preserve the original Daylite Person ID in a custom field daylite_person_id__c on both Lead and Contact for audit and cross-referencing. Any Person marked as a Company contact (is_company_primary_contact flag) is treated as a Contact regardless of Opportunity status.

Daylite Company records map directly to Salesforce Account. The Company name becomes Account Name; the address fields map to BillingAddress. The Daylite Company ID is preserved in a custom field daylite_company_id__c. Accounts are imported before any People migration so that AccountId lookup references are satisfied at Contact insert time. Multiple Daylite People linked to the same Company all resolve to the same AccountId.

Daylite Opportunities map to Salesforce Opportunity with the linked Person resolved to Contact (via the AccountId chain) and the linked Company resolved to AccountId. The Opportunity monetary value maps to Amount, probability maps to a probability percentage we derive from the Daylite stage mapping table, and close date maps to CloseDate. Stage names are normalized from Daylite plain-text strings to the Salesforce Sales Process stage picklist via the stage mapping table produced during scoping.

Daylite Opportunity stages are freeform text strings with no managed taxonomy. We extract every distinct stage value from the export, deduplicate variants (handling typos and case differences), and present a stage mapping table during scoping. Each unique Daylite stage maps to a Salesforce stage name and probability percentage that the customer approves before migration. The mapping becomes a Salesforce Sales Process deployed to the Sandbox before production import.

Daylite Projects have no native Salesforce equivalent. We pre-create a Project__c custom object in the destination org during schema design, with custom fields for project status, start and end dates, budget amount, linked Company (Account lookup), and linked Person (Contact lookup). Project tasks migrate as Task records linked to the Project__c parent via WhatId. If the iOSXpert Time&Budget plugin tables are present in the export, budget and cost data migrate to custom numeric fields on Project__c.

Daylite Tasks map to Salesforce Task with Status, Priority, ActivityDate, and Description preserved. Standalone Tasks carry no WhatId reference. Tasks linked to a Project carry the Project__c custom object ID as WhatId. Task assignment maps by resolving the Daylite owner ID to Salesforce UserId via the owner mapping produced during scoping. Sub-tasks inherit the parent Task ID as a custom parent_task__c field.

Daylite Appointments map to Salesforce Event with StartDateTime and EndDateTime preserved in UTC. The all-day flag maps to IsAllDayEvent. Location maps to Location. Category (Daylite's categorical tag) maps to a custom Event Category picklist that we create during schema design. Attendee links migrate as EventRelation records pointing to the resolved Contact or Lead.

Daylite Notes migrate to Salesforce Note records linked via ContentDocumentLink to the parent object (Lead, Contact, Account, Opportunity, or Project__c). The note body migrates as rich text. Notes with a linked Person attach to the corresponding Contact; notes with a linked Company attach to the Account. We preserve the Daylite note creation timestamp in a custom field daylite_note_created__c.

Daylite Groups are static groupings of People or Companies with no direct Salesforce equivalent. During scoping, the customer chooses between recreating Groups as a custom multi-select picklist on Contact (groups__c), as Salesforce Campaign records with CampaignMember membership, or as Salesforce Topics. We implement the chosen strategy during schema design and populate group membership during import.

Daylite Tags are cross-object string labels exported as a separate lookup table. We map tags to either a custom Label__c multi-select picklist on each applicable object or to Salesforce Labels, depending on the destination's tagging strategy. The customer confirms the strategy during scoping.

Daylite attachments are bundled into the compressed export as a flat folder with filenames referencing the parent object type and ID. We parse the filename structure, reattach each file to the correct Salesforce record via ContentVersion and ContentDocumentLink, and preserve the original filename and Daylite creation date in custom ContentVersion fields.

Daylite custom field definitions (name, type, options) live in a separate metadata table in the export. We extract both the definition table and the value columns, map each Daylite field type to the nearest Salesforce field type (text to Text, date to Date, number to Number, checkbox to Checkbox, picklist to Picklist), pre-create the custom fields on the appropriate Salesforce object during schema design, and migrate values during the standard object import phase.

iOSXpert plugins (Time&Budget, FinanceConnector) write to additional tables within Daylite's database. If those tables are present in the exported CSVs, we migrate their data to custom fields on the corresponding Daylite object (e.g., Time&Budget hours to a custom numeric field on Project__c). If a plugin was not installed when the export was generated, its tables will be absent and we flag the gap for the customer to confirm whether the data exists elsewhere.