Migrate from Spark CRM to Microsoft Dynamics 365 Sales

Spark CRM contacts map 1:1 to Dynamics 365 Sales Contact. The primary company lookup requires an Account record to exist first — FlitStack sequences Account migration before Contact migration to resolve the AccountId foreign key correctly. This sequencing ensures foreign‑key constraints are satisfied during bulk load, reducing risk of failed inserts.

Spark CRM contacts that have not progressed past an initial stage route to Dynamics 365 Sales Lead. Routing logic uses a contact-status field or last-activity date — your team defines the threshold before migration runs. Converted leads become Contacts during post-migration go-live in Dynamics.

Spark CRM companies map to Dynamics 365 Sales Account. Company hierarchies (parent/child) map to the Account.ParentId field. Multi-company associations on a single contact collapse to one primary AccountId plus Account Contact Relationships in Dynamics. If a company has no parent, the ParentId field remains blank, and the hierarchy is preserved as a flat list in Dynamics.

Spark CRM deals map to Dynamics 365 Sales Opportunity. The deal amount, close date, owner, and stage name transfer directly. The Spark CRM pipeline becomes a Business Process Flow; deal stage names map to Opportunity Stage values per process. If the pipeline name includes special characters, FlitStack sanitizes it to a valid BPF name before creation.

Each Spark CRM pipeline translates to a Dynamics 365 Sales Business Process Flow (BPF). If you have three pipelines in Spark CRM, FlitStack creates three BPFs and maps their stage names to the corresponding Opportunity Stage optionset values. BPF activation per record type is handled in your Dynamics admin console after data lands.

Stage names map value-by-value from Spark CRM to Dynamics 365 Sales Opportunity StageName optionset. Stage probability and forecast category re-apply from the destination-side stage configuration. Custom stage names in Spark CRM require explicit value-mapping setup before migration. If Spark CRM uses custom stage colors, these are not transferred; they must be re‑applied in the Dynamics stage configuration after migration.

Spark CRM activity records split by type: calls become Tasks with Type='Phone Call', emails become Email activities, and meetings become Appointments. Original timestamps, activity owners, and parent-record lookups preserve so Dynamics timeline views show the full engagement history. If an activity lacks a subject, FlitStack populates a default subject line using the activity type for clarity.

Spark CRM notes migrate as Dynamics 365 Sales Annotations. Rich-text formatting converts to HTML within the Annotation body. Notes attached to a specific record carry the same object-type and object-id correlation in Dynamics. If a note includes inline images, FlitStack extracts the image URLs and stores them as attachment references in the Annotation record.

Spark CRM custom objects map 1:1 to Dataverse custom tables in Dynamics 365 Sales. Relationships that use an N:N association model in Spark CRM need a junction table in Dataverse — FlitStack surfaces this in the pre-migration schema plan and creates the relationship tables automatically.

Spark CRM custom fields migrate as Dataverse custom columns. Data types are matched: text fields to Single-Line Text or Multi-Line Text, pick-lists to Option Sets, date fields to Date and Time. Dynamics 365 Sales Professional caps custom tables at 15 — Enterprise is recommended for setups exceeding that threshold.

Spark CRM file attachments re-upload to Dynamics 365 Sales Attachments or to a connected SharePoint document library. Files exceeding Dataverse's 128 MB per-file limit route to SharePoint with a correlation link stored in the Dynamics record. If a file name contains special characters, FlitStack sanitizes the name before uploading to ensure SharePoint compatibility.

Spark CRM user records resolve to Dynamics 365 Sales SystemUser by email match. Unmatched owners are flagged before migration — your team either provisions Dynamics users first or assigns records to a fallback owner. No record lands without a valid OwnerId.