Migrate from Daylite to Pipedrive

Daylite People records map directly to Pipedrive Persons. The mapping preserves name fields (first_name, last_name), email addresses (as a separate emails table with type and value columns), phone numbers, and address fields. Custom fields on People migrate to Pipedrive custom fields on Person, which we pre-create in the destination account during schema setup. The Person-Company linkage (a Daylite Person can be linked to one Company via a foreign key) maps to the Pipedrive Person's organization_id field, resolved at migration time after Organizations are created.

Daylite Company records map to Pipedrive Organizations with a 1:1 correspondence. Name, address, industry, website, and custom properties transfer directly. Organization is created before any Person import so that the organization_id lookup is satisfied when Persons are inserted. Daylite supports multiple addresses per Company; we import the primary address and flag the existence of additional addresses in a custom field for the customer's admin to reconcile.

Daylite Opportunities map to Pipedrive Deals. The key migration decision is the Pipeline and Stage assignment. Daylite Opportunity stage names are freeform text strings stored per record, not a managed list. We extract all unique stage name values from the Opportunities export, deduplicate them, and present a stage mapping worksheet where the customer explicitly maps each Daylite stage to a Pipedrive Pipeline Stage. Probability, value (formatted as decimal in Daylite), and close date transfer directly. The Person and Company foreign keys resolve to Pipedrive person_id and org_id via the Person and Organization imports.

Daylite's freeform stage names require explicit normalization. We extract the full set of unique stage strings from the Opportunities export, present them to the customer in a deduplicated table, and the customer assigns each to a Pipedrive Pipeline Stage (with a name and probability). Stages that are typos or variants of the same stage get consolidated at this point. Pipedrive Pipelines are pre-created in the destination account before Deals are imported, and the Stage ID from Pipedrive is stored as the mapping target for all Deal inserts.

Daylite Projects require a scope decision during discovery. Pipedrive's Projects feature (available on Advanced tier and above) supports tasks, milestones, and linked Deals, but is less structured than Daylite's Projects with budget tracking and Time&Budget plugin data. For migrations where Projects represent sales deliverables tied to Deals, we map Projects to Deals with a custom field project_id__c carrying the original Daylite Project reference. For migrations where Projects represent a distinct work-tracking domain, we use Pipedrive's native Projects object and link them to Deals via the project reference field. The customer chooses the strategy during scoping. Time&Budget plugin tables are mapped to custom fields on the Project or Deal depending on strategy.

Daylite Appointments map to Pipedrive Activities with type set to calendar. Each Appointment carries a UTC start and end timestamp, timezone, all-day flag, location, and category. The linked Person and Project IDs resolve to Pipedrive deal_id and person_id at migration time. Attendees from Daylite import as ActivityParticipants in Pipedrive. We preserve the chronological ordering of the appointment history by setting the Activity's due date to the original Daylite timestamp.

Daylite Tasks (both standalone and linked to Projects) map to Pipedrive Activities of type task. Status (open, completed), due date, priority, and assignee transfer directly. Tasks linked to Projects carry a Project foreign key that we resolve to the mapped Deal or Project in Pipedrive depending on the project strategy chosen. Completed status maps to Pipedrive's done flag (0 or 1). Sub-tasks in Daylite map to child Activities with a parent_activity_id reference.

Daylite Notes are freeform text entries attached to any object (Person, Company, Opportunity, Project, Appointment, Task). The export includes the target object type and ID. In Pipedrive, we write Notes as Activity records with type set to note, linked to the corresponding Person, Organization, or Deal via the deal_id or person_id field. Rich text formatting from Daylite Notes is preserved as HTML in Pipedrive's note body. Notes with no valid target object (orphaned records) are flagged for the customer's admin to assign manually.

Daylite Groups are static segment memberships (a Person or Company belongs to one or more Groups). Pipedrive does not have a native Groups object; segmentation is handled via Tags. We map each Daylite Group to a Tag in Pipedrive, creating a TagAssignment for every member record. Tags are created in Pipedrive before Person and Organization imports so that the tag IDs are available during insert. The customer can choose to map Groups to Organization categories instead if they prefer a hierarchical segment structure.

Daylite custom field definitions live in a separate metadata table from the record data. We extract both the field definition table (field name, type, options) and the populated value columns from each record table. During schema setup, we pre-create each custom field in Pipedrive with the matching type (text, varchar, int, double, date, enum, set). Options in Daylite multi-select fields map to Pipedrive's options array. A mapping worksheet presents all custom fields to the customer for explicit confirmation before we create the Pipedrive fields, preventing orphaned or misnamed custom fields in the destination.

Daylite attachments are bundled in the compressed export as a flat folder with filenames referencing the parent object type and ID. We re-attach files to the correct Person, Organization, or Deal record in Pipedrive using the Pipedrive API file upload endpoint. Attachments are uploaded after the parent record exists in Pipedrive, so the parent record insertion order is respected. Any attachments without a valid parent reference are flagged in the migration report.