Migrate from XMPie to Microsoft Dynamics 365 Sales

XMPie audience segment membership is N:N — Dynamics 365 marketing lists are 1:N per contact

XMPie allows a single recipient to belong to multiple audiences and segments simultaneously with rule-based membership that updates dynamically. Dynamics 365 static Marketing Lists associate a Contact with one list at a time through list-member records, and dynamic lists require Enterprise-tier licensing with rule syntax that differs from XMPie's segment conditions. We migrate the primary audience as a pick-list field on the Contact record (XMPie_Audience__c) and secondary audience memberships as a text field (XMPie_Audience_Secondary__c) — but behavioral or date-driven segment rules must be rebuilt as Power Automate flows or Customer Insights segment definitions after migration.

XMPie content personalization variables have no native Dynamics 365 equivalent

XMPie stores recipient-specific personalization fields that drive variable data printing and email personalization — for example, a recipient field named LoyaltyTier or LastPurchaseProduct. Dynamics 365 Contacts have a fixed set of standard fields and a custom field capacity governed by the database row size limit. We map each XMPie variable to a custom field on Contact (prefixed XMPie_) to preserve the data, but campaign personalization logic — conditional content blocks based on those fields — cannot migrate. That logic must be rebuilt as Power Automate conditions or Dynamics 365 marketing email content personalization tokens.

Campaign engagement touchpoints map to a custom entity, not native Dynamics 365 campaign tracking

XMPie Circle tracks each recipient interaction with a campaign — email opens, link clicks, print orders, storefront visits — as a detailed touchpoint record tied to the campaign and recipient. Dynamics 365 Sales Campaign Responses store a single response record per contact per campaign type but do not capture the granular event sequence that XMPie logs. We create a CampaignEngagement__c custom entity in Dynamics 365 to preserve touchpoint history including event type, timestamp, and campaign reference. However, the native Dynamics 365 campaign reporting dashboards will not reflect this data without a custom report or Customer Insights integration.

uStore product variants require manual Dynamics 365 bundle configuration

XMPie uStore allows products with multiple customization dimensions — for example, a product with color, size, and material options where each combination generates a unique SKU. Dynamics 365 Product Bundles group separate products together, and Product Properties handle dimension-based variant selection differently than uStore's option-set model. Products with more than three variant dimensions or dynamic pricing rules per combination require manual bundle setup in Dynamics 365 after migration. We transfer the base product and SKU data; variant structure and pricing rules are flagged for post-migration configuration.

Dynamics 365 Dataverse service protection limits may throttle bulk migration loads

Microsoft applies service protection API limits to Dynamics 365 Online — currently 60,000 requests per user per instance per five minutes for the Web API, with lower limits for certain operations. XMPie exports with high record counts (50,000+ recipients) can exceed these limits during a single migration run if not batched. FlitStack AI implements retry logic with exponential backoff, respects Retry-After headers returned by the Dataverse API, and uses batch ExecuteMultiple requests where allowed to keep within limits without extending migration duration significantly.