Migrate from Marketing Tools Growth Marketing Platform to Microsoft Dynamics 365 Sales

Marketing Tools Growth Marketing Platform Contacts map directly to Dynamics 365 Sales Contacts. Standard fields (firstname, lastname, emailaddress1, telephone1, jobtitle) migrate cleanly via the Dataverse Web API. We resolve the optional company linkage from the source by exporting contact-company pairs and inserting Accounts first so that the _customerid_account_value lookup is satisfied at Contact import time.

Source Companies map to Dynamics 365 Accounts. The company name becomes the Account name; domain becomes the Website field. Accounts are inserted before Contacts so that the parent-account lookup is available during contact batch import. The source's company ID is preserved in a custom field src_company_id__c for audit and cross-reference.

Segment definitions are rule-based and platform-specific; the underlying logic cannot be exported. We extract segment membership per contact (which contacts belong to which segments) and replicate that membership in Dynamics 365 as Static Marketing List members. The customer's admin rebuilds the segment rule logic in Dynamics 365 Customer Insights or via Power Automate post-migration.

Campaign metadata (name, status, start date, end date, channel) migrates to Dynamics 365 Campaign. Campaign performance metrics (open rates, click rates, revenue attribution) are not available via the source's standard export and must be preserved by the customer as a manual reference export from the platform's analytics dashboard before the cutover date. We create the Campaign record and attach a note linking to that reference file.

Journey definitions — triggers, conditions, branches, and action steps — live in the source's internal automation engine and are not accessible via API. We document every active journey during discovery, capture screenshots of the flow logic, and deliver a written inventory with recommended Power Automate equivalents and Customer Insights journey steps. Rebuilding is handled by the customer's admin or a Microsoft partner post-migration.

Custom object schema is not publicly documented in the source platform's available evidence. Where customers report custom object usage, we attempt field-level mapping during scoping by querying the source API directly. Any undocumented custom objects require a schema investigation sprint before migration; we flag these during discovery and scope them as a change-order line item. Dataverse custom entities are created before standard object migration begins.

Tags export as flat key-value pairs per contact. We map them to a custom text field on Contact (multi-select if the destination supports it) or to Dynamics 365 Tags. Tags that exceed destination character limits are flagged in the pre-migration data quality report and truncated per the customer's preference.

File attachments associated with contacts or campaigns are not available via the source's documented export path. We flag this gap in the discovery report and instruct the customer to use the platform's UI export feature for any attachments they need to preserve before the cutover date. Attachments do not migrate through FlitStack AI's standard scope.