Migrate from Daylite to Zoho CRM

Daylite People records map to Zoho CRM Contacts. The Person-Company linkage (one Company per Person in Daylite) becomes a Zoho CRM Account lookup on the Contact record. We extract email, phone, address, job title, social profiles, and custom fields from the People CSV and write them to the Zoho Contacts module via the API, using the email address as the dedupe key. Any Person linked to a Company that is absent from the Companies export is held in a gap queue for the customer to resolve.

Daylite Company records map to Zoho CRM Accounts. The Company name becomes Account Name; industry, website, address, and phone fields map directly. We load Accounts first in the migration sequence so that Contact imports can satisfy the Account lookup at insert time. Daylite supports one Company per Person; if the customer has Person records with no linked Company, we create a placeholder Account named 'No Company Assigned' and flag it for the customer's review.

Daylite Opportunities map to Zoho CRM Deals. Each Opportunity carries a stage name (freeform text), monetary value, close date, and links to a Person (Contact) and Company (Account). We extract all unique stage name strings from the Opportunities CSV during the audit phase and present them as a normalization table: the customer maps each Daylite stage name to a Zoho CRM Deal Stage picklist value and assigns the corresponding probability. Stage normalization must be resolved before Deal import because Zoho enforces the stage picklist on insert.

Daylite Opportunity stage names are freeform text stored per record with no central taxonomy, meaning typos and variant names are preserved verbatim. Zoho CRM Deal Stages are a managed picklist defined per Pipeline with probability and forecast category. We deduplicate all unique stage strings from the Daylite export, normalize them (merging 'Closed Won', 'closed-won', and 'Closed Won ' into a single value), and present a stage mapping worksheet. Each mapped stage gets assigned a Zoho stage name, probability percentage, and the order within the pipeline sequence.

Daylite Projects with status, start/end dates, budget, and linked Tasks map to Zoho CRM Tasks module or the standalone Zoho Projects application depending on the customer's Zoho tier. We inspect the exported Projects table during scoping. If the customer holds Zoho Plus ($57/user/month) or an active Zoho Projects subscription, we migrate Projects to the Projects module with sub-tasks mapped accordingly. Otherwise, Projects migrate as Zoho CRM Tasks with the project name stored in a custom text field and linked Contacts/Accounts set on WhatId.

Daylite Appointments export with UTC start/end timestamps, timezone, all-day flag, location, and category, plus a linked Person ID and optional Project ID. We map these to Zoho CRM Events, preserving Start DateTime, End DateTime, All-Day flag, Location, and Description. We resolve the linked Person to a Zoho Contact ID and set the WhoId. If a Project was linked, we set the WhatId to the corresponding Task or Zoho Projects record depending on the chosen project mapping strategy.

Daylite Tasks export with status, due date, priority, assignee, and optional Project linkage. We map them to Zoho CRM Tasks with Subject, Status, Due Date, Priority, and Owner (resolved by email to Zoho User). Sub-tasks inherit a parent Task ID reference. Tasks linked to Projects carry a Project foreign key we follow to set the WhatId to the migrated project record. Standalone Tasks have no WhatId.

Daylite Notes are freeform text attached to any object (Person, Company, Opportunity, Project, Appointment, Task). The export includes the target object type and ID. We write each Note to the Zoho CRM Notes module linked via ContentDocumentLink to the corresponding target record (Contact, Account, Deal, or Task). Note body migrates as plain text. If the Note contains only an attachment reference, we migrate the attachment separately and link it to the parent record.

Daylite Groups are static groupings of People or Companies used for segmentation. We map them to Zoho CRM Tags (a per-record labeling system) on the Contact or Account record. Each Daylite Group membership row becomes a Tag entry on the corresponding Contact or Account. If the customer used Groups for campaign targeting, we also document the group membership counts as a reference list so the customer's admin can rebuild equivalent segmented views in Zoho CRM's Custom Views.

Daylite's tag system is a cross-object labeling mechanism exported as a separate lookup table per object type. We map each tag to a Zoho CRM Tag on the corresponding record (Contact, Account, Deal, or Task). Zoho's Tags are stored as a comma-separated field on the record, which aligns with Daylite's multi-tag-per-record model. Tag normalization (merging duplicate tag names with different casing or spacing) is handled in the same transformation pass as stage normalization.

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 pattern, resolve the parent object type and ID to the migrated Zoho record ID, and reattach each file using the Zoho CRM Attachments API. Attachments are processed after all parent records are confirmed in Zoho. Large attachment sets (over 5,000 files) are chunked and uploaded with exponential backoff to stay within Zoho's API rate limits.

Daylite custom field definitions live in a separate metadata table from the values table. We extract both during export parsing, pair each field definition (name, type, options) with its values, and present a custom field mapping worksheet. The customer explicitly maps each Daylite custom field to a Zoho CRM custom field, specifying the target module, field type (text, number, date, picklist, multi-select, checkbox), and any type conversion needed. Zoho custom fields are created via the CRM API before record import begins. This explicit worksheet step prevents orphaned or misnamed fields in Zoho.