Migrate from Daylite to Microsoft Dynamics 365 Sales

Daylite People map to Dynamics 365 Contact records. The export contains name, email, phone, address, and custom field columns. We resolve the Company foreign key to the corresponding Account record and populate ParentAccountId on Contact at migration time. Email address is the dedupe key. Any Person without a matching Company is imported as a standalone Contact with no Account linkage, flagged for customer confirmation.

Daylite Company records map to Dynamics 365 Account. Address, industry, and custom properties transfer directly. Account is imported before Contact so that ParentAccountId references are satisfied at insert. We use Account Name as the dedupe key and flag any duplicate name collisions for the customer to resolve.

Daylite Opportunities map to Dynamics 365 Opportunity. The stage name is a freeform string in Daylite; we extract all unique stage strings from the export, deduplicate them, and present them as a stage mapping table. Each stage gets assigned to a Dynamics 365 Sales Process stage with a probability percentage. The close date, value, and probability migrate verbatim; the linked Person and Company foreign keys resolve to Contact and Account IDs at migration time.

Daylite Opportunity stages are per-record freeform strings with no central taxonomy. We create a Dynamics 365 Sales Process (or reuse an existing one) with stage names derived from the customer's deduplicated stage list. Probability values are set per stage per the mapping worksheet. The Sales Process is configured in a Sandbox environment before production migration.

Daylite Projects map to either the Project Service Automation entity (if the customer licenses Dynamics 365 Project Service) or a custom Project entity we create. Project status, dates, and budget fields migrate. Sub-tasks and linked Tasks carry a Project foreign key we follow to maintain hierarchy in the destination. iOSXpert Time&Budget plugin tables, when present in the export, migrate as custom fields on the Project entity.

Daylite Tasks (standalone and sub-tasks) map to Dynamics 365 Task. Status, due date, priority, and assignee migrate. Tasks linked to a Project carry a RegardingObjectId referencing the destination Project entity. We resolve the assignee by email match against the destination User table; unresolved assignees default to the migrating user and are flagged for admin review.

Daylite Appointments map to Dynamics 365 Appointment. UTC start and end timestamps, timezone, all-day flag, location, and category migrate. The linked Person ID resolves to a Contact RegardingObjectId at migration time. Category maps to the Dynamics 365 ActivityType or a custom category field depending on the customer's configuration.

Daylite Notes export with the target object type and ID. We import them as Dynamics 365 Annotation records linked via ObjectId to the corresponding Contact, Account, or Opportunity. Note body migrates as plain text. Any embedded file references in Daylite notes are handled as separate attachment migration.

Daylite Groups are static groupings of People or Companies. We map them to Dynamics 365 Teams (for collaboration groupings) or Security Groups (for access control) depending on how the customer uses Groups. Group membership migrates as Team Membership records or as tags on the member Contact/Account records.

Daylite exports attachments as files in the compressed archive, with filenames referencing the parent object type and ID. We reattach files to the correct Contact, Account, Opportunity, or Project record in Dynamics 365 as Annotation records with file bodies preserved. Large attachment batches are chunked for upload to avoid Dynamics 365 file size limits.

Daylite custom field definitions live in a separate metadata table from the value tables. We extract both, present them as a mapping worksheet so the customer confirms type mapping (Daylite text to Dynamics Text, date to Date, checkbox to Two Option, etc.), and create the custom fields in the Dynamics 365 solution layer before importing values. Custom fields are created per entity (Contact, Account, Opportunity, etc.) with the customer-confirmed API names.