Migrate from Nimble CRM to Microsoft Dynamics 365 Sales

Nimble's single Contact object maps to either a Dynamics 365 Lead or Contact depending on the contact's lifecycle status. Contacts marked as active prospects in Nimble with no associated Deal map to Lead in Dynamics. Contacts with an associated Nimble Deal or a closed-won status map to Contact and attach to an Account (derived from the Nimble Company). We preserve Nimble's social profile fields (LinkedIn, Twitter, Facebook URLs) as custom text fields on both Lead and Contact. The split rule is defined during scoping using Nimble's contact status and Deal association properties.

Nimble Companies map to Dynamics 365 Accounts. The Nimble Company name becomes the Account Name and serves as the deduplication key during import. We export Companies first to establish all Account records before importing Contacts, resolving the parent Account lookup by exact name match. Address, phone, domain, and industry fields map directly to corresponding Account fields. Parent-child Account hierarchies in Dynamics require optional manual configuration if the Nimble data includes subsidiary relationships.

Nimble Deals map to Dynamics 365 Opportunities. The Nimble dealstage property maps to a Dynamics Sales Process stage value, and pipeline assignment maps to an Opportunity Record Type that we configure before migration. Deal value (amount), close date, owner (resolved via email to Dynamics User), and deal notes migrate to the corresponding Opportunity fields. Loss reason and closed-won reason custom fields map to Dynamics Lost Reason and closed fields.

Each Nimble pipeline translates to a Dynamics 365 Sales Process with stage values corresponding to Nimble's stage labels. Stage probability percentages migrate from Nimble to Dynamics StageProbability. We configure Record Types on Opportunity before migration if the customer uses multiple Nimble pipelines, so that each pipeline maps to its own Record Type with scoped stage values.

Nimble logged calls migrate to Dynamics Task records with TaskSubtype set to Call. Call duration, disposition, and any notes migrate to custom fields on the Task. The Task is linked to the parent Contact (resolved through the Lead/Contact split) and optionally to the related Opportunity via WhatId. Activity timestamps preserve the original Nimble logging date for timeline accuracy.

Nimble Events (calendar appointments and meetings) migrate to Dynamics Event records with StartDateTime, EndDateTime, Location, and Subject preserved. Event attendees link to Dynamics ActivityParty records pointing to the resolved Lead, Contact, or User. If Nimble stores meeting notes or outcomes, these migrate as a custom text field on the Event record.

Nimble Tasks (the kanban task cards) cannot be extracted via Nimble's API because the public API lacks Task CRUD. We rely on Nimble's CSV export, which may truncate historical tasks beyond the 500-record per-file ceiling. Tasks that appear in the export map to Dynamics Task records with Status, Priority, Due Date, and Subject preserved. Tasks without an assigned owner map to a system user pending admin assignment.

Nimble custom fields on Contacts and Companies migrate to Dynamics 365 custom attributes on Contact, Lead, and Account entities. Field types (text, picklist, date, boolean, number) map to the corresponding Dynamics attribute type. Multi-value fields (Nimble tags stored as comma-separated values) may require splitting into multi-select picklists or a related custom entity depending on the customer's data volume and usage pattern.

Nimble Tags are flat label associations stored per contact. We export all tags per record and map them to a Dynamics custom multi-select picklist field on Contact or Lead. If the customer uses tags for content or campaign classification, we map them to Dynamics Topics with TopicAssignment records. The customer chooses the tagging strategy during scoping.

Nimble Owners (sales reps assigned to contacts, companies, and deals) map to Dynamics 365 Users by email address. We extract every distinct owner referenced in the export and match against the destination org's User table. Any owner without a matching Dynamics User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive owners can be mapped to a generic migration user with activity re-assignment handled post-migration.