Migrate from Insightly CRM to Microsoft Dynamics 365 Sales

Insightly Organizations map directly to Microsoft Microsoft Dynamics 365 Sales Account records. OrganizationId serves as the dedupe key during import. Account is created first, before any Contact import, so that the AccountId lookup is available at Contact insert time. Address fields (street, city, state, postal code, country) map directly to the Account address composite. Industry and annual revenue fields migrate as custom fields if they are non-standard Insightly fields.

Insightly Contacts map to Microsoft Dynamics 365 Sales Contact records. Each Contact receives the corresponding AccountId from the Organization mapping. Email, phone, title, and address fields map 1:1. Any duplicate email addresses detected in the Insightly dataset are held in a reconciliation queue for the customer to resolve before final import. Contact links originally managed via Insightly's Add/Update Link endpoints are resolved as AccountId on the Contact record, which is the Dynamics-native equivalent.

Insightly Leads map directly to Microsoft Dynamics 365 Sales Lead records. Lead status from Insightly maps to the configured Lead Status picklist in Dynamics, with any custom Insightly status values added to the Dynamics picklist before migration. Lead scores, if stored as Insightly custom fields, migrate to custom numeric fields on the Lead.

Insightly Opportunities map to Microsoft Dynamics 365 Sales Opportunity records. The OpportunityName maps to Dynamics subject or name field, and estimated value, close date, and probability migrate directly. Pipeline stage is a custom string in Insightly and requires an explicit mapping table entry per stage name to the Dynamics Sales Process stage values. We configure the Sales Process and stage entries in Dynamics before migration begins.

Insightly pipeline stages are custom-named strings attached to each Opportunity. We extract all distinct stage names from the Insightly export, add them as Stage values in a pre-configured Dynamics Sales Process, assign probability percentages matching Insightly where available, and map each Opportunity's stage string to the new Dynamics stage value during the Opportunity import transform.

Insightly Notes map to Microsoft Dynamics 365 Sales Annotation records on the Microsoft Dataverse layer. Note body, author, and creation timestamp migrate. Each Note's link to its parent record (Contact, Organization, or Opportunity) is reconstructed as a Regarding (objectid) reference on the Annotation during import, preserving the full note context inside the Dynamics timeline.

Insightly Tasks linked to Contacts, Organizations, or Opportunities migrate to Dynamics Task records with ActivityParty resolution. Task status values (not started, in progress, completed, deferred) map to the corresponding Dynamics Task Status values. OwnerId is resolved by email match against the Dynamics User table.

Insightly tags stored as flat string arrays on Contacts, Organizations, and Opportunities migrate to Dynamics multi-select picklist fields on the corresponding entity. We create the field in the Dynamics schema before migration, populate the picklist values with the distinct tag set, and write the tag arrays as semicolon-delimited values at import time.

Insightly custom fields on Contacts, Organizations, Opportunities, and Leads require a FIELD_NAME metadata lookup via /CustomFields/{objectName} before any write operation. We retrieve all custom field definitions at the start of migration, build a FIELD_NAME-to-API-name reference table, and create matching custom fields in the Dynamics schema before data import begins. Each custom field is created in Dynamics with the equivalent field type (text, number, date, picklist) before records are written.

Insightly user-defined Custom Objects migrate to Dataverse custom entities in Microsoft Dynamics 365 Sales . The destination entity schema is created first via the Dataverse API, including all custom fields and any lookup relationships to standard entities (Contact, Account, Opportunity). Data is imported last, after all parent standard entities are in place, to satisfy any required lookups.